Notifications
Clear all
Topic starter
08/07/2026 7:06 pm
TL;DR: Kubernetes Secrets simplify runtime credential distribution, but by default they are stored unencrypted in etcd and inherit risk from Kubernetes access controls, RBAC scope, and namespace permissions, according to Infisical. The security model only holds when teams layer encryption, least privilege, auditability, and external secret management on top of the platform defaults.
NHIMG editorial — based on content published by Infisical: What are Kubernetes Secrets?
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when Kubernetes Secrets are used without encryption at rest?
A: Without encryption at rest, the control plane stores Secret values in etcd in a form that can be recovered by anyone with sufficient API or backend access.
Q: Why do Kubernetes Secrets create more risk when RBAC is too broad?
A: RBAC is object-scoped, so a workload that can read a Secret often gets every key in that object, not just the value it needs.
Q: What do security teams get wrong about Kubernetes Secrets?
A: Teams often confuse storing a credential in Kubernetes with securing it.
Practitioner guidance
- Encrypt Secrets at rest in etcd Turn on secret encryption during cluster setup and store encryption keys in an external key management service or HSM, not on the same systems as the encrypted data.
- Split credentials by workload and environment Use separate Secret objects and service accounts for each application and environment so one compromised Pod cannot read unrelated credentials across namespaces.
- Move production credentials to an external secret store Use an external secret provider for production workloads that need audit logs, rotation discipline, and stronger lifecycle control than native cluster storage provides.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how Kubernetes Secrets are injected as environment variables, mounted as files, or used for image pulls.
- A practical comparison of native Secrets, external secret providers, and the External Secrets Operator for production use.
- More detail on encryption at rest configuration, including key handling and where the encryption material should live.
- Implementation trade-offs for secret rotation, audit logging, and multi-environment separation that platform teams need before rollout.
👉 Read Infisical's explanation of Kubernetes Secrets and production safeguards →
Kubernetes Secrets: is your cluster really protecting credentials?
Explore further
08/07/2026 7:30 pm
Kubernetes Secrets are a governance layer, not a security boundary. The article makes the default model plain: Kubernetes stores secrets for convenience, then relies on RBAC and operational hygiene to prevent misuse. That means the security outcome is only as strong as the surrounding identity controls. In NHI terms, the credential is protected by policy, not by the secret object itself. Practitioners should treat every Secret as an access-governed asset with a lifecycle, not as an intrinsically safe container.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How should organisations reduce the blast radius of secret exposure in Kubernetes?
A: They should separate credentials by application and environment, constrain service account permissions to the minimum needed, and move production secrets into an external store with audit and rotation controls. The goal is to prevent one workload from becoming a reusable bridge to unrelated systems. That is how teams shrink the blast radius of a compromise.
👉 Read our full editorial: Kubernetes Secrets still need real access controls and rotation
