新聞中心

這里有您想知道的互聯網營銷解決方案

ServiceAccountToken在不同K8s版本中的使用

ServiceAccount token 在不同 K8S 版本中的使用

作者：陽明 2023-01-12 11:31:00

云計算

云原生當創(chuàng)建 Pod 的時候規(guī)范下面有一個 Spec.serviceAccount 的屬性用來指定該 Pod 使用哪個 ServiceAccount，如果沒有指定的話則默認使用Default 這個 Sa。

鐘山ssl適用于網站、小程序/APP、API接口等需要進行數據傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！

ServiceAccount 為 Pod 中運行的進程提供了一個身份，Pod 內的進程可以使用其關聯服務賬號的身份，向集群的 APIServer 進行身份認證。

當創(chuàng)建 Pod 的時候規(guī)范下面有一個 spec.serviceAccount 的屬性用來指定該 Pod 使用哪個 ServiceAccount，如果沒有指定的話則默認使用 default 這個 sa。然后通過投射卷，在 Pod 的目錄 /run/secrets/kubernetes.io/serviceaccount/ 下有一個 token 令牌文件。我們通過 RBAC 對該 sa 授予了什么權限，那么容器里的應用拿著這個 token 后，就具備了對應的權限。

但是需要注意的是不同的 K8s 版本對該 token 文件的使用是不一樣的，所以我們這里分別進行下簡單說明。

<=1.20 版本

使用 kind 快速創(chuàng)建一個小于等于 v1.20 版本的集群：

  kind create cluster --name kind120 --image kindest/node:v1.20.15
  kubectl get nodes
NAME                    STATUS   ROLES                  AGE   VERSION
kind120-control-plane   Ready    control-plane,master   33s   v1.20.15

我們先創(chuàng)建一個字為 sa-demo 的 ServiceAccount 對象：

  kubectl create sa sa-demo
  kubectl get sa
NAME      SECRETS   AGE
default   1         43s
sa-demo   1         6s
  kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-dv78w   kubernetes.io/service-account-token   3      46s
sa-demo-token-4gvbw   kubernetes.io/service-account-token   3      8s

我們可以看到創(chuàng)建 sa 后自動生成了一個 secret，格式為 -token-xxxx，比如我們創(chuàng)建了一個名字為 sa-demo 的 sa 之后，系統自動創(chuàng)建了一個名字為 sa-demo-token-4gvbw 的 secret，這個 secret 里就包含了一個 token。

  kubectl describe secrets sa-demo-token-4gvbw
Name:         sa-demo-token-4gvbw
Namespace:    default
Labels:       
Annotations:  kubernetes.io/service-account.name: sa-demo
              kubernetes.io/service-account.uid: 1ae8eea9-acc6-4e3d-b378-07feb9146ac4

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1066 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImhQNmFMNjAyaDZ5OElyMmtTNGdPUWxRdHVDU1A4aGFfVkJiNHdHMkZjQlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tNGd2YnciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFhZThlZWE5LWFjYzYtNGUzZC1iMzc4LTA3ZmViOTE0NmFjNCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.j0DQmzTeSfagKYGc2dMUuzhYqVQh2puJAoQS0EMKeiAKD6rC4bUHWXWBrCu5Ttvpch6ZTEYwyCdRof1lDGWiLa3pJ1R1RwUNVQTCmVTZPs7tTuoGLRW0KGfEd0jyi4LU6uw4kA_6kwEsz4q2quWcB_fiH_Z3iKVfh1JolYTVAWTBMWnVn6gBvIrlXV5ny2oyvcPQeVfIek8aPQqhbsct_qOxrjqpZY8mpBz0ETR_EELjmcZxVVPLvomOdCqEqbV-FF5KRiFxizB3Xoh6NHz3EcsxpCZNRYdand-UFHaBQC9IPwJKzxhANGmuZuWJUCqCVGGRZTo9c6eoyVz831sZ0A

可以看到自動生成的這個 secret 對象里面包含一個 token，我們也可以通過下面的命令來獲取：

  kubectl get secrets sa-demo-token-4gvbw -o jsnotallow='{.data.token}' | base64 -d

這個 token 是 JWT 結構的，我們可以把這個 token 復制到 jwt.io 網站進行解碼。

