Secrets Management vs. GitOps
GitOps' entire premise is to use Git as the source of truth for infrastructure and application configuration
Automation is in place (ArgoCD) to translate Git’s source of truth into infrastructure applications inside OpenShift
Storing confidential data (passwords, private keys, secrets, authentication tokens, …) in Git is fundamentally a security vulnerability and should be avoided (even if the Git repository is private and access control is in place)
Once confidential data is out in clear-text (or in some reversible form), it has to be considered as compromised
Approaches
There are two fundamental approaches to manage secret material within a GitOps context
Encrypted Secrets stored inside Git repositories
References to Secrets stored inside Git repositories and the actual secret is stored somewhere else
Encrypted Secrets
Secrets are stored in an encrypted form inside the Git repository
Automation and helper tools do the decryption to create Kubernetes secrets from them
A number of projects exist that implement this approach:
These projects provide an easy way to encrypt and decrypt the secrets, and make sure that only authorized users can access them. The encryption method and key management should be considered carefully as they are important to ensure the security of the secrets.
| You should evaluate and choose the right project that fits your specific use case and requirements. |
References to Secrets
This approach requires two main parts:
A Secret Management System (HashiCorp Vault, Conjur, Confidant)
A controller that retrieves the secret from the Secret Management System and translates it to a Kubernetes Secret or injects it into the Pod directly (External Secrets Operators, Kubernetes Secrets Store CSI Driver, Vault Agent Injector)
Secrets are uploaded/created directly into the Secret Management System
References to secrets are stored in Git
A controller reads the references to secrets and translates them into Kubernetes secrets
