top | item 16154405

(no title)

gedrap | 8 years ago

>> storing my.cnf in VCS is a better idea than updating it in prod.

Eh, 'but we can't store things/API keys/passwords in VCS! It's bad!' is a pet peeve of mine. No, let's not 'just update it manually when we need it'. No, if outsider getting your DB password (somehow) poses existential threat... Chances are that you have way more concerning problems.

discuss

order

stouset|8 years ago

Storing passwords and other secrets in VCS is a phenomenally bad idea, particularly when your team size grows past two or three people.

All it takes is one fuckup of accidentally committing to a public repo. Or firing someone on the team but not thinking to rotate secrets. Or hiring an outside contractor that now you implicitly give access to your production AWS credentials, etc.

Secrets do not belong in source control, hard stop.

breatheoften|8 years ago

I don’t understand why secrets should be excluded from source control. It seems like a perfectly fine place for them to be stored to me especially when talking about secrets which the developers require in order to develop the code or maintain a set of systems.

If the secrets in source control are:

(1) encrypted

(2) never have decryption keys stored/loaded on any developer machine

(3) never have stored decrypted representations (only in memory representation of decrypted forms allowed when required).

If you follow these rules you won’t be more likely to accidentally commit unencrypted versions of the secrets and you’ll also by necessity have setup some (auditable) gatekeeper for logging of decryption events (via an aws kms or similar decryption as a service api).

For the category of secrets which must never exist in any decrypted form on a developer machine — maybe I can see the argument that those should be left out of source control as this would represent a reduction in the surface area for offline attacks against the encrypted form of the secrets -— but I would guess that this actually represents a somewhat minor gain in practice? And also seems strictly unimportant to use cases where access to the decrypted representation of the secrets on the developers machine is mandatory ...

iamdave|8 years ago

It is wholly possible to store configuration data in vcs in a way that doesn't sacrifice depth of security when it comes to secrets and passwords.

But otherwise yes, storing passwords in vcs is bad. That wasn't necessarily what I meant to imply by suggesting storing configuration files in vcs, however. I probably phrased that poorly.