右側部分顯示了 token 被解碼之后的內容，其中 PAYLOAD 部分是 token 里包含的 sa-demo 的信息，可以看到里面沒有過期時間，也說明了該 token 是永不過期的。

現在我們使用上面我們創(chuàng)建的 sa 來運行一個 Pod：

# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  serviceAccount: sa-demo
  containers:
    - name: demo
      image: nginx:1.7.9
      ports:
        - containerPort: 80

直接創(chuàng)建該 Pod 即可：

  kubectl apply -f demo-pod.yaml
  kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
demo   1/1     Running   0          81s
  kubectl get pod demo -oyaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: default
spec:
  containers:
  - image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    name: demo
# ......
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: sa-demo-token-4gvbw
      readOnly: true
# ......
  volumes:
  - name: sa-demo-token-4gvbw
    secret:
      defaultMode: 420
      secretName: sa-demo-token-4gvbw

Pod 創(chuàng)建后我們可以看到會自動將指定 sa 對應的 secret 掛載到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目錄下去，所以現在該目錄下面肯定包含對應的 token 文件，我們可以查看該值來驗證下：

  kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6ImhQNmFMNjAyaDZ5OElyMmtTNGdPUWxRdHVDU1A4aGFfVkJiNHdHMkZjQlUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tNGd2YnciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjFhZThlZWE5LWFjYzYtNGUzZC1iMzc4LTA3ZmViOTE0NmFjNCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.j0DQmzTeSfagKYGc2dMUuzhYqVQh2puJAoQS0EMKeiAKD6rC4bUHWXWBrCu5Ttvpch6ZTEYwyCdRof1lDGWiLa3pJ1R1RwUNVQTCmVTZPs7tTuoGLRW0KGfEd0jyi4LU6uw4kA_6kwEsz4q2quWcB_fiH_Z3iKVfh1JolYTVAWTBMWnVn6gBvIrlXV5ny2oyvcPQeVfIek8aPQqhbsct_qOxrjqpZY8mpBz0ETR_EELjmcZxVVPLvomOdCqEqbV-FF5KRiFxizB3Xoh6NHz3EcsxpCZNRYdand-UFHaBQC9IPwJKzxhANGmuZuWJUCqCVGGRZTo9c6eoyVz831sZ0A

可以看到 Pod 里通過投射卷所掛載的 token 跟 sa-demo 對應的 secret 包含的 token 是模一樣的，這個 token 是永不過期的，所以即使刪除了 Pod 之后重新創(chuàng)建，Pod 里的 token 仍然是不變的，因為 secret 對象里面的 token 數據并沒有變化。

如果需要在 Pod 中去訪問 K8s 集群的資源對象，現在就可以為使用的 sa 綁定上相應的權限，然后在 Pod 應用中使用該對應的 token 去和 APIServer 進行通信就可以了，這個時候的 token 就能識別到對應的權限了。

>=1.21 版本 && <= 1.23 版本

接下來我們基于 >= 1.21 && <= 1.23 版本的 K8s 集群進行測試。

這里我們使用 kind 快速創(chuàng)建一個 v1.22.15 版本的集群：

  kind create cluster --name kind122 --image kindest/node:v1.22.15
  kubectl get nodes
NAME                    STATUS   ROLES                  AGE    VERSION
kind122-control-plane   Ready    control-plane,master   115s   v1.22.15

同樣首先創(chuàng)建一個名為 sa-demo 的 ServiceAccount 對象：

  kubectl create sa sa-demo
  kubectl get sa
NAME      SECRETS   AGE
default   1         43s
sa-demo   1         6s
  kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-9w9bp   kubernetes.io/service-account-token   3      116s
sa-demo-token-g7d2g   kubernetes.io/service-account-token   3      8s

