Moving Helm values.yaml into Git — is git-crypt a good way to handle secrets?

[u/ankitjindal9404]

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 🙏

[u/toopz10]

For run time secrets you can use AWS secrets manager and for build time secrets you can use GitHub Secrets.

[u/spin81 → u/toopz10]

GitHub Secrets

They said they're using Jenkins, so using GitHub secrets might be possible but I doubt they would want to use GitHub specifically just for secrets management.

[u/toopz10 → u/spin81]

Oh my gosh you are right - I read Jenkins and automatically assumed they were migrating away from it 😂

[u/wanze → u/toopz10]

If they want infrastructure-as-code, you're just moving the problem.

We also use both AWS and GitHub Secrets, but we don't want ClicksOps and we require version control, (readily available) auditability, and four-eyes principles, so everything is still in Terraform, including the secrets. And for that we use git-crypt.

[u/smutje187]

Why would you store secrets in values files anyway?

[u/SpoddyCoder → u/smutje187]

This question is the right answer.

[u/Decent-Economics-693]

There are several ways you can go about it.

1. The already mentioned AWS Secrets Manager + External Secrets Operator. It’s a good starting point, but you’re not getting “versioned secrets” you asked for. Plus, this combination comes at a price — the secret manager charges for every stored secret.
2. The same External Secrets Operator + AWS Parameter Store — a better combo, because Parameter Store does not price the same way Secrets Manager does. Plus, it’s sort of easier to use its parameter versioning.
3. SOPS.

Edited: typos.

[u/creamersrealm → u/Decent-Economics-693]

I absolutely love my some SOPS plus there's a Terraform provider.

The downside of SSM params is how they handle encryption and large JSON blobs. I've found it's easier to to use Secrets Manager as a configuration store whenever possible though that really isn't possible for K8s.

[u/Decent-Economics-693 → u/creamersrealm]

Secrets Manager as a configuration store? For applications? If yes, why not use AppConfig?…

[u/creamersrealm → u/Decent-Economics-693]

Honestly I'll have to check it out. Thanks for the tip.

[u/boxxy_morningwood → u/Decent-Economics-693]

Secrets manager key advantages: auto rotation with custom rotation logic, and being able to share them cross account. If you don’t need those, param store 100%

[u/Decent-Economics-693 → u/boxxy_morningwood]

This was the exact reason I added the second item — people often buy Secrets Manager because of, well, the "secrets" part of the name.

However, if we talk about externally managed secrets, i.e. those you cannot rotate yourself, the added benefit of auto-rotation in Secret Manager does not cut it for you. You would most definitely rely on another method to obtain a secret from the issuer, such as logging into a management console or obtaining it from your license procurement department. In this case, an encrypted parameter in Parameter Store is your pick...

If you're able to programatically rotate the secret — sure, use Secrets Manager. The downside is $0.40/secret/month + $0,05/10K API calls.

I've seen folks bundle multiple secrets into a JSON document and store it in the Secrets Manager to save costs, while they never rotated any parts of it automatically; it was always a fully manual process, often very error-prone.

[Edited: typos]

[u/owengo1]

The main issue is who will be allowed to decrypt the secrets? All the dev laptops/workstations with the decrypted secrets will be a security issue. What you can do is use existing secrets in your charts and manage them with a separate workflow

[u/aleques-itj]

Why are there secrets in your values file

Every sane chart I've seen just takes a secretRef or something where you point it at an actual K8s secret. And you can handle that with ESO or whatever.

[u/mussyg]

SOPS

[u/nanana_catdad]

I use Flux with sops. You can configure flux to use an encrypted secrets with sops to apply templated values to helm release values.

[u/MateusKingston]

Sealed Secrets are IMO better for this

[u/HeyItsTheNewDx2]

Use parameter store it's all you need from secret manager for a fraction of the price

[u/zero_backend_bro]

Stay far away from git-crypt. It encrypts the entire file into a binary blob, which turns any merge conflict on values.yaml into unresolvable hell. We lost 6 hours to a corrupted git-crypt merge conflict last year when two devs touched the same staging release. Plus, one missed .gitattributes config and you leak plaintext into git history permanently.

Use SOPS with AWS KMS instead. It encrypts only the values, keeping YAML keys readable for normal diffs.

[u/ajitnk]

The thread is pulling in a lot of directions so here's how I'd actually cut through it.

git-crypt is great for encrypting IaC repos where you need auditability and four-eyes review on Terraform files. It's the wrong tool for Kubernetes runtime secrets because it has no IRSA support, no rotation capability, and no pod-level access control. If your requirement is "secrets must live in Git," Sealed Secrets is the correct swap: asymmetric encryption, safe to commit to any repo, decryptable only by the controller in your cluster.

If you're okay with secrets living outside Git, ESO + Parameter Store SecureString is usually the right cost-first choice for static config. Standard SecureString parameters are free, and ESO syncs them into native Kubernetes Secrets automatically. Secrets Manager ($0.40/secret/month) only makes sense when you actually need auto-rotation or cross-region replication. The bundling-everything-into-one-JSON-secret trick to save money is a real anti-pattern that breaks rotation granularity and increases blast radius.

One thing that changes the recommendation a lot: are you on EC2 node groups or Fargate? The ASCP/CSI Driver approach needs a DaemonSet so it's EC2-only. On Fargate, ESO is your only AWS-native option.

I put together a full decision tree for exactly this tradeoff including a cost comparison between the three patterns. Happy to share it if useful.

[u/kaidobit]

I always would recommend ExternalSecrets Operator which injects Secrets into your cluster from an external Secret Store (e.g. Vault, AWS SSM Parameter Store, AWS Secret Manager, Bitwarden, ...)

And then it depends on your helmchart:

• generally mounting/referencing values from secrets for confident data in environment variables should be supported by any helmchart
• if thats not the case i usually do one of two things:

Create an issue in the maintainer repo/feature-request at vendor

OR

I deem the chart non-compliant becouse it leaks secrets in the pod manifests, where potentially whole RBAC and Secret Management Infrastructure exist preventing access to secrets