Kubernetes Service Account Token Security Audit: How to Find Overprivileged Pods and Unused Tokens Before Attackers Use Them for Cluster Escalation

Start with a complete inventory of what each service account can do:

# List all service accounts across all namespaces
kubectl get serviceaccounts --all-namespaces

# List all ClusterRoleBindings (cluster-wide RBAC)
kubectl get clusterrolebindings -o wide

# Find all ClusterRoleBindings that grant cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name == "cluster-admin") | \
  {name: .metadata.name, subjects: .subjects}'

# List all RoleBindings in all namespaces
kubectl get rolebindings --all-namespaces -o wide

For a comprehensive audit, use kubectl-who-can (a kubectl plugin) to check what each service account can do:

# Install via krew
kubectl krew install who-can

# Find who can create pods (a common privilege escalation vector)
kubectl who-can create pods --all-namespaces

# Find who can exec into pods (another escalation vector)
kubectl who-can create pods/exec --all-namespaces

# Find who can list secrets (secrets may contain credentials)
kubectl who-can list secrets --all-namespaces

Any service account that appears in the output of cluster-admin binding queries or that can create pods, exec into pods, or list secrets is a high-priority finding. Document the workload that uses this service account and evaluate whether the permission is required.

After finding overprivileged service accounts, identify which pods are using them:

# Find all pods using a specific service account
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.serviceAccountName == "my-service-account") | \
  {namespace: .metadata.namespace, pod: .metadata.name, \
   sa: .spec.serviceAccountName}'

# Find all pods running with automountServiceAccountToken not disabled
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.automountServiceAccountToken != false) | \
  {namespace: .metadata.namespace, pod: .metadata.name, \
   sa: .spec.serviceAccountName}'

Cross-reference: for each pod with an overprivileged service account, assess the attack surface:

• Is the pod internet-facing (LoadBalancer or Ingress)?
• Does the pod run user-supplied code or untrusted inputs?
• Is the pod running a known-vulnerable image version?
• Does the pod run as root (check securityContext.runAsNonRoot: false or absent)?

A pod running as root, facing the internet, running a known-vulnerable web framework, and mounted with a cluster-admin token is the highest-risk combination. Prioritize remediating these first.

Most application workloads do not need to communicate with the Kubernetes API. For those pods, disable the automatic token mount.

At the pod spec level:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  template:
    spec:
      automountServiceAccountToken: false  # Disable token mount
      containers:
        - name: app
          image: my-app:1.0

At the service account level (applies to all pods using this SA by default):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-web-app-sa
  namespace: production
automountServiceAccountToken: false

The pod-level setting overrides the service account-level setting, so you can disable at the SA level and re-enable for specific pods that do need API access.

For workloads that do need API access: scope the service account permissions to the minimum required using a Role (namespace-scoped) rather than a ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: configmap-reader
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]
    resourceNames: ["app-config"]  # scope to specific named resource

Never use * in resources or verbs for production workload service accounts.

The most common (and dangerous) pattern for Kubernetes workloads that need cloud provider access (AWS, GCP, Azure) is to mount cloud credentials as environment variables or Kubernetes secrets:

env:
  - name: AWS_ACCESS_KEY_ID
    valueFrom:
      secretKeyRef:
        name: aws-credentials
        key: access_key_id

This pattern stores long-lived cloud credentials in Kubernetes secrets, which are base64-encoded (not encrypted) by default, and mounts them in every pod replica. An attacker who reads the secret from any pod gets long-lived cloud credentials.

Workload identity federation eliminates this pattern by allowing pods to authenticate to cloud APIs using their Kubernetes service account token, exchanged for a short-lived cloud provider credential at authentication time.

AWS: EKS Pod Identity or IRSA (IAM Roles for Service Accounts)

# Create an IAM role for the service account
eksctl create iamserviceaccount \
  --name my-app-sa \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve

The pod then uses the AWS SDK which automatically exchanges the projected service account token for temporary STS credentials. No static credentials required.

GCP: GKE Workload Identity

# Bind a Kubernetes SA to a GCP service account
gcloud iam service-accounts add-iam-policy-binding \
  my-gcp-sa@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[production/my-app-sa]"

kubectl annotate serviceaccount my-app-sa \
  --namespace production \
  iam.gke.io/gcp-service-account=my-gcp-sa@my-project.iam.gserviceaccount.com

Kubernetes 1.20 introduced bound service account tokens (projected volumes) which expire and are audience-scoped. Legacy service account tokens (the secret-based tokens in older Kubernetes versions) do not expire and can be used to authenticate to any Kubernetes API server.

Check whether your cluster is using legacy long-lived tokens:

# Find all service account secret-based tokens (legacy non-expiring)
kubectl get secrets --all-namespaces -o json | \
  jq '.items[] | select(.type == "kubernetes.io/service-account-token") | \
  {namespace: .metadata.namespace, name: .metadata.name, \
   serviceAccount: .metadata.annotations["kubernetes.io/service-account.name"]}'

In Kubernetes 1.24+, secret-based tokens are no longer automatically created. If your cluster still has them from a pre-1.24 era, they are long-lived and should be audited.

For bound tokens (the current default): check that your admission controller or Pod Security Standards require projected service account tokens with an expiry. The token path in the pod is typically /var/run/secrets/kubernetes.io/serviceaccount/token, and for bound tokens the audience, expiry, and issuer are validated by the API server on each API call.

Use the kubectl auth can-i command to verify what a specific token is permitted to do:

# Test permissions of a specific service account
kubectl auth can-i --list --as=system:serviceaccount:production:my-app-sa

This lists every resource and verb the service account can perform, which is the definitive permission inventory for that account.