Initial access through the application itself: a deserialization flaw, a template injection, an unauthenticated admin endpoint, or a vulnerable dependency.
The class matters more than the specific bug, because the rest of the chain is identical whichever one it was.
Break the chain. Patch and scan the workload, and terminate untrusted input at an ingress control rather than in the application.
The token is a file at /var/run/secrets/kubernetes.io/serviceaccount/token, mounted into every pod by default.
Reading it is a filesystem operation, invisible to the audit log.
What sets the blast radius is the grant behind it: a workload token holding get or list on secrets.
Break the chain. Set automountServiceAccountToken to false on workloads that never call the API server.
T0 cluster-wide secret harvesting One call returns the decoded data of every Secret in every namespace: registry credentials, database passwords, TLS private keys, and any ServiceAccount token deliberately stored as a Secret.
This is a confidentiality compromise on its own, before any RBAC takeover.
T0 list secrets
T0
list secrets Full Secret objects come back, not metadata. This includes TLS keys, imagePullSecrets, DB passwords, API keys, kubeconfigs, and any legacy or manually created ServiceAccount token Secrets, cluster-wide. Revoking the grant afterwards does not undo the read, since every credential returned stays valid until it is individually identified and rotated.
↗ Kubernetes documentation kubernetes.io/docs/concepts/configuration/secret/ Cluster-wide secret harvesting
T0
Cluster-wide secret harvesting list or watch secrets cluster-wide, or in kube-system alone, and receive every Secret's data in the response. Auto-created ServiceAccount token Secrets are gone from modern clusters, so what is harvested is whatever was deliberately stored. That is the credential material the cluster actually runs on, including registry pull secrets, database and cloud credentials, TLS private keys, and any long-lived token created on purpose. Revoking the permission afterwards does not undo the exposure. Every credential returned stays valid until it is individually identified and rotated. ↗ Kubernetes documentation kubernetes.io/docs/concepts/configuration/secret/ Break the chain. Never grant list or watch on secrets at cluster scope. Audit for it directly; it is the single highest-value grant in the cluster.
authenticate as a privileged identity Somewhere in the harvest is a token or kubeconfig for an identity with more rights than the workload had.
Authenticating with it needs no further grant, and every credential read stays valid until it is individually rotated.
Break the chain. Rotate on the assumption of full disclosure, and prefer short-lived projected tokens over Secrets that hold long-lived ones.
Sources: kubernetes.io, kubernetes.io