Five applications need the same API credential. They all deploy into a Kubernetes namespace. The natural shortcut is to let each application's Helm chart create the same Secret.
Now the deployment depends on which application reconciles first. A chart can fail because a Kubernetes object already exists under another release's ownership. Another chart may overwrite it, change labels or delete it during an uninstall. Even when nothing breaks, you have made five application teams responsible for one shared platform dependency.
This is not really a secret-store problem. It is an ownership problem.
A better design starts by separating where the sensitive value lives, who defines its distribution, and which applications are allowed to consume it.
Three different responsibilities
The external secret manager stores the authoritative credential. It should support the identity and policy model you actually need, including controlled rotation and audit.
External Secrets Operator (ESO) reconciles authorized external values into Kubernetes Secrets. ESO is not itself the encrypted source of truth. If the backing store becomes unreachable, an already materialized Secret may still exist, but rotation and refresh can no longer be assumed.
Applications consume a Kubernetes Secret through a volume or environment reference. They should not need credentials to the central secret manager merely to start.
The design is simpler when a platform team owns the external mapping and Kubernetes distribution object while application teams own only their references.
Same namespace: one Secret, many consumers
Inside a single namespace, a Kubernetes Secret is a namespaced object. There should generally be one owner of its desired state.
Five applications can all reference the same Kubernetes Secret name. They do not need five copies with the same name. And Helm should not render a shared Secret from five independent releases.
With ESO, a single ExternalSecret can materialize that shared Secret inside the namespace. The applications then refer to that name in their Pod specifications.
Ownership still matters: removing the ExternalSecret or changing its target lifecycle settings may affect the generated Secret. Deletion behavior must be explicit and tested before anyone relies on it.
Across namespaces: replication is a policy decision
Kubernetes Secrets are not cluster-global values. If workloads in different namespaces need a shared external credential, they usually need a Secret instance in each namespace.
ESO provides a ClusterExternalSecret custom resource for generating ExternalSecret resources in matching namespaces. This can be a good platform-level distribution mechanism, but it is not a magic shared Secret that lives above namespaces. ESO still creates namespaced resources.
The important choice is the namespace selection policy. Label selectors are convenient, but they change the security boundary: whoever is allowed to add the matching namespace label may gain access to the distributed Secret.
That is why namespace admission, RBAC and label ownership are not implementation details. They determine who can opt a workload into a credential.
If the platform cannot reliably control selectors, an explicit namespace inventory or another approved declaration mechanism may be preferable. Do not deploy a global selector merely because the controller supports it.
The External Secrets Operator ClusterExternalSecret reference documents the API and its distribution behavior.
Do not solve ownership by making every application a controller
It is tempting to add a helper that scans application Helm values and creates ExternalSecrets for all shared dependencies. That can work, but it adds another source of desired state and another failure mode.
Before introducing a generator or custom resource, ask whether a single platform-owned resource and a clear namespace onboarding workflow already solve the problem.
A custom operator is justified when the platform needs semantics the existing controllers cannot provide, such as explicit team-level grants, auditable service-to-secret relationships or cross-project approval workflows. Its controller must still deal with upgrades, failure recovery, credentials, status and eventual consistency.
Writing an operator to avoid one YAML file is not operational simplification.
Security and recovery checks that belong in the design
A successful Secret sync alone does not prove that the overall model is safe.
- Access: Can a developer read every namespace's generated Secrets through Kubernetes RBAC?
- Enrollment: Who can apply namespace labels or request distribution of a shared credential?
- Rotation: Does the consuming application reload the value, restart or retain the old credential indefinitely?
- Staleness: What happens when the external store is unavailable at deployment or refresh time?
- Deletion: Which controller owns the target and what happens when the declaration is removed?
- Logging: Are raw values excluded from logs, diffs, alerts and support bundles?
- Recovery: Can the secret manager and its policies be recovered without depending on a Kubernetes cluster that cannot start because the manager is unavailable?
Encryption at rest and TLS in transit are necessary but insufficient if namespace admission and access policies permit unintended disclosure. These checks are part of how we review secrets management and Kubernetes access in DevSecOps engagements.
CI credentials need the same deliberate ownership and scoping. See why a GitHub Actions runner is a security boundary, not just build capacity.
What we would test before rollout
A simple integration test is more persuasive than an architecture diagram.
Create two test namespaces: one approved to receive a shared credential, one not. Deploy an ExternalSecret or ClusterExternalSecret under the platform-owned identity. Confirm only the selected namespace receives the expected resource and that workload service accounts cannot read unrelated Secrets. Rotate the value in the external store, observe reconciliation, then simulate a temporary store outage.
Finally, uninstall one application and confirm the shared Secret is still owned by the platform.
Those are acceptance tests for a proposed design, not claims that a particular customer's cluster already passed them.
The engineering decision
Shared secret distribution is a platform contract, not a chart convenience.
Use one owner for the credential mapping, grant distribution deliberately, and let multiple applications consume the namespaced Secrets they need. Prefer the smallest operating model that has clear authorization, lifecycle behavior and tests.
For teams standardizing their platform, see Big Bad Byte's DevOps and Kubernetes engineering. An implementation starts with the access model and failure cases, not a new custom controller.