Notifications
Clear all
Topic starter
25/06/2026 1:30 am
TL;DR: Kubernetes Secrets are base64-encoded objects that do not provide native object-level encryption, and External Secrets Operator shifts the source of truth to an external secrets manager while leaving applications unchanged, according to Akeyless. That changes the governance problem from in-cluster storage to lifecycle, rotation, audit, and restart handling across the cluster.
NHIMG editorial — based on content published by Akeyless: Kubernetes Secrets and the External Secrets Operator
By the numbers:
- The project is hosted under the external-secrets GitHub organisation and has accumulated over 4,000 stars and hundreds of contributors, making it one of the most actively maintained Kubernetes ecosystem projects for secrets management.
- 15–30 minutes is the recommended refresh interval for, secrets that rotate frequently, such as database credentials and short-lived tokens.
Questions worth separating out
Q: How should security teams govern Kubernetes Secrets in multi-tenant clusters?
A: Treat Kubernetes Secrets as a delivery mechanism, not the system of record.
Q: Why do Kubernetes secret rotation projects fail if pods are not reloaded?
A: Because changing the Secret object does not guarantee the application reads the new value.
Q: What do teams get wrong about External Secrets Operator refresh intervals?
A: They often treat refreshInterval as a generic polling setting instead of a control tied to credential lifetime and provider load.
Practitioner guidance
- Default to namespace-scoped SecretStores Use SecretStore per team namespace and only promote to ClusterSecretStore when the same secret genuinely serves multiple tenants.
- Shorten refresh intervals to match real TTLs Set refreshInterval based on the actual lifetime of the upstream secret, not the convenience of a default.
- Pair sync with a pod reload mechanism Assume that an updated Kubernetes Secret will not be consumed automatically by every application.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step YAML manifests for SecretStore, ClusterSecretStore, and ExternalSecret setup
- Provider-specific authentication details for Akeyless Kubernetes JWT, AWS IAM, Azure AD, and GCP
- Production tuning guidance for refreshInterval values and failure handling
- Audit and restart integration patterns for secrets that must be reloaded at runtime
👉 Read Akeyless's guide to syncing Kubernetes Secrets with External Secrets Operator →
External Secrets Operator in Kubernetes: are your secrets actually governed?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 10:57 am
Base64-encoded Kubernetes Secrets are not a governance control. They are a transport format for application compatibility, not a lifecycle boundary for credentials. The real failure is assuming that storing a secret in a native Kubernetes object makes it managed. It does not, which is why NHI programmes need external source-of-truth controls, not just in-cluster copies.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: Which frameworks are most relevant for Kubernetes secret governance?
A: NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 are the most direct fits because this problem spans protection, access control, and credential lifecycle. In practice, teams should use them to align secret storage, rotation, and audit logging with the cluster’s identity model.
👉 Read our full editorial: Kubernetes Secrets and ESO: closing the secret lifecycle gap
