Join our Newsletter — 33% off our NHI Course

Should teams centralise secrets before using GitOps for Kubernetes?

Yes, when the same credential must serve multiple apps, clusters or environments. A central secrets manager gives you one lifecycle and one revocation point, while Git only carries the declarative reference. That reduces duplication, but only if the cluster-side materialisation is tracked correctly.

Why centralising secrets fits GitOps rather than competing with it

GitOps works best when Git describes desired state and the runtime system handles sensitive material separately. Centralising secrets supports that split because the repository can reference a secret without storing the secret itself. That keeps pull requests, reviews and deployment automation focused on configuration intent, while the secrets platform owns issuance, rotation and revocation.

The practical benefit is consistency. When multiple applications or clusters depend on the same secret, a central manager prevents copy-paste drift and makes expiry or emergency revocation tractable. That also reduces the chance that teams treat Git history as a secret store, which is exactly where long-lived credentials become hard to discover and harder to retire.

A useful way to think about the pattern is that Git should carry the declarative link, not the credential payload. Centralised secrets management also fits better when applications can consume short-lived material or pull a reference at runtime rather than embedding a reusable value in manifests or environment variables.

When centralisation becomes the safer operating model

Centralisation is most defensible when the same credential is reused across environments, services or clusters, because lifecycle control matters more than local convenience. A single revocation point is especially important when a token, key or certificate would otherwise need to be hunted down in multiple places. For teams evaluating that trade-off, NHIMG’s Secrets Management Guide is the clearest starting point for the lifecycle and rotation side of the decision.

It is also the better model when the cluster is only allowed to materialise secrets temporarily. In that pattern, GitOps still controls deployment, but the cluster-side secret injection mechanism becomes an operational dependency that must be monitored, tested and audited. If that last step is weak, the architecture can look clean in Git while still failing in production.

Centralisation is usually less attractive when each workload truly needs its own isolated secret and the blast radius should be as small as possible. In that case, the key question is not whether secrets are in Git, but whether the reference path, retrieval policy and runtime permissions still enforce separation cleanly.

What usually breaks: sprawl, reuse and blind trust in the cluster

The main failure mode is secret sprawl. If teams centralise the store but then duplicate values into many namespaces, overlays or manifests, they lose most of the lifecycle benefit and create a wider exposure surface. NHIMG’s Guide to the Secret Sprawl Challenge is a strong reference for the hard part: reducing duplication without creating new leakage paths.

Another common weakness is treating the repository as the source of truth for everything except the actual bytes of the secret. That sounds disciplined, but if the cluster-side materialisation is not validated, teams can end up with stale values, failed rotations or undeleted references that outlive the intended credential lifecycle. In practice, the failure is often not GitOps itself, but the assumption that synchronisation is happening correctly.

There is also an attacker angle. Once a central secret store becomes the authoritative source for many systems, compromise of that store or its delivery path can create broad downstream exposure. The design is only as strong as the authentication and access controls on the secrets platform and the workload identity used to retrieve the material.

Risk and Threat Considerations

Centralising secrets reduces duplication, but it also concentrates trust. If the manager, its retrieval path or its operator permissions are overexposed, one compromise can affect multiple applications, clusters or environments at once. The security benefit depends on tight access boundaries and on proving that the runtime only receives the secret it is supposed to materialise.

Failure mechanism: Reused credentials, weakly isolated namespaces, or permissive cluster access can turn a tidy GitOps workflow into a high-blast-radius secret distribution channel. Attackers often target the central store or the sync mechanism because one success can unlock many downstream systems.

Impact: A single leaked key or misconfigured reference can enable lateral movement, service impersonation, or rapid re-use across environments. In practice, the organisation may not notice until rotation fails, a deployment unexpectedly succeeds with stale access, or multiple workloads begin using the same compromised secret.

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 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 — Secret Leakage GitOps secret centralisation directly addresses secret storage and leakage risk.
NHI-07 — Long-Lived Secrets The question turns on whether shared credentials should be centralised and rotated.
NHI-05 — Overprivileged NHI Centralised secrets can widen blast radius if the same credential serves many workloads.
Recommendation — Keep secrets out of Git and store them in a dedicated secrets manager. Prefer short-lived credentials and rotate shared secrets aggressively. Scope each secret to the minimum set of workloads and permissions.
OWASP ASVS V11 — Cryptography Secrets handling depends on safe storage and transport of sensitive material.
Recommendation — Protect secret material with strong cryptographic storage and transmission controls.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Central secret lifecycle, rotation and revocation map directly to credential management.
Recommendation — Enforce issuance, rotation, storage and revocation procedures for shared authenticators.

Practitioner Guidance

What to verify: Confirm that Git contains only declarative references, that the secrets manager owns rotation and revocation, and that the cluster injects values through a controlled runtime path rather than through committed manifests or shared files.

Decision rule: If one credential is shared across workloads, centralise it and design for fast revocation; if each workload can safely own its own secret, avoid unnecessary reuse and keep the blast radius narrow.

What good looks like: A change in the secret store propagates predictably, stale values are discoverable, and you can prove which runtime received which secret without exposing the secret itself. For teams aligning this with broader identity control, NHIMG’s Static vs Dynamic Secrets section is useful when deciding whether the workload should keep a reusable secret at all.

Practitioner takeaway: Centralise secrets when it improves lifecycle control and reduces duplication, but treat cluster-side materialisation as a first-class control, not an implementation detail.