External Secrets Operator pausing raises Kubernetes secrets governance risk

At a glance

What this is: External Secrets Operator’s pause exposed the operational fragility of treating a secrets-sync bridge as part of the secrets governance stack.

Why it matters: Kubernetes teams, IAM leads, and NHI owners need to separate secrets storage from secrets delivery so that one project’s maintenance status does not become a governance failure.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Infisical's guide to moving from External Secrets Operator to Infisical

Context

External Secrets Operator is a Kubernetes bridge, not a secrets manager. It reads values from an external store and materialises them as Kubernetes Secrets, which means the governance problem is really about how secrets are delivered, rotated, and consumed across cluster boundaries. When that delivery layer becomes uncertain, the risk is operational dependency, not just feature loss.

For identity teams, this is a machine identity and workload identity issue as much as a Kubernetes issue. The post is useful because it separates the storage plane from the injection plane, which is where many programmes blur accountability and assume one control can cover both.

For teams already running ESO, the practical question is not whether Kubernetes can keep working. It is whether secrets governance can remain consistent when the synchronisation component, the operator, and the surrounding release process no longer move together.

Key questions

Q: How should security teams govern Kubernetes secrets when the sync bridge is maintained separately from the secrets manager?

A: Security teams should treat the bridge as a governed dependency, not a neutral utility. The source of truth remains the external secrets manager, but the delivery layer still needs ownership, monitoring, failure handling, and lifecycle review. If that component slows or pauses, workload identity can drift even when the backend remains healthy.

Q: Why do Kubernetes secrets bridges create operational risk for NHI programmes?

A: They create risk because machine credentials are only useful if delivery, rotation, and refresh continue to work at cluster speed. A paused or stale bridge can extend credential lifetime, delay revocation, and leave workloads operating on old material. That is an identity lifecycle problem, not only a platform concern.

Q: What should teams evaluate before switching from one secrets-sync pattern to another?

A: Teams should evaluate how each pattern changes materialisation, rotation, and fallback behaviour. Native Secret sync, pod injection, and CSI mounting all create different persistence footprints and failure modes. The right choice depends on whether the priority is fewer stored copies, simpler workload consumption, or tighter control over refresh timing.

Q: Who should own the risk when a Kubernetes secrets bridge stops receiving maintenance?

A: Ownership should sit with the team accountable for workload identity and secrets lifecycle, not only platform operations. If support, patches, or release cadence stall, the business risk is stale access and delayed remediation. That makes the control a governance issue with clear accountability, not a temporary tooling inconvenience.

Technical breakdown

How external secrets bridging works in Kubernetes

External Secrets Operator sits between a cluster and an external secrets manager, then reconciles values into Kubernetes-native objects. That design keeps sensitive material out of application code and lets platform teams centralise storage while preserving Kubernetes consumption patterns. The trade-off is that the bridge becomes part of the operational trust chain. If it stalls, secrets may not refresh, workloads may drift from expected values, and automation that depends on reconciliation loses its guarantee. In practice, the bridge is a delivery control, not the source of truth.

Practical implication: treat the sync layer as a governed dependency and map who owns its lifecycle, failure handling, and recovery path.

Why operator-based secret rotation changes the control model

Operator-driven rotation can renew and re-materialise credentials without touching application code, which makes it attractive for ephemeral and dynamic secrets. But the control only works when the operator, the CRDs, and the back-end store all remain healthy and current. If maintenance slows, the control plane itself becomes a backlog point. That matters because credential validity, refresh cadence, and workload restart behaviour all depend on timely reconciliation. A delayed operator does not merely reduce convenience. It can extend secret exposure windows or leave services running on stale material.

Practical implication: tie secret freshness and rotation SLAs to the operator lifecycle, not just to the secrets backend.

Kubernetes secret injection without long-lived objects

Infisical describes two additional patterns besides native Secret sync: an agent injector that mutates pods to include a retrieval container, and a CSI approach that mounts secrets as files instead of creating Kubernetes Secret objects. Both reduce the number of persistent secret copies in the cluster, which can lower blast radius and simplify revocation. They also change operational dependencies. When secrets are fetched at runtime or mounted on demand, identity, admission, and node-level access controls must all remain aligned. The governance question shifts from where the secret is stored to how many places it is materialised.

Practical implication: decide whether your control objective is fewer secret copies, shorter lifetime, or easier rotation, then match the delivery pattern accordingly.

Threat narrative

Attacker objective: The practical objective is to preserve or exploit stale secret delivery paths long enough to weaken rotation, recovery, or workload trust.

1. entry: The weak point is not a single exploit but dependency on a small, paused maintenance surface that sits between external secret stores and Kubernetes workloads.
2. escalation: Once the bridge stops evolving, patch gaps, support gaps, and release gaps widen the time secret delivery remains exposed to operational drift.
3. impact: Workloads can continue consuming stale or unmanaged secrets, turning a maintenance pause into an availability and governance problem.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets delivery is now a governance domain, not just an implementation detail. ESO-style bridges make this visible because they sit between the secrets manager and the workload runtime. Once that bridge is treated as optional infrastructure, teams lose line-of-sight over where credentials are refreshed, who owns the reconciliation loop, and what happens when the operator slows down. The implication is that secrets governance must account for delivery mechanics, not only for storage location.

