I deploy my Rails 6 app in a Kubernetes cluster and I think about how to implement my ENV vars.
Regularly in Rails apps I use dotenv with regular ENV vars on the host. But it seems, that I can omit them now and make the use Rails credentials. But just because features exists doesn't mean it has to be used or must be better, right?
So I am not sure how to solve this env/security puzzle:
Approach ConfigMap
ConfigMap on the cluster to provide ENV varsApproach Credentials
Secret or ConfigMap with the RAILS_MASTER_KEYRAILS_ENV?)The downside I am worry about is, that when I wanna change a ENV var (fix typos, scale workers, switch db, credentials...), I have to pass a lot of steps: make a git push, build and tag the container and wait for a deploy.
With a ConfigMap I simply kubectl apply the change.
I like the Rails way "convention over configuration", so scattering vars to two or three different kinds seems not so practical to mem, but I am afraid, I have to.
When to use credentials then?
What's best practice in 2021?
You wouldn't use (only) a ConfigMap since that's not safe but you might use a Secret to hold all the env vars in the same way as you describe. Really its up to which workflow you prefer. No matter how you do it, you have some Kubernetes Secrets object somewhere, just a question of scope for it. So you 100% need to have a workflow for that side of things. But if you prefer the day-to-day secrets edits to be via the Rails workflow so you don't need to touch the Kubernetes side as much, that's cool.
Personally I think having fewer systems touching secrets data is better even if it means the Rails devs need to learn a new tool.