Help Center/Cloud Container Engine/User Guide/Permissions/Service Account Token Security Improvement
Updated on 2026-01-04 GMT+08:00
View PDF
Share

Service Account Token Security Improvement

Service Accounts No Longer Auto Create Permanent Tokens

In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from v1.21. Service accounts will stop auto creating secrets in clusters from v1.25.

In clusters of v1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period (one hour by default). Before expiration, kubelet refreshes the token to ensure that the pod always uses a valid token. When the mounting pod is deleted, the token automatically becomes invalid. This approach is implemented by the BoundServiceAccountTokenVolume feature to improve the token security of the service account. Kubernetes clusters of v1.21 and later enable this approach by default.

For smooth transition, the community extends the token validity period to one year by default. After one year, the token becomes invalid, and clients that do not support certificate reloading cannot access the API server. It is recommended that clients of earlier versions be upgraded as soon as possible. Otherwise, service faults may occur.

If you use a Kubernetes client of a to-be-outdated version, the certificate reloading may fail. Versions of officially supported Kubernetes client libraries able to reload tokens are as follows:

  • Go: ≥ v0.15.7
  • Python: ≥ v12.0.0
  • Java: ≥ v9.0.0
  • Javascript: ≥ v0.10.3
  • Ruby: master branch
  • Haskell: v0.3.0.0
  • C#: ≥ 7.0.5

For details, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens.

If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.

Diagnosis

Perform the following operations to check your CCE clusters of v1.21 or later:

  1. Check the add-on versions.
    • If you are using the Prometheus add-on 2.23.34 or earlier, upgrade it to 2.23.34 or later.
    • If you are using CCE Node Problem Detector 1.15.0 or earlier, upgrade it to the latest version.
  2. Use kubectl to access the cluster and run the kubectl get --raw "/metrics" | grep stale command to obtain the metrics. Check the metric named serviceaccount_stale_tokens_total.

    If the value is greater than 0, some workloads in the cluster may be using an earlier client-go version. In this case, check whether this problem occurs in your deployed applications. If yes, upgrade client-go to the version specified by the community as soon as possible. The version must be at least two major versions of the CCE cluster. For example, if your cluster version is v1.23, the Kubernetes dependency library version must be at least 1.19.

Enhanced Node Authentication for Service Accounts

In Kubernetes clusters 1.28 or later, service accounts that use TokenRequest support enhanced node authentication. This capability is available in CCE clusters v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, v1.34.1-r0, and later.

After a user configures the rbac.kubernetes.io/restricted-by-node: "true" annotation on the service account used by a pod, any request that uses the token generated by the service account to access cluster resources (nodes, pods, ConfigMaps, secrets, PVCs, PVs, service accounts/tokens) is restricted to the resources of the node where the pod is located.

Even when the annotation takes effect, the final permission set is still determined by the Role or ClusterRole assigned to the service account through RBAC. RBAC can be thought as a filter rather than a grant. It ensures that the broad permissions of a service account cannot be misused by its token anywhere, thereby enforcing the principle of least privilege.

In this mode, the token is granted only the permissions to operate resources related to the node where the pod is located. Other resources are not restricted. The restricted permissions are as follows:

  • Node: permissions to read, update, and delete node information
  • Pod: permissions to read, update, and delete pods on the nodes
  • Configuration resources: permissions to read, update, and delete ConfigMaps and secrets required by the node
  • Storage resources: permissions to read, update, and delete PVCs and PVs related to the node
  • Token creation: permissions to create tokens for the service account
Parent Topic: Permissions