How do you secure secrets in a GitOps repository?

WHAT THIS TESTS: This question evaluates whether you understand the core GitOps principle that Git serves as the source of truth for declarative infrastructure and application configuration, while recognizing that storing confidential data in Git represents a security vulnerability even when repositories are private and implement access controls. The interviewer wants to see that you can distinguish between configuration state and sensitive credentials, and that you know practical patterns for keeping secrets out of plaintext version control without breaking automated GitOps reconciliation.

A GOOD ANSWER COVERS: A good answer hits three things in order. First, encrypting secrets at rest inside the repository using tools like Mozilla SOPS or Bitnami Sealed Secrets, which allows manifests to be stored in Git while ensuring that only the target cluster or specific keys can decrypt the actual values. Second, referencing external secret management systems such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Cloud KMS from the declarative manifests, then relying on an operator like External Secrets Operator or the GitOps controller itself to inject those values into the cluster at runtime without ever writing plaintext to Git. Third, leveraging native capabilities of the GitOps operator to generate or reconcile secrets outside of version control, for example by using templating, post-rendering hooks, or operator-managed secret generation. You should also mention that rotation, auditing, and least-privilege access policies must accompany whichever technical approach you choose.

COMMON WRONG ANSWERS: The most common wrong answer is claiming that a private repository with role-based access control is sufficient protection for plaintext secrets. Another red flag is suggesting manual secret application steps outside of the GitOps pipeline, which breaks the declarative source-of-truth model. Candidates also stumble by confusing config maps with secrets, or by proposing base64 encoding alone, which is not encryption and is trivially reversible.

LIKELY FOLLOW-UPS: An interviewer might push on key rotation strategy and how you automate it without editing Git state. They may ask how you handle secret drift if someone modifies a secret directly in the cluster, or how you audit access when secrets are injected from an external vault. You might also be asked to compare the tradeoffs between encrypted Git storage and external secret stores in terms of blast radius, availability, and disaster recovery.

ONE CONCRETE EXAMPLE: Suppose you are running Argo CD or Flux on Amazon EKS. You could store a SealedSecret custom resource in Git that encrypts a database password for a specific namespace. Argo CD reconciles the SealedSecret object, the cluster-side controller decrypts it into a standard Kubernetes Secret, and your application consumes it. Alternatively, you could commit a SecretStore manifest pointing to AWS Secrets Manager; the External Secrets Operator fetches the password at runtime and creates the Kubernetes Secret automatically. In both cases, the Git repository never contains the plaintext password, satisfying the requirement that confidential data should not be allowed in Git even when access controls exist.

Source: redhat.com