If you don't store secrets in a file... how do you share them? When a new developer comes on board; when a new deploy machine is provisioned; etc.
Honest question, I've been trying to figure out the best way to do this.
Even without considering deploying secrets to a new machine, doesn't 'keep them in environment variables' usually mean store in a .bashrc or something, which is of course still a file?
The idea is to keep them out of version control. At least ~/.bashrc won't end up in a repository under normal circumstances. You have no idea what pieces of your code base may eventually be open-sourced.
For small teams, a good solution is to keep a GPG-encrypted file in Dropbox or another team file share. When you onboard a new developer, someone reencrypts the file with the new recipient. If you use Chef, the knife-briefcase plugin will handle this for you.
For large teams, there shouldn't be any secrets that need to be disributed. In an ideal world, at least. Each user should get his/her own account on each server, his/her own AWS credentials, etc. At some point you'll run into sharing a secret among production servers (SSL certs, for example), but you should never need to share secrets among developers in a well-designed system. Individual accounts allows useful audit trails and limits the damage if a credential is leaked.
Chef encrypted databags or a similar approach where the environment variable is encrypted on disk and decrypted at runtime. Obviously your deployment nodes eventually need the secret in plaintext and all end up with the key, but at least the information is encrypted at rest (for example in your source control, a common source of breaches).
It doesn't seem wise to share secrets amongst developers (especially new ones) to me - that sounds like a recipe for disaster. GitHub accidentally deleted their production database by giving developers access to production secrets on their local machines a few years ago - regardless of how much you trust your people it's not a particularly solid plan.
Comments
If you don't store secrets in a file... how do you share them? When a new developer comes on board; when a new deploy machine is provisioned; etc.
Honest question, I've been trying to figure out the best way to do this.
Even without considering deploying secrets to a new machine, doesn't 'keep them in environment variables' usually mean store in a .bashrc or something, which is of course still a file?
The idea is to keep them out of version control. At least ~/.bashrc won't end up in a repository under normal circumstances. You have no idea what pieces of your code base may eventually be open-sourced.
For small teams, a good solution is to keep a GPG-encrypted file in Dropbox or another team file share. When you onboard a new developer, someone reencrypts the file with the new recipient. If you use Chef, the knife-briefcase plugin will handle this for you.
For large teams, there shouldn't be any secrets that need to be disributed. In an ideal world, at least. Each user should get his/her own account on each server, his/her own AWS credentials, etc. At some point you'll run into sharing a secret among production servers (SSL certs, for example), but you should never need to share secrets among developers in a well-designed system. Individual accounts allows useful audit trails and limits the damage if a credential is leaked.
Chef encrypted databags or a similar approach where the environment variable is encrypted on disk and decrypted at runtime. Obviously your deployment nodes eventually need the secret in plaintext and all end up with the key, but at least the information is encrypted at rest (for example in your source control, a common source of breaches).
It doesn't seem wise to share secrets amongst developers (especially new ones) to me - that sounds like a recipe for disaster. GitHub accidentally deleted their production database by giving developers access to production secrets on their local machines a few years ago - regardless of how much you trust your people it's not a particularly solid plan.