Credential persistence debt: when a cluster depends on a paused bridge, the governance problem becomes accumulated exposure time. The article’s core lesson is that a maintained secrets backend does not guarantee a maintained secret lifecycle if the sync layer is stale. That is a lifecycle failure, not a tooling preference. Practitioners should read this as a reminder that delivery latency and maintenance status directly influence blast radius.

Kubernetes secrets architecture should minimise the number of places a secret exists at rest. ESO writes secrets into native Kubernetes objects, while agent injection and CSI can reduce object persistence or eliminate it altogether. That does not remove identity risk, but it changes the containment boundary. The governance question becomes whether the cluster is acting as a storage system, a transport system, or both. Practitioners should pick the narrowest pattern that still meets workload requirements.

This is an NHI control problem because the subject is machine-issued access, not human authentication. The credentials being moved are secrets, certificates, and workload tokens, all of which fall under non-human identity governance. The fact that the bridge is open source does not change the control obligation. The implication is that teams need a clear owner for machine identity lifecycle, including dependency review, rotation assurance, and fallback design.

Bridge failure exposes a category gap in many IAM programmes. Human IAM programmes tend to assume central systems can be patched or paused without breaking access governance, but workload identity does not tolerate that assumption as easily. When delivery automation drifts, the workload still needs consistent credentials. Practitioners should therefore evaluate secrets injection paths with the same seriousness they apply to privileged access workflows.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Read more in the Guide to the Secret Sprawl Challenge for the operational patterns behind secret exposure and remediation.

What this signals

Credential delivery is becoming the real control surface. When the cluster-side bridge that injects or syncs secrets is paused, the programme can still look healthy while refresh behaviour quietly degrades. Teams should monitor not only vault posture but also operator health, CRD drift, and pod-level consumption patterns.

A practical next step is to separate persistent secret storage from transient secret materialisation in your architecture reviews. That distinction makes it easier to decide whether Kubernetes should hold a native Secret, fetch on demand through an injector, or mount credentials through a file-based path.

If your programme still treats secrets sync as a convenience layer, the maintenance pause is a warning that the category is operationally mature enough to warrant lifecycle ownership. That is especially true where workload identity, privileged access, and certificate handling converge in the same path.

For practitioners

• Map the secrets delivery chain end to end Identify every component between the external secrets manager and the pod, including operator, CRDs, injector, CSI driver, and restart logic. Assign a named owner for each hop so a maintenance pause cannot be mistaken for a harmless product change.
• Separate storage governance from runtime injection Treat the secrets manager as the source of truth and the cluster-side mechanism as a delivery control. Document which workloads rely on native Kubernetes Secrets, which use agent injection, and which mount secrets as files.
• Define fallback behaviour before a bridge slows down Create a documented path for what happens if the sync layer stops releasing updates, including manual refresh, alternate delivery patterns, and rollback criteria for workloads that cannot tolerate stale credentials.
• Reduce persistent secret copies in clusters Prefer injection or file-based mounting where workloads do not require Kubernetes Secret objects. This lowers the number of at-rest copies and narrows the places you must monitor for stale or exposed material.

Key takeaways

• A secrets bridge is part of the identity control plane when it determines how machine credentials reach workloads.
• Maintenance pauses matter because stale delivery can extend the life of secrets long after the backend remains healthy.
• Teams should reduce persistence in clusters and assign lifecycle ownership to the full delivery chain, not just the vault.

Key terms

• Secrets Delivery Layer: The secrets delivery layer is the part of the architecture that moves credentials from a trusted store into the runtime where workloads can use them. It matters because security depends not only on where secrets are stored, but on how reliably and safely they are materialised, refreshed, and revoked.
• Workload Identity: Workload identity is the machine identity a service, pod, or application uses to prove who it is to another system. In Kubernetes environments, it often depends on certificates, tokens, or injected secrets, which means lifecycle and delivery controls are as important as the credential itself.
• Secrets Materialisation: Secrets materialisation is the act of turning a stored secret into something a running workload can consume, such as a Kubernetes Secret, mounted file, or injected runtime value. The security significance is that each materialisation point creates another place where exposure, drift, or stale access can occur.
• Credential Persistence Debt: Credential persistence debt is the accumulated risk created when secrets stay present in too many places, for too long, or in systems that are hard to refresh. It is a useful way to describe how delayed rotation, poor delivery design, or stale clusters quietly extend the attack window.

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 migration guidance for teams moving from External Secrets Operator to Infisical.
• Configuration detail for the Kubernetes Operator, Agent Injector, and CSI-based delivery patterns.
• Implementation specifics for CRDs, rolling restarts, and dynamic secret handling inside Kubernetes.
• Practical consolidation guidance for teams standardising secrets management outside the cluster.

👉 Infisical's full post covers the Kubernetes migration path, operator options, and secret delivery patterns in detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.