Topic starter
25/06/2026 1:30 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Using External Secrets Operator (ESO) with Akeyless”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Kubernetes Secrets solve delivery, not governance, because encoding a value does not enforce rotation, audit, or reload behaviour.
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
👉 Read Akeyless's guide to Kubernetes Secrets and External Secrets Operator →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
25/06/2026 10:57 am
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.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes Secrets and ESO: closing the secret lifecycle gap
This post was modified 4 hours ago by NHI Mgmt Group