How to handle secrets securely in a public GitOps repository without leaking credentials?

All answers to this question.

The industry is moving heavily toward the External Secrets Operator (ESO). Instead of trying to encrypt secrets inside Git (like Sealed Secrets or SOPS), ESO allows you to keep your secrets in a dedicated provider like HashiCorp Vault or AWS Secrets Manager. In your Git repo, you only store a "SecretStore" and an "ExternalSecret" manifest. The ESO controller running in your cluster then fetches the actual values from Vault and injects them as standard Kubernetes Secrets. This keeps your Git history clean of sensitive data and aligns perfectly with the "declarative everything" principle of GitOps.

   Answered 2024-05-08 by Patricia Wilson

Have you considered using Mozilla SOPS with a KMS key? It allows you to keep the files encrypted in Git but still readable by the GitOps controller.

   Answered 2024-05-10 by Robert Martinez

• We tried SOPS, but managing the GPG keys across a large team became a nightmare. We really need a solution that integrates with our existing IAM roles in AWS so we don't have to manage another layer of identity. Does the External Secrets Operator you mentioned support IAM roles for service accounts (IRSA) to make the authentication process seamless?

     Commented 2024-05-12 by William Taylor

We just use the Vault Agent sidecar pattern. It’s not strictly "GitOps" in the sense that the secret isn't in Git, but it's very secure for dynamic secrets.

   Answered 2024-05-14 by We just use the Vaul

• While the sidecar works, it adds a lot of overhead. I think Patricia’s suggestion of ESO is the most "GitOps-friendly" way to bridge the gap between Git and Vault.

     Commented 2024-05-15 by Christopher Evans