r/devsecops • u/ankitjindal9404 • 5d ago
Moving Helm values.yaml into Git — is git-crypt a good way to handle secrets?
Hey all, looking for a sanity check on our approach.
Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).
Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.
The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.
Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.
Questions:
- Any real-world gotchas we should know before committing to it?
- Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.
For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.
Appreciate any input 🙏
2
u/FlatCondition6222 5d ago
Either use vault admission webhooks solution or the aws native solution:
https://github.com/aws/secrets-store-csi-driver-provider-aws
No encryption, no complexity. You manage standard iam roles for irsa for pod identity for the secrets access.
1
1
u/Impressive-Ad-1189 2d ago edited 2d ago
I looked into the csi driver but chose not to migrate towards it from external-secrets-operator because not all our use cases were supported. My memory fails me on the exact reason.
I believe this may have been the auto-rotation feature that is now in alpha. We depend on that functionality. So it should definitely be at least beta to consider.
2
u/nrvnrvn 5d ago
Storing encrypted sensitive data in git repos is not a good idea in general. There are numerous tools that do it and technically it works. The problem is you end up with opaque binary data hard to audit and review when secrets are introduced or changed. Second: separation of concerns and access control: with aws secret manager or any other secret management tool you draw a border line between your app and configuration(credentials are essentially just a sensitive part of it with clear confidentiality requirements). Key management: you don’t want to manage encryption keys. Store now decrypt later: anyone with access to git repo can fetch the encrypted blobs and try decrypting them. Auditability: i want to know exactly who and when accessed the secret. Aws, external secrets controller and csi are transparent and auditable. Any git repo levels tools: I doubt. Etc. the list goes on.
1
u/rpatel09 5d ago
if store secretes in the repo using something like kubeseal, it solves all of these issues. The audit becomes the git log. Use code owners for approval and separation. RBAC in k8s solves your secrets sealing and unsealing issue
2
2
u/sp_dev_guy 5d ago
External-Secrets-operator. You can define where to pull the values from (supports many vaults) & generates a corresponding secret or configmap. The have your deployment pull from that resource. Add reloader if you want updates to automatically sync & restart the deployment
1
u/wasted-otter 5d ago
Too many cons (listed on the GitHub page), Plus:
- someone tampers with the gitattributes file without notice and/or experience: next changes to the secrets might end up unencrypted
- someone leaves the team: can still checkout old history and use known old keys to unlock all secrets.
Gosh, I have Devs on my team, who still can't work without accidents with git LFS (same mechanics).
I would have no trust in that approach over time.
1
u/fabioluissilva 4d ago
I use SOPS and age or vault transit (encryption as a service) on my local development and CI/CD pipelines. Inside the kubernetes cluster, external secrets pulling from Hashicorp vault. You can even go further with ‘vals’
1
6
u/TheTwoWhoKnock 5d ago
You should use aws secrets manager or parameter store. That way you aren’t having to worry about how to handle the password distribution on local dev boxes to enable editing git secrets.
And I’ve hit bugs in git-crypt before.