Service account tokens: mount only when the workload needs Kubernetes API access

Last updated: 1 Oct 20266 min read

tutorial

A Kubernetes ServiceAccount identifies a workload to the API server. Its token is a credential, not a general-purpose application secret. A Pod may receive an automatically mounted token even when the application never calls the Kubernetes API. The existence of RBAC restrictions lowers the scope of that token but does not make needless exposure desirable.

Operational decision

A document-rendering worker reads jobs from a queue and writes finished PDFs to object storage. It has no reason to list Pods or read Secrets. Assign it a dedicated ServiceAccount with no added RoleBinding and disable automatic token mounting in its Pod template. The manifest shows that boundary but omits queue configuration, resource requests, and probes, which must be added for the real service. Test the container after changing the mount setting; a hidden library that calls the API should fail visibly and trigger an architecture decision, not a silent return to the default account. If a controller really needs API access, grant only the verbs and resources required, use short-lived projected credentials, and check the audience and expiration. Cloud access belongs to a separately reviewed identity mapping rather than a broad Kubernetes Role.

apiVersion: v1
kind: ServiceAccount
metadata: {name: document-renderer, namespace: documents}
---
apiVersion: apps/v1
kind: Deployment
metadata: {name: document-renderer, namespace: documents}
spec:
  replicas: 3
  selector:
    matchLabels: {app: document-renderer}
  template:
    metadata:
      labels: {app: document-renderer}
    spec:
      serviceAccountName: document-renderer
      automountServiceAccountToken: false
      containers:
        - name: renderer
          image: registry.internal/document-renderer@sha256:REPLACE_WITH_FULL_DIGEST

Cost and verification

Separate accounts add a small amount of configuration and review work. They also make audit records easier to attribute and limit the reach of a compromised Pod. A token turned off at the Pod level does not remove other secrets supplied through environment variables, volumes, or node metadata. Inspect all credential paths. A short-lived token still grants its permissions until it expires or its trust is revoked, so avoid permissions that are wider than the work requires.

Common Mistakes

Do not run every workload as the namespace default account.
Do not mount an API token just because RBAC looks narrow.
Do not confuse a Kubernetes ServiceAccount with a cloud identity grant.

Connected lessons

Practice and check

Advanced follow-up

Projected identity tokens: reopen the file and verify its audience

devops

operations