Managing secrets in a GitOps workflow

WHAT THIS TESTS Whether you understand that GitOps wants everything in Git but that plaintext secrets must never go there, and whether you know concrete, safe patterns.

A GOOD ANSWER COVERS The constraint is that Git is the source of truth yet must not hold readable secrets, and base64 in a Kubernetes Secret is encoding, not encryption, so it is not safe. Common patterns: Sealed Secrets, where a controller in the cluster owns an asymmetric key pair; you encrypt a Secret with the public key to produce a SealedSecret custom resource that is safe to commit, and only the in-cluster controller can decrypt it into a real Secret. SOPS, often with age or KMS, encrypts the secret values in a file you commit, and the controller or a plugin decrypts at apply time. The External Secrets Operator takes a different approach: you commit only a non-sensitive reference, and the operator fetches the actual value at runtime from an external store like HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager, then materializes a Kubernetes Secret. Combine with RBAC and encryption at rest in etcd.

COMMON WRONG ANSWERS Committing base64-encoded Secrets and calling them encrypted, hardcoding credentials in values files, or storing plaintext in a private repo and assuming privacy equals security.

LIKELY FOLLOW-UPS Why is base64 not secure? How does Sealed Secrets handle key rotation and disaster recovery? When prefer External Secrets over Sealed Secrets?

ONE CONCRETE EXAMPLE You run kubeseal against the cluster's public key to turn a Secret holding a database password into a SealedSecret resource. That encrypted resource is committed to Git and synced by Argo CD. Only the Sealed Secrets controller, holding the private key, can decrypt it into a normal Secret inside the cluster, so the password never exists in plaintext in the repository.