Notifications
Clear all
Topic starter
08/07/2026 6:52 pm
TL;DR: At scale, the first Kubernetes operator degraded because each secrets resource carried its own connection and authentication state, creating memory pressure, rate-limit bursts, and mass-edit overhead as clusters grew, according to Infisical. The rebuild shifts to shared connection and auth objects, showing that secrets management architectures must reduce per-resource identity duplication before scale turns convenience into operational risk.
NHIMG editorial — based on content published by Infisical: Our Kubernetes Operator Didn’t Scale, So We Rebuilt It
Questions worth separating out
Q: How should teams design Kubernetes secrets operators for shared machine identities?
A: Use shared connection and authentication objects, not per-resource client state, when many workloads consume the same secret source.
Q: Why do per-resource secrets operators break down as Kubernetes clusters grow?
A: They break down because each resource carries its own connection and authentication overhead, which multiplies memory consumption and reconcilation traffic as the cluster scales.
Q: What do security teams get wrong about secrets centralization in Kubernetes?
A: They assume centralization means one store, when in practice the control plane still needs a scalable way to deliver and reconcile secrets into many workloads.
Practitioner guidance
- Refactor shared machine identity state Split connection, authentication, and secret sync into separate reusable objects so one machine identity can serve many workload resources without duplicated clients.
- Limit per-resource authentication ownership Review whether any Kubernetes secret resource still embeds host or credentials data that should live in a shared reference object instead.
- Measure reconciliation bursts after restarts Test operator behaviour during rolling restarts and pod churn to confirm it does not create a spike of simultaneous authentication calls.
What's in the full article
Infisical's full blog post covers the implementation detail this post intentionally leaves for the source:
- The exact v1 and v2 CRD structures for InfisicalSecret, InfisicalConnection, InfisicalAuth, and InfisicalStaticSecret.
- The caching and invalidation behaviour that drops a client on config change or a 401 and 403 response.
- The migration path for teams still running v1alpha1 alongside v1beta1.
- The additional support for multi-source paths and multiple targets, including Secret and ConfigMap outputs.
👉 Read Infisical's analysis of Kubernetes operator scaling for secrets management →
Kubernetes secrets scaling: what IAM teams should watch?
Explore further
08/07/2026 7:13 pm
Per-resource client replication is the hidden identity tax in Kubernetes secrets operators: When every secret object owns its own authentication and connection state, the control plane inherits the very sprawl secrets management is supposed to remove. The result is not just memory growth, but a governance burden where rotation, host changes, and steady-state reconciliation all multiply by resource count. The practitioner conclusion is that shared identity objects are a structural requirement, not an optimization.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How can platform teams tell whether secret reconciliation is actually healthy?
A: Use readiness status, stable reconciliation timing, and low reauth churn as operational signals. If a restart triggers a wave of repeated authentication attempts or requires mass edits when a host changes, the operator is not healthy at scale. Healthy secret delivery should remain observable and predictable even when workloads roll at the same time.
👉 Read our full editorial: Kubernetes operator scaling exposes secrets management tradeoffs
