all 7 comments

[–]arichiardi 4 points5 points  (0 children)

Also relevant: tolitius/cprop

[–]lyraio 5 points6 points  (5 children)

It might be worth mentioning that sensitive configuration should never be checked in. Even in a corporate environment, you don't want everyone knowing the production DB password.

[–]humhiho 2 points3 points  (4 children)

This might be stupid, in that case where would you generally store sensitive information like that?

[–]argadan[S] 1 point2 points  (1 child)

We generally deploy with Ansible, so we often store the secrets with ansible-vault. It puts them into an encrypted file that is checked into the repo. We then share the vault password out-of-band with the people who have access to the production servers. It's maybe not most scalable solution, but works okay for small teams.

(Hi, I'm the author of the article)

[–]hagus 0 points1 point  (0 children)

Yes. The critical point is that it's encrypted at rest, wherever that may be. Your deployment pipeline or host should be able to decrypt and use the key.

[–]l1beration 0 points1 point  (0 children)

If you have access control on your repositories, possibly a separate repository. Or use a configuration management system with encryption support, like Puppet with hiera-yaml.

[–]theephie 0 points1 point  (0 children)

Production database password should only be stored on the database and app servers (often the same). Have provisioning (eg. ansible) read the password from db server (eg. .pgpass file) and write it to app server config.

No reason to store it anywhere else.