同樣可以看到創(chuàng)建 sa 后系統也自動創(chuàng)建了一個對應的 secret 對象，和以前版本沒什么區(qū)別，我們也可以通過下面的命令來獲得該 secret 對象里面包含的 token 值：

  kubectl get secrets sa-demo-token-g7d2g -o jsnotallow='{.data.token}' | base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6Im1ERkhnQ3Y3b1oxUmNHbWVhN210SDEwNXY2dVNkc0QzdXJjTkhsY21FRVEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLWRlbW8tdG9rZW4tZzdkMmciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2EtZGVtbyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjI3ZGI0M2FjLTdjYjItNDQ2Yi05N2Q1LWU0MGUzOWRjZTg4YyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnNhLWRlbW8ifQ.fnSaqrZKolTfz2pi9t32X38Er60WSzUoRHArte6qVmQ1NTaMis4F6rESWekeJvGW26szTJdll6vK8KtL_IRO2m6sp_fEAYfNMQMXL4CuaRByXeAavDqLgMHhodf4k4Yg-Mj4LCQ3aHOxojbAbPT1i_h17Ewivc39fmzp-dAXbHhhWhCW2Vl_CkM-F-UtzLyDwThvJedkeetrfyOOjE7K6HpzWfqIQyMUdCJog3WnFO_4kHXacFCgYg_gNPMYyViQAsTsxB8FplGdEzRuWKnQO9cDE55V4l55IxmE0er-dSSdG8085PzxaM_lMCtRI8YtjRjxcbxS5QkTm5R_ps0IsA

同樣將該 token 值拷貝到 jwt.io 網站進行解碼。

從解碼后的值可以看到該 token 值里面同樣不包含任何過期時間，也說明了我們創(chuàng)建 sa 之后，所對應的 token 是永不過期的。

同樣我們再次使用上面的 sa 來創(chuàng)建一個 Pod，如下所示：

# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  serviceAccount: sa-demo
  containers:
    - name: demo
      image: nginx:1.7.9
      ports:
        - containerPort: 80

直接創(chuàng)建該 Pod：

  kubectl apply -f demo-pod.yaml
  kubectl get pods
NAME   READY   STATUS    RESTARTS   AGE
demo   1/1     Running   0          81s
  kubectl get pod demo -oyaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: default
spec:
  containers:
  - image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    name: demo
    ports:
    - containerPort: 80
      protocol: TCP
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-6wmfb
      readOnly: true
# ......
  volumes:
  - name: kube-api-access-6wmfb
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

當 Pod 創(chuàng)建后查看對應的資源對象，可以看到和之前的版本已經有一個很大的區(qū)別了，并不是將上面自動創(chuàng)建的 secret 掛載到容器的 /var/run/secrets/kubernetes.io/serviceaccount 目錄。我們可以查看下 Pod 中的 token 值來和 secret 包含的 token 值進行對比：

  kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6Im1ERkhnQ3Y3b1oxUmNHbWVhN210SDEwNXY2dVNkc0QzdXJjTkhsY21FRVEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzA1MDI1NDU4LCJpYXQiOjE2NzM0ODk0NTgsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJkZW1vIiwidWlkIjoiNzY1ODRmODAtZjU1My00Mzk2LWIxOTUtMDEwOTBhMzM4MWYyIn0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYS1kZW1vIiwidWlkIjoiMjdkYjQzYWMtN2NiMi00NDZiLTk3ZDUtZTQwZTM5ZGNlODhjIn0sIndhcm5hZnRlciI6MTY3MzQ5MzA2NX0sIm5iZiI6MTY3MzQ4OTQ1OCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6c2EtZGVtbyJ9.TAoe1eCHCXUoHh6oM4uySp8kzRaLQ44GZdU02Ir8m_dzYpdFSw4nwsNyqPggrZdDL3BMH4zceudBEdQuyxiSsrpVDeQKww2wTGhXAr2hWujrJq4ycmu6aMywyv2iRX9Vn-Las1giWK_bFuzCxiR10Lcgyd5N7VjB2WcT7K8rN7dAeUWgiH2s9lMOzoaIorUDXzlnSTcmxkhz1h7RXYKVGaqZBbd5wJsRnINZPGxqsS-wi21Aw2FFmIeeK8GGlnAqnS0f3VS1N2jm03gKPii-sMt0GARse4HsmhGAhyJnt9za6ZNpBgcybd7uEBjgIVrRFTkqBJOjPrAnMvRucVtwww

可以很明顯看到現在 Pod 中的 token 值和自動創(chuàng)建 secret 的 token 值不一樣了，同樣在 jwt.io 解碼該 token 值。

可以看到該 token 值解碼后的 PAYLOAD 數據中包含了很多不同的數據，其中的 exp 字段表示該 token 的過期時間，可以看到過期時間是 1 年。

