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.
- 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
|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
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
- 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.