Notifications
Clear all
Topic starter
08/07/2026 7:03 pm
TL;DR: External Secrets Operator paused new releases, patches, and support in August 2025, which exposed how many Kubernetes teams depend on a thin bridge layer between clusters and external secrets managers, according to Infisical. The real issue is not one project’s cadence, but whether secrets governance can survive when the control plane for injection and rotation becomes a single point of operational dependency.
NHIMG editorial — based on content published by Infisical: External Secrets Operator is paused. What’s next?
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.
Questions worth separating out
A: Security teams should treat the bridge as a governed dependency, not a neutral utility.
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.
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.
Practitioner guidance
- 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.
- Separate storage governance from runtime injection Treat the secrets manager as the source of truth and the cluster-side mechanism as a delivery control.
- 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.
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.
👉 Read Infisical's guide to moving from External Secrets Operator to Infisical →
External Secrets Operator pausing: what should Kubernetes teams do now?
Explore further
08/07/2026 7:27 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: External Secrets Operator pausing raises Kubernetes secrets governance risk
