Rationale
The entire premise behind GitOps is to use Git as the source of truth for infrastructure and application configuration, taking advantage of Git workflows, while at the same time, having automation that realizes the configurations described in Git repositories (GitOps operators when we are deploying to Kubernetes).
That said, both infrastructure configuration and application configurations require access to some kind of sensitive assets, most commonly called secrets (e.g. authentication tokens, private keys, etc), to operate correctly, access data, or otherwise communicate with third party systems in a secure manner.
However, storing confidential data in Git represents a security vulnerability and should not be allowed, even when the Git repository is considered private and implements access controls to limit the audience. Once a secret has been pushed in clear-text (or in an easily reversible state) to Git, it must be considered compromised and should be revoked immediately.
So, how can we overcome this limitation and provide users and customers implementing GitOps with mechanisms to provision secrets to their applications without compromising their confidentiality? There are approaches and open source projects in the Kubernetes ecosystem that address these challenges, each in their different ways. This document provides an overview of several popular options in this space.
Secrets management methodologies
There are two main architectural approaches when it comes to managing secrets in GitOps:
- Encrypted Secrets are stored within Git repositories and automation facilitates the decryption and rendering of them as Kubernetes Secrets.
- Reference to secrets are stored in Git repositories and automation facilitates the retrieval of the actual secrets based on these references. Finally the retrieved secrets are rendered as Kubernetes Secrets.
Learn more: https://cloud.redhat.com/blog/a-guide-to-secrets-management-with-gitops-and-kubernetes
