Kubernetes secrets and NHI governance: what teams miss

At a glance

What this is: This is a guide to creating, encoding, encrypting, using, and monitoring Kubernetes Secrets, with a clear emphasis on secrets and non-human identity management.

Why it matters: It matters because Kubernetes secret handling is one of the most common ways NHI risk enters container platforms, and IAM teams need to connect secret hygiene, access scope, and auditability across machine and human governance programmes.

👉 Read Entro Security's guide to creating, encrypting, and monitoring Kubernetes Secrets

Context

Kubernetes Secrets are the mechanism that keeps sensitive data out of application code and Pod specifications, but that separation only helps if the surrounding governance is sound. For identity security teams, the real question is whether secrets are being treated as governed non-human identities or as convenient configuration values.

The article focuses on the operational gap between storing secrets and actually managing them across lifecycle, rotation, monitoring, and access paths. That gap is familiar to IAM and NHI practitioners because a secret is only as safe as the controls around creation, distribution, use, and revocation.

Key questions

Q: How should security teams govern Kubernetes Secrets in container platforms?

A: Treat each secret as a governed credential with an owner, scope, and revocation path. Limit who can create, read, and update secrets, encrypt them at rest, and monitor access through audit logs. The goal is not simply to store sensitive data separately, but to control where it can be used and how quickly it can be retired when risk changes.

Q: Why do Kubernetes Secrets create identity risk for workloads?

A: Because a secret is an access path, not just a storage object. If it is shared broadly, mounted in multiple places, or left long-lived, the same credential can enable lateral movement across workloads and services. That turns one configuration item into a non-human identity control problem with a much larger blast radius.

Q: What do teams get wrong about Base64-encoded secrets?

A: They confuse representation with protection. Base64 makes a value less readable at a glance, but it does not encrypt it or stop a privileged user from extracting it. Real protection depends on encryption at rest, transport security, and strict API permissions around secret access.

Q: How do organisations know if secret rotation is actually working?

A: Look for evidence that old credentials are revoked, not just replaced. Effective rotation shows up as short-lived exposure windows, no lingering use of retired values, and clean audit trails that confirm the previous secret can no longer authenticate. If access still works after a change, rotation has not really reduced risk.

Technical breakdown

Kubernetes Secrets as workload identity inputs

Kubernetes Secrets are not identity controls by themselves. They are objects that hold sensitive values such as passwords, API keys, and certificates so Pods can authenticate to other systems without embedding those values in code or manifests. In practice, the secret is an input to workload authentication, while the real control boundary sits in how the cluster stores, exposes, and audits that data. If the same secret is mounted broadly, copied into environment variables, or left long-lived, the security model weakens fast.

Practical implication: treat every secret as a governed credential with an owner, scope, and revocation path, not as a static configuration file.

Base64 encoding is not encryption

The guide correctly distinguishes encoding from encryption. Base64 makes secret values readable in a different representation, but it does not protect them from anyone who can inspect the manifest or access etcd and the API server. True protection depends on encryption at rest, transport protection, and access control around who can read or change the secret object. In Kubernetes, the storage layer and API permissions matter more than the encoding step itself.

Practical implication: validate encryption at rest and API authorisation controls before assuming a secret is protected because it is stored in Kubernetes.

Secret delivery paths expand the attack surface

Secrets can reach workloads through volumes, environment variables, and imagePullSecrets, and each path creates a different exposure pattern. Volume mounts leave material on the filesystem within the container context, environment variables may leak into logs or process inspection, and image pull credentials extend trust to registry access. The architecture is convenient, but convenience increases blast radius when one secret is shared across multiple Pods or environments. Monitoring access and usage is therefore part of the identity control, not an optional add-on.

Practical implication: choose the delivery path based on exposure tolerance and verify that access to each secret is narrowly scoped and observable.

NHI Mgmt Group analysis

Kubernetes Secrets are governed credentials, not harmless configuration values. The article treats secrets as an operational convenience, but the security reality is that each one represents a live access path into infrastructure, registries, and downstream services. That makes secret handling an NHI governance problem, not just a Kubernetes administration task. Practitioners should judge secrets by access impact, not by where they are stored.

Base64 creates visibility, not protection, and that distinction still trips up mature teams. Many programmes stop at format conversion and miss the harder controls around encryption at rest, RBAC, and audit trails. In NHI terms, that is the same mistake as treating a rotated-looking credential as a controlled credential when the underlying exposure remains unchanged. The relevant framework lens here is OWASP-NHI and NIST-CSF, because the issue is control assurance, not data formatting.

