Secret-based service account tokens increase credential sprawl and leave more long-lived credentials lying around than necessary. Kubernetes 1.26 reduces that exposure by preferring TokenRequest-based projected volumes, warning on auto-created secret tokens, and purging unused ones. The practical failure is not just extra clutter, but a wider attack surface and weaker control over credential lifecycle.
Why auto-generated secret tokens break the Kubernetes security model
When service account tokens are still created and mounted as long-lived Secrets, Kubernetes keeps handing workloads a credential that behaves more like a static secret than a bounded workload token. That weakens the intent of legacy service account token handling and keeps unnecessary credentials alive far beyond the workload’s actual need.
The architectural problem is not just storage format. Auto-generated Secret tokens expand credential sprawl, make inventory and revocation harder, and preserve a reusable bearer token in places where projected bound tokens would be narrower, shorter-lived, and tied more closely to a specific pod lifecycle. That is why Kubernetes moved toward TokenRequest-based projected volumes and away from secret-backed defaults.
With secret-backed tokens, the control boundary is also weaker. A token sitting in a Secret can be copied, mounted, or accidentally retained even after the workload that first used it is gone, which increases the chance that access outlives the pod, the deployment, or the original intent of the grant.
What changes operationally when projected bound tokens replace Secrets
Projected bound tokens change the operational failure mode from “credential persists unless someone cleans it up” to “credential expires and is reissued for the workload context.” That materially improves lifecycle control because the token is issued through the service account administration model rather than left as a durable object in the cluster.
The practical benefit is tighter blast-radius control. A projected token is meant to be short-lived and pod-bound, so compromise has a smaller useful window and a cleaner revocation path. In contrast, auto-created Secret tokens often survive configuration drift, stale deployments, and cleanup gaps that are common in busy clusters.
This also affects visibility. Secret-based tokens create more places where credentials can exist, which makes it harder to answer basic questions such as which workloads still hold access, which tokens are still valid, and whether a credential is present because it is required or just because it was once auto-created.
- Projected tokens reduce the amount of durable credential material a cluster must manage.
- They improve rotation and expiry behavior without depending on manual Secret cleanup.
- They make accidental reuse of stale workload credentials less likely.
Risk and Threat Considerations
Secret-backed service account tokens increase the chance that a bearer credential will be exposed, copied, or reused after it should no longer be trusted. The main risk is not theoretical clutter, but a wider attack surface with more long-lived tokens available for abuse if a pod, namespace, CI pipeline, or cluster object is compromised.
Failure mechanism: auto-generated tokens persist as Secrets, so they can outlive the workload, remain valid longer than necessary, and be recovered from places where projected bound tokens would have been short-lived and more tightly scoped. That creates a straightforward credential-theft and replay path.
Impact: attackers or internal misuse can obtain durable API access, move laterally through the cluster, and retain access even after the original workload is replaced. Operationally, teams also lose confidence that service account credentials are current, which slows incident response and makes revocation less deterministic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Lifecycle | Service account token Secrets are workload credentials with lifecycle and rotation risk. |
| NHI-02 — Least Privilege and Access Scope | Token persistence widens blast radius when workload credentials outlive their need. | |
| NHI-05 — Discovery and Inventory | Unused auto-generated tokens increase credential sprawl and reduce visibility. | |
| Recommendation — Prefer short-lived projected tokens and remove auto-generated credential Secrets. Scope service account access tightly and minimise token reuse across workloads. Inventory service account tokens and purge unused credential objects. | ||
| CIS Controls v8 | 6.3 — Access Control Management | This is an access-path reduction problem caused by lingering workload credentials. |
| 5.3 — Account Monitoring and Control | Token lifecycle drift requires monitoring and revocation of stale credential objects. | |
| 8.2 — Audit Log Management | Credential use and cleanup need auditability when tokens persist beyond workload life. | |
| Recommendation — Remove unnecessary service account token Secrets and enforce least-privilege access. Monitor service account credential creation and revoke stale tokens promptly. Log service account token issuance and investigate lingering credential use. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Least Privilege for Resource Access | Projected tokens align with minimizing standing access for workloads. |
| 3.3 — Continuous Authentication and Authorization | Short-lived projected tokens better support continuous revalidation than static Secrets. | |
| Recommendation — Apply least-privilege access to service account credentials and reduce standing trust. Use short-lived workload tokens that can be revalidated and rotated continuously. | ||
Practitioner Guidance
What to verify: confirm that the cluster is using TokenRequest-based projected volumes for pods that do not require legacy Secret tokens, and check whether any auto-generated service account token Secrets are still being created or left unused. If a workload truly depends on a legacy token path, treat that as an exception requiring explicit ownership and expiry review.
What to prioritise: focus first on workloads with broad namespace reach, CI/CD access, or cluster-admin-adjacent permissions, because those tokens create the largest blast radius if they persist. The key judgement is whether the token must exist as a durable object at all, not whether it is merely convenient to mount.
Practitioner takeaway: the control objective is to make service account access ephemeral by default, because every unnecessary long-lived token is both a cleanup problem and a standing compromise path.
Related resources from NHI Mgmt Group
- What breaks when Kubernetes service account tokens are mounted by default in AI workloads
- How should security teams reduce the risk of Kubernetes service account tokens?
- What breaks when agents are given personal access tokens and service account keys directly?
- What breaks when service accounts still rely on long-lived secrets?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
