When you create a Kubernetes cluster, you can enable service account token volume projection to enhance security when you use service accounts. This feature enables the kubelet to request and store the token on behalf of the pod, and allows you to configure token properties such as the audience and validity duration. As the token approaches expiration, the kubelet proactively rotates the token if it is older than 80 percent of its time to live (TTL) or if it is older than 24 hours. This topic describes how to configure and use service account token volume projection in Container Service.

Background information

Service accounts are used to provide an identity for pods when they communicate with the API server. Traditionally, you may encounter the following security issues when you use service accounts:
  • The JSON Web Tokens (JWTs) used by service accounts are not audience bound. Any user of a service account can masquerade as anyone else and launch masquerade attacks.
  • The service account token is stored in a secret and delivered as a file to the corresponding node. A service account may be granted advanced permissions when a powerful system component is running. This results in a broad attack surface for the Kubernetes control plane. Attackers can obtain the service account used by this system component to launch privilege escalation attacks.
  • JWTs are not time bound. A JWT that is compromised in the aforementioned attacks stays valid for as long as the service account exists. You can mitigate the issue only through service account signing key rotation, which is not supported by client-go and not automated by the control plane. Therefore, a complex operations process is required.
  • A Kubernetes secret must be created for each service account. This may put strains on elasticity and capacity in large-scale workload deployments.

Container Service for Kubernetes supports the BoundServiceAccountTokenVolume feature to enhance the security of service accounts. This feature enables pods to use a projected volume to mount the service account to a container, thus avoiding the dependency on secrets.

Step 1: Enable service account token volume projection

When you create a cluster, select the Enable check box to enable service account token volume projection. For more information about creating a cluster, see Create an ACK cluster.Enable service account token volume projection
When service account token volume projection is enabled, system components apiserver and controller-manager will automatically enable BoundServiceAccountTokenVolume feature gate and the following parameters will be added to apiserver startup parameters.
Parameter Description Default Configure through console
service-account-issuer The issuer of the service account token, which corresponds to the iss field in the token payload. kubernetes.default.svc Supported
api-audiences The identifiers of the API, which are used to validate the tokens at the API server side. kubernetes.default.svc Supported. You can set one or more audiences. Separate multiple audiences with commas (,).
service-account-signing-key-file The file path of the private key that signs the token. /etc/kubernetes/pki/sa.key Not supported. Default is /etc/kubernetes/pki/sa.key.

Step 2: Use service account token volume projection

To configure a token with an audience of vault and a validity duration of two hours for a pod, you can run the following command and use the following PodSpec template. 
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault
Notice
  • Make sure that the pod periodically reloads the token when it rotates. This ensures that the pod can obtain the latest token in real time. We recommend that you reload the token once every 5 minutes. client-go versions later than 10.0.0 support automatic reloading to obtain the latest token.
  • The permissions of the token file that corresponds to a service account are no longer 644. When BoundServiceAccountTokenVolume is used, the permissions are 600. When fsGroup is used, the permissions are 640.