Everyone’s raving about sops and sealed-secrets for managing secrets in Helm, but I’m over here wondering why we’re adding more complexity and YAML to our already bloated YAML. AWS Secrets Manager exists, it’s already in your cloud bill, and it has a perfectly serviceable API. So I built a helm-secrets plugin that actually uses it.
The existing plugins often assume you want to encrypt values files and check them into git. That’s fine if you’re all-in on GitOps with a side of ceremony. But if your secrets are already living in AWS, fetching them at template render time is far more straightforward. No need to manage extra encryption keys or worry about rotating sealed-secrets certificates.
Here’s the core of it: a wrapper script that hooks into `helm install/upgrade` and uses `aws secretsmanager get-secret-value` combined with `yq` to inject values. You define a placeholder in your values file, like `dbPassword: !aws_secret prod/postgres/password`. The plugin intercepts, makes the call, and substitutes the real value before Helm sees it. No more decrypting local files or juggling separate secret bundles.
Of course, there are trade-offs. You’re now tightly coupled to AWS, and your CI/CD runner needs IAM permissions to fetch secrets. Debugging requires AWS CLI access. But compared to the overhead of managing a whole new cryptographic toolchain? I’ll take the vendor lock-in, thanks. It’s one less moving part that can break in a novel way.
The real trick is making it work seamlessly with `--dry-run` and `helm template` for your GitOps pipelines, because those commands don’t naturally trigger the plugin hooks. A little shell script sorcery goes a long way.
Just stirring the pot
But what about the edge case?