Service-account tokens

Bound tokens, automount off, minimal reach.

Service-account tokens are the credentials attackers most want inside a cluster, because a token is API access scoped by RBAC. How those tokens are issued and mounted determines how much a compromised pod can do with one.

Legacy vs bound tokens

Older Kubernetes auto-created a long-lived, non-expiring Secret token for every service account and mounted it into pods — a durable credential that, if stolen, worked forever and cluster-wide. Modern clusters use bound (projected) service-account tokens: short-lived, audience-scoped, tied to the pod’s lifetime, and issued via the TokenRequest API. A leaked bound token expires quickly and is narrower in scope, dramatically shrinking the value of theft. Prefer bound tokens, and avoid creating standalone long-lived token Secrets unless a specific integration truly requires one.

# If a pod never calls the Kubernetes API, give it no token to steal:
apiVersion: v1
kind: ServiceAccount
metadata: { name: frontend }
automountServiceAccountToken: false        # SA-level default
 
apiVersion: v1
kind: Pod
spec:
  serviceAccountName: frontend
  automountServiceAccountToken: false        # or per-pod
# For pods that DO need the API, rely on the short-lived projected token
# Kubernetes mounts by default in modern clusters.

Minimize the credential’s reach

Two levers reduce token risk. First, do not mount a token where it is not needed: set automountServiceAccountToken: false for workloads that never call the API, removing the credential entirely. Second, keep the service account’s RBAC minimal, so even a stolen token opens few doors. Together these mean a compromised pod either has no token or a token that can do almost nothing — the containment that keeps one foothold from becoming cluster access. Treat every mounted token as a credential an attacker may obtain, and design accordingly.