成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

ServiceAccount Token 在不同 K8s 版本中的使用

作者：陽明
云計算 云原生
當創建 Pod 的時候規范下面有一個 Spec.serviceAccount 的屬性用來指定該 Pod 使用哪個 ServiceAccount，如果沒有指定的話則默認使用Default 這個 Sa。

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

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

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

<=1.20 版本

使用 kind 快速創建一個小于等于 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

我們先創建一個字為 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

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

? ? kubectl describe secrets sa-demo-token-4gvbw
Name:         sa-demo-token-4gvbw
Namespace:    default
Labels:       <none>
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 是永不過期的。

現在我們使用上面我們創建的 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

直接創建該 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 創建后我們可以看到會自動將指定 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 之后重新創建，Pod 里的 token 仍然是不變的，因為 secret 對象里面的 token 數據并沒有變化。

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

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

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

這里我們使用 kind 快速創建一個 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

同樣首先創建一個名為 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

同樣可以看到創建 sa 后系統也自動創建了一個對應的 secret 對象，和以前版本沒什么區別，我們也可以通過下面的命令來獲得該 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 值里面同樣不包含任何過期時間，也說明了我們創建 sa 之后，所對應的 token 是永不過期的。

同樣我們再次使用上面的 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

直接創建該 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 創建后查看對應的資源對象，可以看到和之前的版本已經有一個很大的區別了，并不是將上面自動創建的 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 值和自動創建 secret 的 token 值不一樣了，同樣在 jwt.io 解碼該 token 值。

圖片

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

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

從上面查看創建后的 Pod 資源清單可以看出，現在創建 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 包含一組證書頒發機構數據，Pod 可以使用這些證書來確保自己連接到集群的 kube-apiserver（而不是連接到中間件或意外配置錯誤的對等點上）。
  • downwardAPI 數據源：用于查找包含 Pod 的名字空間的名稱，并使該名稱信息可用于在 Pod 內運行的應用程序代碼。

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

而且我們還可以手動使用 kubectl create token <sa> 命令來請求 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 快速創建一個 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

同樣創建一個名為 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 創建后并沒有創建對應的 Secret 對象。同樣接下來創建一個如下所示的 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

創建上面的 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

可以看到創建 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 簽發的令牌無效，如果你不再信任為某個 Pod 綁定的 ServiceAccount 令牌，你可以刪除該 Pod，刪除 Pod 將使其綁定的令牌過期。

總結

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

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

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

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

責任編輯：姜華 來源： k8s技術圈
K8sToken
相關推薦

2024-08-30 09:21:28

2022-01-22 21:38:19

K8SRedisRedis clus

2023-11-06 07:16:22

WasmK8s模塊

2022-04-22 13:32:01

K8s容器引擎架構

2020-12-15 18:56:26

MirantisDockersKubernetes

2023-12-05 18:16:59

LTS版本K8s

2022-06-14 07:56:15

Kubernetes存儲架構K8S

2020-07-17 08:40:47

K8SServicePOD

2023-09-06 08:12:04

k8s云原生

2024-01-02 14:56:37

K8s部署應用程序

2024-07-15 18:20:18

2023-09-15 07:34:15

AIOps云原生項目

2022-06-01 09:38:36

KubernetesPod容器

2024-01-26 14:35:03

鑒權K8sNode

2021-07-14 14:20:22

root命令Linux

2021-08-05 07:28:26

K8sNFS ProvisiSubdir

2020-05-12 10:20:39

K8s kubernetes中間件

2022-09-05 08:26:29

Kubernetes標簽

2023-05-25 21:38:30

2023-08-03 08:36:30

Service服務架構
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 亚洲成人免费观看 | av一级久久| 黄a大片 | 亚洲成人自拍 | 亚洲交性 | 精品久久九 | 国产婷婷色综合av蜜臀av | 欧美电影在线观看网站 | 成人av网站在线观看 | 欧美亚洲一区二区三区 | 日韩精品成人av | 日韩精品久久久久久 | 久久久综合精品 | 久久精品亚洲精品国产欧美 | 国产免费观看久久黄av片涩av | 亚洲草草视频 | 日韩免费高清视频 | 日韩中字幕| 日韩久久久久久 | 久久最新精品 | 久久精品一区二 | 国产区视频在线观看 | 亚洲欧美高清 | 希岛爱理在线 | 毛片免费观看 | av国产精品毛片一区二区小说 | www日韩欧美| 天天av综合 | 91xh98hx 在线 国产 | 中国美女av | 国产高清免费视频 | 免费高潮视频95在线观看网站 | 精品中文字幕一区二区三区 | 最新中文字幕一区 | 亚洲精品国产电影 | 五月综合色啪 | 亚洲三区视频 | 全免一级毛片 | 久久久久久国产 | 欧美日韩亚洲视频 | 亚洲综合电影 |