這里我們可以總結下在 v1.21 到 v1.23 版本的 K8s 集群，當創(chuàng)建 ServiceAccount 對象后，系統仍然會自動創(chuàng)建一個 secret 對象，該 secret 對象里面包含的 token 仍然是永不過期的，但是 Pod 里面并不會使用該 secret 的 token 值了。

從上面查看創(chuàng)建后的 Pod 資源清單可以看出，現在創(chuàng)建 Pod 后，Kubernetes 控制平面會自動添加一個投射卷到 Pod，此卷包括了訪問 Kubernetes API 的 token，該清單片段定義了由三個數據源組成的投射卷，這三個數據源是：

serviceAccountToken 數據源：包含 kubelet 從 kube-apiserver 獲取的令牌，kubelet 使用 TokenRequest API 獲取有時間限制的令牌。為 TokenRequest 服務的這個令牌會在 Pod 被刪除或定義的生命周期（默認為 1 小時）結束之后過期。該令牌綁定到特定的 Pod，并將其 audience（受眾）設置為與 kube-apiserver 的 audience 相匹配。這種機制取代了之前基于 Secret 添加卷的機制，之前 Secret 代表了針對 Pod 的 ServiceAccount 但不會過期。
configMap 數據源：ConfigMap 包含一組證書頒發(fā)機構數據，Pod 可以使用這些證書來確保自己連接到集群的 kube-apiserver（而不是連接到中間件或意外配置錯誤的對等點上）。
downwardAPI 數據源：用于查找包含 Pod 的名字空間的名稱，并使該名稱信息可用于在 Pod 內運行的應用程序代碼。

所以我們應該要指定現在版本的 K8s 集群創(chuàng)建的 Pod 里面包含的 token 不是使用 ServiceAccount 自動關聯的 secret 對象里面的 token 了，而是 kubelet 會向 TokenRequest API? 發(fā)送一個請求，申請一個新的 token 放在 Pod 的 /run/secrets/kubernetes.io/serviceaccount/token 里。這個 token 會在 1 個小時后由 kubelet 重新去申領一個新的 token，所以 1 小時之后再次查看這個 token 的話會發(fā)現 token 的內容是變化的，如果刪除此 Pod 重新創(chuàng)建的話，則會重新申領 token，被刪除 Pod 里的 token 會立即過期。

而且我們還可以手動使用 kubectl create token 命令來請求 ServiceAccount 的 token，可以指定有效期等：

  kubectl create token -h
Request a service account token.

Examples:
  # Request a token to authenticate to the kube-apiserver as the service account "myapp" in the current namespace
  kubectl create token myapp

  # Request a token for a service account in a custom namespace
  kubectl create token myapp --namespace myns

  # Request a token with a custom expiration
  kubectl create token myapp --duration 10m

  # Request a token with a custom audience
  kubectl create token myapp --audience https://example.com

  # Request a token bound to an instance of a Secret object
  kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret

  # Request a token bound to an instance of a Secret object with a specific uid
  kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid
0d4691ed-659b-4935-a832-355f77ee47cc

Options:
# ......

?>=?1.24 版本

現在我們再來看下 v1.24 版本以上的 K8s 集群中的 ServiceAccount token 是如何工作的。這里我們使用 kind 快速創(chuàng)建一個 v1.25.3 版本的集群：

  kind create cluster --name kind125 --image kindest/node:v1.25.3
  kubectl get nodes
NAME                    STATUS   ROLES                  AGE    VERSION
kind125-control-plane   Ready    control-plane,master   115s   v1.25.3

同樣創(chuàng)建一個名為 sa-demo 的 ServiceAccount：

  kubectl create sa sa-demo
  kubectl get sa
NAME      SECRETS   AGE
default   0         39d
sa-demo   0         5s
  kubectl get secrets
No resources found in ns1 namespace

我們可以看到該 ServiceAccount 創(chuàng)建后并沒有創(chuàng)建對應的 Secret 對象。同樣接下來創(chuàng)建一個如下所示的 Pod：

# demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  serviceAccount: sa-demo
  containers:
    - name: demo
      image: nginx:1.7.9
      ports:
        - containerPort: 80

創(chuàng)建上面的 Pod 后查看詳情：

  kubectl apply -f demo-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: default
spec:
  containers:
  - image: nginx:1.7.9
    imagePullPolicy: IfNotPresent
    name: demo
    ports:
    - containerPort: 80
      protocol: TCP
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-pftqd
      readOnly: true
