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的基本概念，希望能對你有所幫助。