ServiceAccounts

Identity for Workloads

Humans authenticate with OIDC or client certificates; pods get a ServiceAccount. Every namespace ships a default account, and pods that specify nothing use it — a frequent source of surprising 403s for apps that never opted in.

On startup, kubelet projects a token into the container at /var/run/secrets/kubernetes.io/serviceaccount. Modern clusters (1.24+) request short-lived tokens through the TokenRequest API — typically one hour, refreshed by kubelet — instead of creating permanent token Secrets.

The token identifies system:serviceaccount:<namespace>:<name> to the API server, where RBAC decides what that identity may do. The same name can also bind a cloud IAM role through workload identity integrations.

Wiring Identity Correctly

spec:
  serviceAccountName: billing-api
  automountServiceAccountToken: false   # for apps that never call the API
  containers:
  - name: app
    image: registry.example.com/billing:1.2

Create the account and its permissions:

kubectl create serviceaccount billing-api -n prod
kubectl create rolebinding billing-api-read \
  --clusterrole=view --serviceaccount=prod:billing-api

When a token mount is needed (for the API or an external audience), declare a projected volume with serviceAccountToken, setting expirationSeconds and audience explicitly. Out-of-cluster automation should prefer OIDC federation over minting long-lived static tokens.

Pitfalls and Interview Angles

Pitfall 1 — automount on everything. Any pod running the default account carries a usable token; a compromised web container inherits whatever that SA can do. Set automountServiceAccountToken: false for workloads that never call the API.

Pitfall 2 — audience mismatches. A token minted for a cloud-identity audience is rejected by the API server, which expects its own — TokenReview fails even though the signature is valid. Match audience to consumer.

Interview-ready: contrast human and workload identity, explain why Kubernetes moved to short-lived TokenRequest tokens (static Secret tokens were leaky and permanent), and list hardening moves: one SA per app, least-privilege binding, automount disabled where unused, projected tokens with explicit audiences.