Secret delivery paths are an identity blast radius problem: when the same credential feeds volumes, environment variables, and registry access, the damage path widens beyond the original workload. That is the point where container convenience becomes identity sprawl. Teams should think in terms of blast radius, ownership, and revocation rather than secret count alone.

Monitoring secret usage is the missing governance layer in many Kubernetes estates. The guide’s emphasis on audit logs and access monitoring is well placed because lifecycle controls without observability do not prove compliance or detect misuse. The practical conclusion is that secrets governance must be measured by access patterns, not simply by the existence of a secret object.

Hardcoded and long-lived secrets remain the most predictable failure mode in containerised identity. The article’s best-practice section points to the same structural weakness seen across NHI programmes: credentials drift into code, configuration, and pipelines faster than teams can retire them. That is why secret lifecycle discipline, especially rotation and offboarding, remains the control that most directly changes risk.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means secret governance often operates without a complete inventory of who or what can authenticate.
• For a broader view of the lifecycle problem behind this, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how provisioning, rotation, and offboarding should connect.

What this signals

Secret governance is moving from point control to lifecycle control. Teams that still treat Kubernetes Secrets as a manifest-level issue will keep missing the wider problem: secrets behave like non-human identities, and they need ownership, rotation, and revocation discipline across the full workload lifecycle. The organisations that close this gap will also be better positioned to align container security with the principles in Ultimate Guide to NHIs.

Secret delivery is becoming a blast-radius question, not just a deployment question. Once credentials can be mounted into files, exposed as environment variables, or reused for registry access, the relevant control becomes where compromise can spread next. That is why the combination of access scope and monitoring will matter more than the storage mechanism itself.

Secrets that survive change are the clearest sign of governance debt. Our research shows 91.6% of secrets remain valid five days after notification, which tells you the problem is not discovery alone but the inability to retire access quickly enough. If your programme cannot prove that old values are actually dead, your rotation control is incomplete.

For practitioners

• Map every Kubernetes secret to an owner and workload scope Require an explicit business or platform owner for each secret, then record which namespaces, Pods, and external services are allowed to use it. Reassess that mapping whenever a workload, namespace, or registry relationship changes.
• Enforce encryption and access control before rollout Verify encryption at rest in the cluster storage layer and restrict API access to secret read and update operations. Do not rely on Base64 or manifest separation as a protection mechanism.
• Rotate secrets on a defined operational cadence Set rotation triggers for age, change events, and suspected exposure, then automate replacement so old values are retired instead of merely replaced in place. Tie rotation to revocation of the previous credential.
• Audit secret access through cluster logging Enable audit logging for secret creation, modification, and read attempts, then review those logs for anomalous access patterns and cross-namespace usage. Treat access review as part of secret governance, not a separate security process.

Key takeaways

• Kubernetes Secrets reduce exposure only when they are managed as governed credentials with clear ownership and revocation.
• Encoding does not equal encryption, and weak storage controls leave workload identities exposed even when manifests look tidy.
• The strongest improvement comes from tying rotation, audit logging, and access scope together instead of treating them as separate tasks.

Key terms

• Kubernetes Secret: A Kubernetes Secret is an object used to store sensitive data such as passwords, tokens, certificates, and API keys outside application code. It simplifies delivery to Pods, but it does not automatically protect the data. Security depends on storage encryption, access control, and monitoring of how the secret is used.
• ImagePullSecret: An ImagePullSecret is a credential object that lets Kubernetes authenticate to a private container registry when pulling images. It extends trust beyond the application runtime into image supply and registry access, so its scope and lifecycle need to be managed like any other non-human credential.
• Secret Rotation: Secret rotation is the process of replacing a credential with a new value and ensuring the old one can no longer authenticate. In Kubernetes environments, effective rotation includes revocation, rollout coordination, and audit evidence that the retired secret is no longer accepted.
• Secret Lifecycle: Secret lifecycle is the end-to-end governance of creation, distribution, use, rotation, and offboarding for a secret. For machine workloads, the key question is not just whether a secret exists, but whether it is owned, monitored, and retired on time.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step kubectl, YAML, and Kustomize examples for creating Kubernetes Secrets in different deployment patterns
• Practical examples of mounting secrets as volumes, exposing them as environment variables, and using imagePullSecrets
• Secret monitoring, audit logging, and anomaly detection guidance for Kubernetes environments
• Vendor-specific workflow examples for detecting hardcoded secrets in code, repositories, and collaboration channels

👉 Entro Security's full guide covers creation methods, secret delivery patterns, and monitoring details

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or maturing your IAM programme, it is worth exploring.