Should organisations store Kubernetes secrets in the cluster or inject them at runtime?

For most high-value credentials, runtime injection is safer because it avoids leaving secrets persistently stored in the cluster. The decision still depends on audit, rotation and revocation processes outside Kubernetes. If those controls are weak, runtime delivery reduces exposure but does not solve governance by itself.

Should you store Kubernetes secrets in the cluster or inject them at runtime?

Why cluster storage changes the risk profile

Storing secrets inside Kubernetes makes the cluster itself part of the trust boundary for sensitive material. That can be acceptable for low-risk or low-impact secrets, but it increases blast radius because cluster compromise, overly broad read access, backup exposure, and accidental replication can all turn into credential exposure. A runtime model shifts that burden to the delivery path instead of the cluster datastore.

Runtime injection is especially relevant when the secret is a bearer credential, API key, token, or database password with direct production impact. In those cases, reducing persistence matters more than convenience, because any long-lived copy inside the cluster increases the number of places a secret can leak or be recovered from. Secrets Management Guide is a useful companion for understanding when secret injection becomes part of a broader move toward secretless or short-lived access.

Some teams treat Kubernetes Secrets as configuration rather than sensitive identity material, which is where the trouble starts. Once a secret can authenticate to another system, it should be managed as credential material with lifecycle, rotation, revocation and access review expectations. That is why cluster storage and runtime delivery are not just implementation choices, they are different security postures.

What runtime injection does, and does not, solve

Runtime injection reduces how long a secret sits at rest in the cluster and can lower exposure from accidental disclosure through manifests, Git history, etcd snapshots, or cluster-wide reads. It works best when paired with short-lived credentials, per-workload scoping, and a reliable renewal path. Ultimate Guide to NHIs — Static vs Dynamic Secrets is directly relevant here because the real improvement usually comes from making the credential ephemeral, not just moving where it is first written.

But runtime injection is not a substitute for governance. If a team cannot prove who can mint, refresh, revoke, or audit those credentials, then the secret may be harder to find but not meaningfully safer to operate. The operational question is whether the injection mechanism is backed by trustworthy identity, reliable expiry, and rapid revocation when a workload is compromised.

For Kubernetes specifically, the surrounding controls matter as much as the secret store. Service account design, workload identity, token projection, RBAC, and secret handling all affect whether injected credentials stay bounded to the workload that needs them. Kubernetes NHI Security Guide covers the broader control set that makes runtime credential delivery viable without turning the cluster into a credential warehouse.

When cluster storage is still acceptable

Cluster storage is not automatically wrong. It can be reasonable for low-impact secrets, development environments, tightly controlled internal workloads, or cases where operational simplicity outweighs exposure risk. The key test is whether the secret’s compromise would materially affect another system, customer data, or a privileged production path.

If the secret has a long lifetime, broad reuse, or can unlock multiple downstream systems, cluster storage becomes harder to justify. In those cases, the safer pattern is usually short-lived issuance at runtime, with the credential constrained to one workload, one environment, and one purpose. Guide to the Secret Sprawl Challenge is useful for understanding how persistent storage, duplicated copies, and ad hoc handling create avoidable exposure over time.

The practical line is simple: if the secret would still be valuable after compromise, treat persistence as a liability. If the secret is truly low sensitivity and easy to rotate, cluster storage may be operationally fine, but only with clear ownership and monitoring.

Risk and Threat Considerations

Persistent cluster storage creates an attractive compromise path because a single read failure, backup leak, or misconfigured access rule can expose many credentials at once. Attackers commonly target the easiest secret source first, then reuse it for lateral movement, registry access, or access to external services.

Failure mechanism: The cluster becomes a durable secret repository, so compromise of the control plane, etcd, backup system, CI pipeline, or an overprivileged operator account can expose credentials well beyond the workload that uses them.

Impact: Secret theft can lead to production access, data exposure, registry compromise, or downstream identity abuse, and it often persists until every affected credential is rotated and every copy is found.

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 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Secret lifecycle and rotation are central to where Kubernetes secrets should live.
	AC-6 — Least Privilege	Kubernetes secret handling should limit which workloads and operators can read credentials.
	AU-2 — Event Logging	Auditability matters when secrets are injected at runtime and must be traceable.
Recommendation — Use IA-5 to enforce rotation, expiry, and revocation for runtime-delivered credentials. Apply AC-6 to restrict secret access to the minimum required workload and administrators. Use AU-2 to log secret issuance, access, and revocation events.
ISO/IEC 27001:2022	A.5.15 — Access control	The choice between storage and injection hinges on controlled access to sensitive secret material.
	A.8.24 — Use of cryptography	Secret handling often depends on protecting credentials in transit and at rest.
Recommendation — Define and enforce access rules for stored or injected secrets under A.5.15. Apply A.8.24 to protect secret delivery and stored secret material with strong cryptography.
CIS Controls v8	CIS-6 — Access Control Management	Secret storage decisions depend on limiting access to sensitive credentials and rotating them quickly.
Recommendation — Use CIS-6 to restrict who can read secrets and to remove excess access promptly.
OWASP ASVS	V14 — Data Protection	Stored secrets and runtime-delivered secrets both require protection as sensitive data.
Recommendation — Apply V14 to protect credential material throughout storage and delivery paths.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Kubernetes secret storage directly affects the chance of credential leakage.
	NHI-07 — Long-Lived Secrets	Runtime injection is most valuable when it shortens secret lifetime materially.
Recommendation — Use NHI-02 to reduce secret leakage by minimizing persistent secret copies. Use NHI-07 to replace long-lived Kubernetes secrets with short-lived credentials.

Practitioner Guidance

What to prioritise: Treat runtime injection as the default for high-value credentials, but only if you can also prove tight TTLs, ownership, rotation, and revocation. If those four controls are weak, the exposure reduction is real but incomplete.

What to verify: Confirm where the secret originates, who can mint it, how it is renewed, and how fast it can be revoked after a workload or cluster compromise. Also verify that the workload gets only the minimum credential scope needed for its task.

Common mistake: Teams often focus on whether Kubernetes can store the secret securely enough and ignore the bigger question of how many durable copies, operators, and backup paths now need to be trusted. That is usually where the risk accumulates.

Practitioner takeaway: The safer design is the one that minimizes secret lifetime and copy count while preserving a reliable recovery path when rotation or revocation is needed.