Kubernetes身份認證和授權(quán)操作全攻略：訪問控制之Service Account

這是本系列的最后一篇文章，前面我們了解了訪問控制中的基本概念以及身份認證和授權(quán)的具體操作，本文我們將進一步了解訪問控制中的service account。

Kubernetes中有用戶和service account的概念，可用于訪問資源。用戶與密鑰和證書相關聯(lián)用于驗證API請求，使用其中一個配置方案對在集群外部發(fā)起的任何請求進行身份驗證。最常見的方案是通過X.509證書進行身份認證請求。有關創(chuàng)建證書和將證書與用戶關聯(lián)的信息，請參閱Kubernetes身份驗證教程。

請記住，Kubernetes不維護數(shù)據(jù)庫或用戶和密碼的配置文件。相反，它希望在集群之外進行管理。通過身份驗證模塊的概念，Kubernetes可以將身份驗證委派給第三方，如OpenID或Active Directory。

盡管X.509證書可用于身份驗證的外部請求，但service account可以用于驗證集群中運行的進程。此外，service account與進行API server內(nèi)部調(diào)用的pod相關聯(lián)。

每個Kubernetes安裝都有一個默認的service account，它與每個正在運行的pod相關聯(lián)。類似地，為了使pod能夠調(diào)用內(nèi)部API Server端點，有一個名為Kubernetes的ClusterIP服務，它與默認的service account一起使內(nèi)部進程可以調(diào)用API端點。
 

kubectl get serviceAccounts

NAME      SECRETS   AGE
default   1         122m

 kubectl get svc

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1            443/TCP   123m

請注意，這個service account指向嵌在每個pod內(nèi)部的secret。這一secret包含API Server所需的令牌。
 

kubectl get secret

NAME                  TYPE                                  DATA   AGE
default-token-4rpmv   kubernetes.io/service-account-token   3      123m

當我們開始調(diào)度pod并且訪問它時，一切都變得明朗起來。我們將使用curl命令啟動一個基于BusyBox的pod。
 

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
If you don't see a command prompt, try pressing enter.
[ root@curl-tns-56c6d54585-6v2xp:/ ]$

當我們在BusyBox shell中時，讓我們嘗試訪問API Server端點。
 

[ root@curl-tns-56c6d54585-6v2xp:/ ]$ curl https://kubernetes:8443/api

由于請求缺少身份驗證令牌，因此不會產(chǎn)生任何結(jié)果。讓我們看看如何檢索可以嵌入HTTP頭部的令牌。

如之前所討論的，令牌作為一個secret安裝在pod里。查看/var/run/secrets/kubernetes.io/serviceaccount 來查找令牌。
 

[ root@curl-tns-56c6d54585-6v2xp:/ ]$ cd /var/run/secrets/kubernetes.io/serviceaccount

[ root@curl-tns-56c6d54585-6v2xp:/tmp/secrets/kubernetes.io/serviceaccount ]$ ls
ca.crt     namespace  token

讓我們來設置一些環(huán)境變量以簡化curl命令。
 

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)

以下curl命令請求在默認命名空間中的服務。讓我們看看我們能否從API Server中獲得回應。
 

[ root@curl-tns-56c6d54585-6v2xp:~ ]$ curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/services/"

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "services is forbidden: User \"system:serviceaccount:default:default\" cannot list resource \"services\" in API group \"\" in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "services"
  },
  "code": 403
}

然而，默認的service account并沒有足夠的權(quán)限來檢索在同一命名空間內(nèi)的服務。

請記住，Kubernetes遵循封閉開放的慣例，這意味著在默認情況下用戶和service account沒有任何權(quán)限。

為了滿足這一請求，我們需要創(chuàng)建一個角色綁定，將默認service account和適當?shù)慕巧嚓P聯(lián)。這一步與我們將角色綁定到Bob的方式類似，后者授予他列出pod的權(quán)限。

退出pod并且運行以下命令，為默認service account創(chuàng)建一個角色綁定。
 

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=default:default \
  --namespace=default

 rolebinding.rbac.authorization.k8s.io/default-view created

以上命令將默認service account與集群角色視圖相關聯(lián)，該角色視圖使pod能夠列出資源。

如果你十分好奇，想看所有可用的集群角色，運行命令：kubectl get clusterroles。

讓我們再次啟動BusyBox pod并且訪問API Server。
 

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
If you don't see a command prompt, try pressing enter.
[ root@curl-tns-56c6d54585-2cx44:/ ]$

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)

curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://kubernetes/api/v1/namespaces/$NAMESPACE/services/"

{
  "kind": "ServiceList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/namespaces/default/services/",
    "resourceVersion": "11076"
  },
  "items": [
    {
      "metadata": {
        "name": "kubernetes",
        "namespace": "default",
        "selfLink": "/api/v1/namespaces/default/services/kubernetes",
        "uid": "b715a117-6be1-4de0-8830-45bddcda701c",
        "resourceVersion": "151",
        "creationTimestamp": "2019-08-13T09:45:27Z",
        "labels": {
          "component": "apiserver",
          "provider": "kubernetes"
        }
      },
      "spec": {
        "ports": [
          {
            "name": "https",
            "protocol": "TCP",
            "port": 443,
            "targetPort": 8443
          }
        ],
        "clusterIP": "10.96.0.1",
        "type": "ClusterIP",
        "sessionAffinity": "None"
      },
      "status": {
        "loadBalancer": {

        }
      }
    }
  ]
}

您可以隨意為默認service account創(chuàng)建其他綁定，以檢查RBAC如何擴展到pod。

關于Kubernetes身份認證與授權(quán)系列文章到此結(jié)束，我們討論了身份驗證，授權(quán)和Service account的基本概念，希望能對你有所幫助。