Kubernetes Service Account Token Theft

Service-account tokens authenticate workloads to trusted APIs

Kubernetes service account token theft turns a workload credential into control-plane access. A compromised container, vulnerable application, exposed debug endpoint, malicious dependency, or overly permissive sidecar can read a mounted token and present it to the Kubernetes API—or to another service that trusts the same issuer and audience.

Current Kubernetes service account documentation recommends TokenRequest-based projected tokens. These JWTs can carry expiry, audience, and object-binding claims, and kubelet rotates projected tokens. Legacy Secret-based service-account tokens can be long-lived and are not recommended.

Short lifetime narrows replay time but does not make use legitimate. Impact depends on the token audience, service-account RBAC, namespace and cluster boundaries, admission policy, accessible secrets, and whether the identity can create more durable access. Inventory those effective permissions before rating the incident.

Decode claims safely and preserve token provenance

Never paste a live token into a public decoder, ticket, chat, or shell history. Preserve it only when incident authority and evidence-handling policy require that; otherwise record a keyed fingerprint and decode a protected copy locally without attempting to use it.

This is an authored, redacted claim set—not a valid token:

{
  "iss": "https://kubernetes.default.svc.cluster.local",
  "sub": "system:serviceaccount:payments:reconciler",
  "aud": ["https://kubernetes.default.svc"],
  "iat": 1794331800,
  "exp": 1794335400,
  "kubernetes.io": {
    "namespace": "payments",
    "serviceaccount": {"name": "reconciler", "uid": "<redacted>"},
    "pod": {"name": "reconciler-7c9...", "uid": "<redacted>"}
  }
}

Decoding does not validate signature, audience, expiry, or object binding. Use the API server’s TokenReview for authoritative cluster validation where appropriate. Kubernetes notes that an external service performing only offline OIDC validation can accept a bound token until expiration even after the bound pod is deleted; document which validator each relying service uses.

Join API audit activity to the service account and originating pod

Kubernetes auditing documentation records requests to the API server according to audit policy. Preserve stage, audit ID, request URI, verb, user username and groups, source IPs, user agent, response status, object reference, impersonation, and request or response bodies only where policy permits. Sensitive resources require careful redaction.

Detect service-account use from new networks or user agents, activity after the bound pod ended, requests outside the workload’s normal verbs and resources, cluster-wide listing from a namespace workload, Secret reads, SubjectAccessReview discovery, token creation, role-binding changes, pod creation with privileged settings, exec or attach, and impersonation. Compare each action with workload deployment time and normal controller behavior.

Source IP is not pod identity in many clusters; NAT, nodes, proxies, and API gateways can collapse origins. Build Kubernetes audit telemetry that joins audit identity with pod UID, node, workload owner, network flow, runtime process, and deployment revision. A successful API call proves token use, not which process read it.

Invalidate the token binding and remove persistence paths

Isolate the compromised workload according to service criticality and preserve pod specification, image digest, runtime evidence, projected-volume metadata, service account, role bindings, audit events, network flows, admission decisions, and created objects. Do not rely on copying a rotating token file after the fact to reconstruct which token was used.

For a pod-bound projected token, delete and recreate the compromised pod through a trusted deployment path; Kubernetes service account administration guidance states that deleting the pod invalidates its bound tokens. Remove unauthorized role bindings, pods, Secrets, admission webhooks, jobs, and other persistence. For legacy Secret-based tokens, delete the relevant token Secret and migrate away from long-lived credentials.

Review external systems that trust the Kubernetes issuer. If they validate JWTs offline, pod deletion may not immediately end acceptance. Revoke or block at those systems, rotate other credentials exposed to the workload, and follow the incident response lifecycle through recovery verification.

Reduce token exposure and effective RBAC authority

Set automountServiceAccountToken: false for pods that do not call trusted APIs. For workloads that do, use projected tokens with an explicit audience and appropriate expiration, a dedicated service account, and narrowly scoped roles. Apply least-privilege access design; avoid wildcard verbs and resources, unnecessary Secret access, and bindings to powerful built-in roles.

Harden the pod boundary with non-root execution, read-only filesystems where feasible, restricted capabilities, seccomp, admission policy, image provenance, network policy, and separation of mutually untrusted containers. A sidecar sharing the same token volume and network context can inherit authority even if the main application is well designed.

Changing RBAC or disabling token mounts can break controllers and deployment automation. Inventory API calls, test in a non-production namespace, canary policy changes, and retain an explicit rollback path. Validate denied and allowed actions rather than assuming a pod startup proves correct authorization.

Run a bounded service-account authority exercise

Next step: choose one non-production workload. Record its service account, projected-token audience and expiry, pod UID, effective RBAC, expected API verbs, external token consumers, and audit coverage. Confirm whether the pod needs a token at all.

In an authorized test namespace, make one expected API call and one denied call, then delete the pod and verify that TokenReview rejects the old bound token. Do not print the token into CI logs or shared terminals. The durable outcome is an attributable workload identity with short-lived credentials, narrow authorization, complete audit joins, and a tested invalidation path.