We run AWS and Kubernetes deployments with plain Helm from Jenkins, without a GitOps tool. Our Helm values.yaml currently contains hardcoded environment-variable secrets and is stored only on the Jenkins server. We want to move the file into Git for versioning, but we do not want plaintext secrets in the repository. One option is git-crypt, which would encrypt the file in the repository and allow authorized users or automation to decrypt it. Are there important operational gotchas with git-crypt? Since we already use AWS, would AWS Secrets Manager or Parameter Store with External Secrets Operator be a better low-maintenance approach for a small team? Where would SOPS with AWS KMS or Sealed Secrets fit? We mainly want a clean way to manage and version configuration without leaking credentials.
4 Answers
Sealed Secrets is mainly useful when you want encrypted Kubernetes Secret manifests committed to Git and a controller in the cluster to decrypt them. It is a reasonable option, especially with a GitOps workflow, but it does not provide the same external secret storage or rotation model as AWS Secrets Manager or Parameter Store. Since you deploy directly with Helm, External Secrets or a Jenkins step that retrieves secrets from AWS may integrate more naturally.
SOPS with AWS KMS is usually a better fit than git-crypt when encrypted files genuinely need to live in Git. You can encrypt only the sensitive fields, use KMS identity and access policies to control decryption, and let Jenkins assume a tightly scoped AWS role. Be careful with access permissions, decrypted files in CI workspaces, logs, backups, and pull requests—encryption at rest does not help if the pipeline prints or packages the plaintext.
git-crypt can work for a small team, but the key lifecycle is the main drawback. You need a safe way to provision, rotate, revoke, and back up keys, and every person or automation account that can decrypt the repository is effectively trusted with all encrypted values. Accidental plaintext copies, diffs, editor swap files, and leaked CI artifacts are also common failure points. It is more practical for static, low-risk configuration than for credentials that need rotation or auditability.
For runtime credentials, the cleaner pattern is to keep secrets out of values.yaml entirely and store them in AWS Secrets Manager or Systems Manager Parameter Store. External Secrets Operator can then synchronize them into Kubernetes Secrets. Secrets Manager is useful for sensitive values and rotation, while Parameter Store is often cheaper and supports parameter history. This also avoids distributing one decryption key to every developer and CI job.
That makes sense. We were initially focused on encrypting the existing values file, but keeping credentials outside Git and fetching them during deployment sounds less risky.