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.
At a glance
What this is: This is a Kubernetes secrets management analysis showing that per-resource authentication and connection state caused the operator to fail at scale.
Why it matters: It matters because Kubernetes and NHI programmes both need shared identity objects and lifecycle control, not duplicated credentials embedded in every resource.
Context
Kubernetes secrets delivery becomes a governance problem when each workload resource carries its own authentication and connection state. At small scale that looks convenient, but at cluster scale it turns into duplicated identity management, memory pressure, and operational drift across otherwise identical resources.
The article argues that secrets centralisation only works when the operator architecture separates connection, authentication, and secret synchronisation. For IAM and NHI teams, the real question is not whether secrets can be synced, but whether the identity model can be reused safely across hundreds of resources without turning every change into a mass update.
Key questions
Q: What breaks when every Kubernetes secret resource carries its own credentials and endpoint state?
A: The controller repeats the same identity work across every resource, which inflates memory usage, increases authentication bursts after restarts, and makes simple changes expensive to propagate. The failure is not secret syncing itself, but the duplication of connection and authentication state at the resource layer.
Q: Why does duplicated machine identity state create operational risk in Kubernetes?
A: Because Kubernetes workloads churn constantly, any identity model that assumes stable, long-lived resources turns normal restarts into retry storms and configuration sprawl. Shared identity objects reduce that risk by making one trust boundary serve many syncs without recreating the same client over and over.
Q: How should teams redesign Kubernetes secrets governance for scale?
A: Treat connection details, authentication, and secret delivery as separate governance objects, then reference them from workload resources. That keeps rotation and endpoint changes in one place and prevents every secret object from becoming a duplicate identity record.
Q: What is the difference between per-resource secret syncing and reference-based secret syncing?
A: Per-resource syncing embeds credentials and endpoint details inside each secret object, so every object manages its own client. Reference-based syncing pulls those shared details into reusable objects, which lowers memory pressure, reduces update overhead, and creates a cleaner lifecycle boundary for machine identity.
Technical breakdown
Why per-resource authentication breaks Kubernetes secrets scaling
The first design embedded host, credentials, scope, and target secret details inside each Kubernetes secret resource. That means every resource instantiated its own client, so the controller repeated the same authentication and connection work for every sync. In a small deployment that is tolerable. In a cluster with many resources, the pattern multiplies memory consumption, increases controller churn, and creates bursty authentication behaviour when pods restart or reconcile together. The architecture problem is not secrets delivery itself, but identity duplication at the resource layer.
Practical implication: collapse repeated connection and authentication state into shared objects instead of copying it into every secret resource.
How shared connection and auth objects change the control plane
The revised operator splits connection, authentication, and secret sync into separate custom resources. A secret resource now references a shared connection and a shared auth object, so the controller can cache clients by identity instead of by resource. That changes scaling behaviour in two ways. First, one identity can serve many secret syncs without creating many clients. Second, a host or credential change is handled in one place rather than edited across every secret definition. This is a structural control-plane simplification, not just a performance tweak.
Practical implication: model secret access as reusable identity primitives so configuration changes do not require per-resource edits.
Why Kubernetes operators need lifecycle-aware identity reuse
Kubernetes workloads restart, roll, and reschedule far more often than persistent infrastructure such as a VM or VPS. A secrets operator that assumes long-lived, stable identity boundaries will therefore overreact to normal cluster behaviour. The result is not only memory overhead, but also authentication storms, rate limiting, and slow reconciliation after failure. Shared identity objects reduce that lifecycle mismatch because they let the controller reuse a machine identity across many resources while still centralising policy and audit points. That is the right pattern for elastic infrastructure.
Practical implication: design identity reuse around workload lifecycle churn, not around the illusion of a stable single resource per secret.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Per-resource identity duplication is the real scaling failure: the first operator did not fail because secrets management is inherently unscalable, but because each resource carried its own identity and connection state. That design creates unnecessary client replication, memory pressure, and mass-edit overhead as Kubernetes resources multiply. The implication is that identity architecture must be deduplicated before operational convenience collapses under cluster growth.
Secrets centralisation only works when the control plane is reference-based: separating connection, authentication, and sync is more than a design preference. It turns secrets delivery into a reusable identity model, which is the only sustainable way to manage large Kubernetes estates where hundreds of resources may point to the same upstream secret source. Practitioners should treat shared identity objects as the governance unit, not each individual secret resource.
Kubernetes exposes a lifecycle assumption that persistent infrastructure hides: the operator originally behaved as if one resource equalled one durable identity boundary. Kubernetes invalidates that assumption because workloads restart, reschedule, and reconcile continuously. The implication is that NHI governance for Kubernetes must be built around reusable credentials, cached trust state, and centralised revocation points rather than per-object authentication fragments.
Identity blast radius: duplicated auth state expands both the operational and governance blast radius of a simple configuration change. A single host update or credential rotation should not require editing every downstream secret resource. Practitioners should judge Kubernetes secrets tooling by how much identity state it repeats, because repeated state is where scale problems and governance drift begin.
Lifecycle-aware secret governance is now a platform requirement: Kubernetes operators need to assume churn, not stability, and they need to make rotation, invalidation, and reconciliation cheap. This article shows that the architecture decision is whether the controller owns one identity per resource or one identity per trust boundary. Practitioners should standardise on the latter to keep secrets governance auditable and operable.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
What this signals
Identity deduplication is the hidden scaling control for Kubernetes secrets. Once a secrets operator starts copying connection and authentication state into every resource, the control plane becomes the problem it was meant to solve. Platform teams should look for architectures that centralise trust boundaries without replicating them per workload.
Kubernetes makes lifecycle churn visible, which is why secrets tooling built for persistent infrastructure often fails the first serious scale test. The practical signal is simple: if a controller cannot survive rolling restarts without authentication storms or mass edits, its identity model is too granular.
Shared machine identity objects: this article reinforces that the governance unit should be the shared trust boundary, not the individual secret resource. That shift is what keeps secrets management auditable when clusters expand and configuration changes become frequent.
For practitioners
- Define shared connection objects Separate upstream endpoint configuration from individual secret sync resources so host changes do not require editing every workload definition.
- Reuse shared authentication objects Make one machine identity usable by many secret resources so the controller can cache by identity instead of instantiating a client per resource.
- Audit CRDs for duplicated identity state Check whether credentials, host details, and secret scope are embedded in each resource, then refactor those fields into reusable references.
- Monitor reconciliation after restarts Watch for authentication bursts, memory growth, and rate-limit retries when pods restart or controllers reschedule across large clusters.
- Plan migrations away from monolithic secret resources Treat per-resource secret definitions as a transition pattern and move toward split connection, auth, and sync resources before scale forces the change.
Key takeaways
- The core problem is duplicated authentication and connection state, which turns a convenient Kubernetes secret pattern into a scaling liability.
- The redesign succeeds by moving identity and endpoint data into shared references, reducing memory pressure and mass-edit overhead.
- For practitioners, the lesson is to govern secrets around reusable trust boundaries so scale does not force operational workarounds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Per-resource credentials and clients replicate identity state across many secret objects. |
| NHI-07 — Long-Lived Secrets | The article focuses on rotating and reusing machine identity state without mass-editing every secret. | |
| Recommendation — Consolidate repeated trust boundaries into shared NHI objects instead of embedding them in every resource. Reduce lifecycle friction by centralising secret and credential references so rotation touches one object, not hundreds. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The operator redesign changes how machine authenticators are stored, reused, and refreshed. |
| Recommendation — Apply IA-5 to govern credential reuse, refresh, and invalidation through shared identity objects. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling which secret resources may use which upstream identities. |
| Recommendation — Align secret references to PR.AA-05 so access and entitlement boundaries stay explicit and reusable. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article centers on how machine credentials are handled, reused, and protected in a cluster. |
| Recommendation — Map reusable secret architecture to TA0006 and look for credential handling paths that expand exposure. | ||
Key terms
- Kubernetes Operator: A Kubernetes Operator is automation that manages application or platform tasks using Kubernetes-native patterns. It can handle day-2 operations such as scaling, upgrades, and certificate rotation. Operators reduce manual intervention by continuously reconciling the cluster toward the desired state defined by the team.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Reference-Based Architecture: A reference-based architecture stores shared configuration and identity state once, then lets many resources point to it. For secrets governance, that reduces duplication, makes changes easier to control, and prevents the same connection or credential details from being copied into every resource.
- Secrets Sync: Secrets sync is the controlled movement of credentials from one authoritative store into another system for downstream use. The governance challenge is preserving ownership, rotation, and revocation while preventing duplicate secret lifecycles that create drift and expand blast radius.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org