Kubernetes身份認證和受權操做全攻略：訪問控制之Service Account

這是本系列的最後一篇文章，前面咱們瞭解了訪問控制中的基本概念以及身份認證和受權的具體操做，本文咱們將進一步瞭解訪問控制中的service account。

Kubernetes中有用戶和service account的概念，可用於訪問資源。用戶與密鑰和證書相關聯用於驗證API請求，使用其中一個配置方案對在集羣外部發起的任何請求進行身份驗證。最多見的方案是經過X.509證書進行身份認證請求。有關建立證書和將證書與用戶關聯的信息，請參閱Kubernetes身份驗證教程。

請記住，Kubernetes不維護數據庫或用戶和密碼的配置文件。相反，它但願在集羣以外進行管理。經過身份驗證模塊的概念，Kubernetes能夠將身份驗證委派給第三方，如OpenID或Active Directory。

儘管X.509證書可用於身份驗證的外部請求，但service account能夠用於驗證集羣中運行的進程。此外，service account與進行API server內部調用的pod相關聯。

每一個Kubernetes安裝都有一個默認的service account，它與每一個正在運行的pod相關聯。相似地，爲了使pod可以調用內部API Server端點，有一個名爲Kubernetes的ClusterIP服務，它與默認的service account一塊兒使內部進程能夠調用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內部的secret。這一secret包含API Server所需的令牌。

kubectl get secret

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

當咱們開始調度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

因爲請求缺乏身份驗證令牌，所以不會產生任何結果。讓咱們看看如何檢索能夠嵌入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

讓咱們來設置一些環境變量以簡化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並無足夠的權限來檢索在同一命名空間內的服務。

請記住，Kubernetes遵循封閉開放的慣例，這意味着在默認狀況下用戶和service account沒有任何權限。

爲了知足這一請求，咱們須要建立一個角色綁定，將默認service account和適當的角色相關聯。這一步與咱們將角色綁定到Bob的方式相似，後者授予他列出pod的權限。

退出pod而且運行如下命令，爲默認service account建立一個角色綁定。

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

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

以上命令將默認service account與集羣角色視圖相關聯，該角色視圖使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建立其餘綁定，以檢查RBAC如何擴展到pod。

關於Kubernetes身份認證與受權系列文章到此結束，咱們討論了身份驗證，受權和Service account的基本概念，但願能對你有所幫助。