# ......
  volumes:
  - name: kube-api-access-pftqd
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

可以看到創(chuàng)建 Pod 后同樣會自動添加一個投射卷到 Pod，此卷包括了訪問 Kubernetes API 的令牌，和 >=1.21 版本 && <= 1.23 版本表現是一致的。同樣我們可以下查看 Pod 中的 token 值來進行驗證：

  kubectl exec -it demo -- cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IndnazJLZENQTktiZkxVejhnMnhmTHJYRTlkZ2ZnOHJGQmgwVW4td3BWd0kifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzA0ODg0MDg0LCJpYXQiOjE2NzMzNDgwODQsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJkZW1vIiwidWlkIjoiMTY0ZTIwZTYtYjNjMi00ZmQ5LWI3ZTUtMDZjYTExZWIyOWM4In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYS1kZW1vIiwidWlkIjoiYjJlNWM3ZmYtNjlhNy00NzYyLTkxMDctM2UxNzZhYmQ3NTdiIn0sIndhcm5hZnRlciI6MTY3MzM1MTY5MX0sIm5iZiI6MTY3MzM0ODA4NCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6c2EtZGVtbyJ9.lhYscyn_d9Y3GZSipSqGj4Jtsu8qsIyz34L18lv37HxjjGU_bQmUFCXYf_CRom8DfadHppmlaskZS18KmyTV1Z09BeujJd8viUnnYCWb9K6VJB5uPBYWLB0FETfgQy7Kqu8Gvk8qBKLjdCkl8U2vr2Oqd2qSEDyvqhNBQXnckQRH6wyypBUc7EXSGAJf6dPVE3c6XqnbXMJ7SRZb5svE-hv0lZKmJrouz9Ia4qxUXUtpzDlMPnHOym2x9d1TSSZ1Lp7BOsqTnxlUQVueh9w869jAajrP1G9e5zhZwZBfzRfARqCVqoLid_hOQP-mo4MLfHbn61SWItlCBd75nl2WLQ

我們可以把上面輸出的 token 值拷貝到 jwt.io 里進行解碼。

從上面的數據可以看到這里的 token 的有效期也為 1 年，這個 token 在 Pod 里也是每 1 小時會更新一次，如果 Pod 被刪除重建，那么會重新申領一個新的 token，被刪除 Pod 里的 token 立即過期。

需要注意的沒有特定的機制使通過 TokenRequest 簽發(fā)的令牌無效，如果你不再信任為某個 Pod 綁定的 ServiceAccount 令牌，你可以刪除該 Pod，刪除 Pod 將使其綁定的令牌過期。

總結

我們可以簡單總結下不同版本的 K8s 集群下面的 ServiceAccount Token 是如何工作的。

1.20（含 1.20）之前的版本，在創(chuàng)建 sa 時會自動創(chuàng)建一個 secret，然后這個會把這個 secret 通過投射卷掛載到 pod 里，該 secret 里面包含的 token 是永久有效的。
1.21~1.23 版本，在創(chuàng)建 sa 時也會自動創(chuàng)建 secret，但是在 pod 里并不會使用 secret 里的 token，而是由 kubelet 到 TokenRequest API 去申請一個 token，該 token 默認有效期為一年，但是 pod 每一個小時會更新一次 token。
1.24 版本及以上，在創(chuàng)建 sa 時不再自動創(chuàng)建 secret 了，只保留由 kubelet 到 TokenRequest API 去申請 token。

當然我們仍然可以手動創(chuàng)建 Secret 來保存 ServiceAccount 令牌，例如在你需要一個永不過期的令牌的時候。一旦手動創(chuàng)建一個 Secret 并將其關聯到 ServiceAccount，Kubernetes 控制平面就會自動將令牌填充到該 Secret 中。

盡管存在手動創(chuàng)建長久 ServiceAccount 令牌的機制，但還是推薦使用 TokenRequest 獲得短期的 API 訪問令牌。

網站題目：ServiceAccountToken在不同K8s版本中的使用
瀏覽路徑：http://fisionsoft.com.cn/article/dpdgiis.html

新聞中心

ServiceAccount token 在不同 K8S 版本中的使用

<=1.20 版本

>=1.21 版本 && <= 1.23 版本

?>=?1.24 版本

總結

其他資訊