TL;DR: Akeyless finds that Kubernetes Secrets are base64-encoded objects stored in etcd, and External Secrets Operator shifts the source of truth to an external secrets manager while leaving applications unchanged. That improves lifecycle control, but rotation, audit, and pod refresh handling still define whether secrets are actually governed.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Akeyless's blog post: External Secrets Operator changes Kubernetes secret handling by moving the source of truth outside the cluster and tightening lifecycle control.
Why it matters: It matters because IAM and platform teams still own rotation, auditability, namespace scope, and pod refresh behaviour even after the secret backend moves out of Kubernetes.
👉 Read Akeyless's guide to Kubernetes Secrets and External Secrets Operator
Context
Kubernetes Secrets are a credential delivery mechanism, not a full secret governance model. The core issue is that the application contract stays the same while the storage and lifecycle controls underneath it may or may not improve.
External Secrets Operator bridges an external secrets manager and Kubernetes workloads by syncing values into native Secret objects. That helps teams avoid application rewrites, but it does not remove the need to govern refresh cadence, audit logging, namespace boundaries, and pod reload behaviour.
For identity and access teams, the practical question is whether the secret lifecycle is controlled at the source and consistently enforced in the cluster. If the answer is no, Kubernetes has simply moved the exposure point rather than eliminated it.
Key questions
Q: When do Kubernetes Secrets fail as a governance control?
A: They fail when teams assume base64-encoded storage is the same as lifecycle control. Kubernetes Secrets can deliver credentials into workloads, but they do not enforce rotation, auditability, expiry alignment, or pod reload behaviour. If those controls live only in policy documents, the secret is stored but not governed.
Q: Why does moving secrets to an external manager improve security in Kubernetes?
A: It improves security when the external store becomes the authoritative source for rotation, access control, and audit logging. That removes secret values from Git and shifts governance to a system designed to manage lifecycle and access policy, while Kubernetes only receives the value needed at runtime.
Q: What are the signs that secret rotation is not actually working?
A: Look for updated backend values that never appear in running pods, repeated SecretSyncedError conditions, or workloads that continue using old credentials after a sync. Those signals mean the refresh path or restart path is broken, so rotation exists in policy but not in execution.
Q: Should teams use namespaced SecretStores or a ClusterSecretStore?
A: Use namespaced SecretStores by default because they limit who can reference a secret source and where that source can write. Reserve ClusterSecretStore for genuinely shared secrets, because cluster-wide scope expands the blast radius and turns a convenience choice into a governance decision.
Technical breakdown
Why Kubernetes Secrets are a lifecycle problem, not just a storage problem
Kubernetes Secrets are base64-encoded data objects, which means the encoding layer is not encryption and does not by itself provide lifecycle governance. The real issue is that the same secret value may persist across clusters, namespaces, pipelines, and workloads longer than intended unless an external source of truth enforces rotation and revocation. ESO exists because the cluster object alone cannot guarantee drift control, expiry alignment, or auditability. The security model therefore shifts from static in-cluster storage to continuous reconciliation between the external backend and the Kubernetes Secret object.
Practical implication: Treat in-cluster Secrets as delivery artefacts and govern the authoritative secret in the external store.
How ESO reconciliation, SecretStore, and ExternalSecret split control
ESO uses three core resources. SecretStore or ClusterSecretStore defines how to authenticate to the backend. ExternalSecret defines what to fetch, where to project it, and how often to refresh. The controller then reconciles the cluster state on a polling interval, which means the secret value in Kubernetes is only as current as the last successful sync. Namespace-scoped SecretStores reduce blast radius, while ClusterSecretStore widens access across namespaces and therefore demands tighter RBAC and clearer ownership.
Practical implication: Scope SecretStore usage to the smallest viable boundary and review ClusterSecretStore as a cluster-wide privilege decision.
Why secret rotation still fails unless workloads reload
ESO updates the Kubernetes Secret object, but Kubernetes does not automatically restart pods when a Secret changes. That creates a common lifecycle gap: the secret is rotated in the backend, synced into the cluster, and still not used by the application until the pod reads the new value. Teams therefore need a restart or refresh mechanism for workloads that cannot reread secrets dynamically. This is especially important for short-lived credentials, where sync speed and application reload behaviour must line up with the credential TTL.
Practical implication: Pair ESO with a restart or reread mechanism for any workload that cannot consume updated secrets live.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secret governance now lives in the gap between backend policy and workload behaviour: moving the source of truth out of Kubernetes improves control, but it does not complete governance unless refresh, audit, and consumption are aligned. The article shows that the hardest part is not storing the value, it is proving that the value was rotated, synced, and actually used on time. The practical conclusion is that secret lifecycle control must be assessed end to end, not backend by backend.
Namespace-scoped secret delivery is a governance decision, not just an implementation choice: SecretStore and ClusterSecretStore create very different access boundaries, and ESO inherits that scope into cluster write paths. That means the real question is who can cause secrets to appear in which namespaces, and under what authentication model. Practitioners should treat store scoping as part of access governance, not as a deployment convenience.
Rotation without workload refresh is only half a control: if the secret changes in the provider but the pod keeps using an old in-memory value, the risk window stays open. This is the secret lifecycle gap the article surfaces most clearly, and it is where many programmes overestimate their maturity. The implication is that lifecycle policy has to cover secret issuance, sync, and consumer refresh as one control chain.
Ephemeral credential delivery is stronger than static secret replication, but only when the refresh interval matches the credential model: a one-hour default may be reasonable for many secrets, but it is not automatically suitable for short-lived database credentials or certificates. The operational test is whether the external secret can be refreshed before the credential expires and before application state diverges. Practitioners should align TTL, polling, and reload behaviour as a single design problem.
Kubernetes secret management increasingly looks like identity governance for non-human identities: ESO does not replace NHI governance, it makes it more visible. The article reinforces that service credentials, namespace boundaries, and audit trails are now governed assets, not incidental implementation details. Teams that already run IAM and PAM controls should extend the same lifecycle discipline to Kubernetes-backed secrets.
From our research library:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Secret lifecycle governance is now the control point: teams that only inventory Kubernetes Secrets miss the larger issue, which is whether the authoritative secret store, the refresh interval, and the pod consumption model all agree. Without that alignment, rotation policy exists on paper while workloads keep using stale credentials.
Refresh cadence has to be designed around credential reality, not operator convenience: a default polling interval is not a control objective. The operational question is whether the secret can be refreshed before expiry and whether the consuming workload can actually ingest the change without manual intervention.
Namespace isolation remains the cleanest governance boundary for multi-tenant clusters: once a shared store is granted cluster-wide reach, the secret path itself becomes a privileged control surface. Teams should use the smallest viable store scope and keep secret delivery aligned to ownership boundaries.
For practitioners
- Define the authoritative secret source Treat the external secrets manager as the system of record and reserve Kubernetes Secrets for consumption only, so rotation and revocation are enforced outside the cluster.
- Scope SecretStore access by namespace Use namespace-scoped SecretStores for tenant isolation and only promote to ClusterSecretStore when a secret truly needs cluster-wide reach.
- Match refresh intervals to secret TTLs Set refreshInterval shorter than the secret expiry window for credentials that rotate frequently, and document the interval per ExternalSecret.
- Add a pod reload path Pair ESO with a restart mechanism such as a reloader or application-side reread logic so updated Secrets are actually consumed by workloads.
- Route sync failures into operations Alert on SecretSyncedError conditions and correlate ESO logs with Kubernetes audit logs so failed syncs and stale secrets are not missed.
Key takeaways
- Kubernetes Secrets solve delivery, not governance, because encoding a value does not enforce rotation, audit, or reload behaviour.
- External Secrets Operator improves control by shifting the source of truth to an external manager, but lifecycle risk remains if workloads do not reload updated values.
- The most important design choice is not just where the secret lives, but whether backend rotation, sync cadence, and pod consumption are aligned.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article centres on secret rotation lag and stale credential exposure in Kubernetes. |
| NHI-01 — Improper Offboarding | Secret revocation and source-of-truth transfer matter when workloads or stores are decommissioned. | |
| Recommendation — Shorten secret lifetime and align refresh intervals to reduce long-lived credential exposure. Revoke and remove obsolete secret sources when workloads or namespaces are retired. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses rotation, replacement, and lifecycle handling for machine credentials. |
| Recommendation — Apply IA-5 to enforce rotation, replacement, and retirement of authenticators used by workloads. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | ESO scope and store access determine which namespaces can obtain which secrets. |
| Recommendation — Review entitlements for secret stores and limit access to the minimum namespace scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secret stores and consuming workloads need lifecycle management comparable to account governance. |
| Recommendation — Inventory and retire secret-backed identities as part of account management. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The main threat is exposure or misuse of credentials stored and synchronized through Kubernetes. |
| Recommendation — Map exposed secrets to credential-access detection and prioritise rapid revocation. | ||
Key terms
- External Secrets Operator: An External Secrets Operator is a Kubernetes integration that synchronises secrets from an external manager into the environment that consumes them. It preserves the external system as the source of truth while making fresh, referenceable secrets available to workloads. This supports rotation without rewriting policy or deployment logic.
- SecretStore: A SecretStore defines how Kubernetes authenticates to an external secrets provider within a namespace. It contains the connection and credential reference needed for sync, so it acts as the local trust boundary for a team or application namespace.
- ClusterSecretStore: A ClusterSecretStore is the cluster-scoped version of a SecretStore and can be referenced from any namespace. It simplifies shared access, but it also broadens the blast radius if access paths or RBAC are not tightly controlled.
- Secret lifecycle drift: Secret lifecycle drift is the gap between when a credential was issued and how long it remains useful in the real environment. A secret may expire on paper but still exist in code, memory, or a copied file, which extends exposure beyond the original policy decision.
What's in the full article
Akeyless's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Helm installation and CRD setup for External Secrets Operator
- Complete Akeyless SecretStore and ClusterSecretStore manifest examples
- Provider-specific auth method setup for Kubernetes JWT, AWS IAM, Azure AD, and GCP
- Production handling for pod restarts, audit logging, and SecretSyncedError alerts
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org