How should teams manage secrets in GitOps workflows without breaking declarative control?

Teams should treat Git as the source of truth for desired state, but keep secret values out of plaintext repositories. The strongest pattern is to store references or encrypted material in Git, then retrieve or inject secrets at deployment time through a dedicated secret manager. That preserves traceability, supports rotation, and reduces the operational friction that appears when secrets and deployments are tightly coupled.

Why This Matters for Security Teams

GitOps works only when the repository accurately represents desired state, but secrets are different from ordinary configuration because their value is sensitive, mutable, and high impact if exposed. The practical challenge is not whether Git can track a secret reference, but how to preserve auditability, rollout consistency, and rollback safety without turning the repo into a credentials store. NHI Management Group’s research on the Guide to the Secret Sprawl Challenge shows how quickly secret handling fragments when teams improvise around deployment tooling.

The strongest teams keep Git declarative for intent, then move secret material into a dedicated control plane that handles encryption, access policy, and rotation. That pattern reduces the pressure to “just commit it for now,” which is how secret sprawl begins. It also fits what security guidance has been pushing toward: visible state in Git, protected secret material outside Git, and policy checks that stop insecure references before they reach production. The OWASP Non-Human Identity Top 10 is useful here because GitOps pipelines are full of machine identities, tokens, and automation paths that become attack paths when secret handling is weak. In practice, many teams discover the weakness only after a token leak or failed rotation has already interrupted delivery.

How It Works in Practice

A workable GitOps secret pattern separates three concerns: declaration, retrieval, and enforcement. Git should describe what the application needs, not embed the secret itself. That can mean a sealed reference, an encrypted blob, or a pointer to a vault path. At deployment time, the controller or platform agent resolves the value from a secret manager, then injects it into the workload only for the lifetime required.

This is where declarative control stays intact: the desired state still includes the fact that a service needs a database credential, but the secret value lives under a different security boundary. Current guidance suggests that the secret manager should own rotation, access logging, and revocation, while Git should own review, change history, and policy checks. NHI Management Group’s 2025 State of NHIs and Secrets in Cybersecurity highlights how duplicated and exposed secrets become a lifecycle problem, not just a storage problem.

• Store references, not plaintext, in Git.
• Use short-lived tokens or injected credentials where possible.
• Bind retrieval to workload identity, not shared human access.
• Rotate centrally in the secret manager, not by editing manifests manually.
• Validate references in CI so broken secret paths fail before merge.

In environments that use external secret operators, the controller can reconcile the reference and keep the live secret in sync without exposing the value in Git. That preserves traceability while limiting blast radius. These controls tend to break down when teams copy the same secret into multiple clusters or namespaces because rotation then becomes inconsistent and revocation becomes incomplete.

Common Variations and Edge Cases

Tighter secret control often increases platform complexity, so teams have to balance developer speed against operational discipline. The tradeoff is most visible in local development, preview environments, and emergency hotfixes, where engineers want fast access but the production pattern should not be weakened just to save time.

There is no universal standard for this yet, but best practice is evolving toward a few common variants. Some teams encrypt secrets in Git and decrypt them only inside the cluster. Others keep only vault references in Git and let admission or sync controllers materialise the secret at runtime. Both can work, but the important test is whether the repository still remains auditable without becoming a storage location for usable credentials.

Edge cases usually involve shared secrets, legacy applications that cannot read from a manager, or pipelines that need temporary credentials to reach external systems. In those cases, limit scope aggressively and prefer ephemeral issuance over long-lived static values. The Ultimate Guide to NHIs — Static vs Dynamic Secrets helps frame why TTL, revocation, and workload binding matter more than convenience when automation is involved. For teams trying to harden the broader delivery chain, the CI/CD pipeline exploitation case study is a useful reminder that secret handling and pipeline trust are inseparable.

The safest rule is simple: if a secret can be recovered from Git without a separate trust decision, the workflow is no longer truly declarative, it is just conveniently exposed.

Related resources from NHI Mgmt Group

• How should teams migrate from Sealed Secrets to an external secrets manager in Kubernetes GitOps workflows?
• How should security teams restrict third-party access without breaking essential vendor workflows?
• How should teams manage IAM end-of-life without breaking access control?
• How should security teams manage policy deletions in production authorization systems without breaking access control integrity?