Kubernetes Service Account Token Theft:
Lateral Movement Across Clusters and Cloud.

Token Basics

Every Kubernetes pod is associated with a service account. By default, this is the default service account in the pod's namespace. A JWT token for that service account is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token inside every container in the pod, unless the pod spec explicitly sets automountServiceAccountToken: false.

The token is a Kubernetes-signed JWT that authenticates the pod to the cluster's API server. Its claims include the service account name and namespace. The API server validates the token signature and applies the RBAC bindings for the service account. Every pod that does not disable auto-mounting is therefore pre-authenticated to the cluster API with whatever permissions its service account has — available to any code executing inside the container.

RBAC Escalation Paths

The damage an attacker can do with a stolen service account token depends entirely on the RBAC bindings attached to that service account. In a poorly configured cluster, several common patterns create escalation paths:

• Wildcard cluster roles: rules: [{apiGroups: ["*"], resources: ["*"], verbs: ["*"]}] — cluster admin via the service account. Any pod with this binding is a full cluster takeover if compromised.
• Secrets read access: A service account with get or list on secrets resources can read every secret in its namespace (or the entire cluster if the binding is a ClusterRoleBinding). Kubernetes Secrets store TLS certificates, database credentials, container registry credentials, and application API keys.
• Create pods permission: A service account that can create pods can create a privileged pod with hostPID: true, hostNetwork: true, and hostPath mounts — enabling container escape to the node.
• RBAC create/update permission: A service account with permission to create or modify RBAC resources can grant itself or other service accounts any permission, including cluster admin.

Cloud Environment Pivot

In managed Kubernetes environments (EKS, GKE, AKE), the integration between Kubernetes service accounts and cloud IAM creates an additional escalation surface. Both AWS EKS Pod Identity and GCP Workload Identity allow a Kubernetes service account to be mapped to a cloud IAM role — granting pods running under that service account the ability to make authenticated calls to cloud APIs.

An attacker who steals a service account token with a cloud IAM binding can request cloud credentials directly from the cloud provider's metadata endpoint, using the Kubernetes token as proof of identity. The resulting cloud credentials grant the permissions of the mapped IAM role — which may include S3 bucket access, RDS database access, Secrets Manager reads, or broader IAM permissions depending on how the role was configured.

Audit Logging Gaps

Kubernetes audit logging is the primary mechanism for detecting service account token abuse. The audit log records every API call made to the cluster API server, including the identity (service account) and source IP. Reviewing audit logs for service account API calls from unexpected source IPs is the canonical detection for token theft and use outside the pod.

The problem is that audit logging is not enabled by default in all Kubernetes distributions, and where it is enabled, the verbosity level significantly affects what is captured. Many clusters run with a minimal audit policy that logs only authentication failures and high-privilege operations — missing the reconnaissance phase (list pods, list secrets, check permissions) that precedes an actual attack.

Detection Patterns

• API calls from service accounts made from external IP addresses: A service account for a pod should only make API calls from within the cluster's IP range. Any audit log entry showing a service account authenticated from an external IP is a strong signal of token theft and external use.
• Self-subject rules review calls: Attackers commonly call selfsubjectrulesreviews or selfsubjectaccessreviews to discover what permissions they have. This is a reconnaissance signal — legitimate applications rarely need to enumerate their own permissions at runtime.
• Secret list/get calls from pods that don't normally access secrets: If a pod's service account suddenly starts reading secrets, either the application changed behaviour or the token was stolen. Both are worth investigating.
• Privileged pod creation from a service account: Any pod creation request that includes securityContext.privileged: true, hostPID, hostNetwork, or hostPath mounts from a service account that has not historically created pods should trigger immediate review.

Hardening Controls

1. Disable auto-mounting for pods that don't need cluster API access: The vast majority of application pods do not need to call the Kubernetes API. Set automountServiceAccountToken: false in the pod spec or on the service account itself. This eliminates the token attack surface entirely for those workloads.
2. Create dedicated service accounts for each workload: Never share service accounts between workloads. Each deployment should have its own service account with the minimum permissions for that workload only. This limits blast radius — a compromised pod's token only grants that workload's permissions.
3. Use Kubernetes token projection with short expiry: Projected service account tokens (enabled by default in Kubernetes 1.20+) are time-limited and audience-bound. Set expirationSeconds to a short duration (e.g., 3600 seconds) so that a stolen token expires quickly.
4. Audit all RBAC bindings regularly: Review ClusterRoleBindings and RoleBindings quarterly. Remove any binding that grants secrets access, pod creation, or RBAC modification to service accounts that do not strictly require those permissions.
5. Enable and review Kubernetes audit logs with a meaningful policy: Deploy an audit policy that captures at minimum: authentication events, secret access, pod creation, and RBAC changes. Ship audit logs to a SIEM and alert on the detection patterns above.
6. Scope cloud IAM role bindings to specific service accounts: When using EKS Pod Identity or GKE Workload Identity, bind cloud IAM roles to specific service accounts in specific namespaces, not to broad service account patterns or all service accounts.