You should be using a secrets service that is designed for such a purpose, like Hashicorp's Vault[0], so that you never have to keep a secret in the code.
Storing secrets in a repository with non-secrets is bad, because access is pre-repo, and it would hurt your ability to limit secret access to the smallest possible audience.
However, storing secrets in a git repo is still not as good as a purpose built store, because the access control on git is not fine grained enough.
I configure my application roles to be able to decrypt with the master key and I restrict what ciphertext they can read from Dynamodb.
Don't store encrypted secrets in git if you can avoid it.
This is built on the assumption that you only ever have one set of secrets, or that you don't mind distributing your prod secrets to your engineers, both of which I would consider to be bad practice.
> Knox is a service for storing and rotation of secrets, keys, and passwords used by other services.
I've been using https://github.com/AGWA/git-crypt until now, always good to have more alternatives.
Can you tell us what is different about your approach with this project?
Very specific to Ansible, but works fine. It's a shame only files containing variables (we're using group_vars) can be encrypted, and not arbitrary files or templates.
There are two things currently that bother me about ansible-vault. The first is that the 'edit' command write a completely new file even if I didn't change anything. And the second is that the diffs in git become useless. I'd love to have a special diff driver for ansible-vault encrypted files that decrypts before diffing when the secret is available.
- no file encryption, only YML
- no separate values, only entire file
- OMG it's s...l...o...w...
- password based instead of certs
- only one password
- password cannot even stored in an env var
More: http://jpmens.net/2014/02/22/my-thoughts-on-ansible-s-vault/
But yeah, the "only one password" is the biggest pain for me...
echo "$ANSIBLE_VAULT_PASSWORD"
https://github.com/rustyio/git-gpg
Other benefits include architectural simplicity and low footprint: it consists of a single Python script that you add to your executable path.
If you have a github account the script could also get the pubkey directly from the github api...
¹http://superuser.com/questions/576506/how-to-use-ssh-rsa-pub...
However, stackexchange is the right place to go if you want to use asymmetric secret storage in git.
I don't do that anymore. The main problem as I saw it was that you basically liberate your security to an environment you can't monitor or send rejections to (if someone downloads your gpg file). Compare this to an ssh server which affords both those abilities.
But they still can encrypt old versions stored in git, no? Do you change all secrets when somebody leaves the team/company? I guess that'd be best practice, but I have no idea how often that's done out there.
Storing secret keys, API keys, etc. in your git repo is a terrible idea and an antipattern any way you slice it. Keep your secrets out of version control.
The quoted advice is extremely bad. If someone who has access to a secret of any importance leaves your team, the only acceptable response is to rotate the secret.
As Junio C Hamano explains more eloquently and in greater depth here[1], one thing to bear in mind with this (and similar) tools is that they store the managed files as binary blobs, regardless of their original format, meaning that a change to the source file of even a single bit will result in an entirely different uncompressed blob being stored, rather than a compressible textual delta.
[1] http://article.gmane.org/gmane.comp.version-control.git/1132...
Access control is managed through AWS KMS key policies, with EC2 instances running the applications having permissions to decrypt the secrets.
Blog post about this will follow soon.
When you remove someone from the list of users does it have to go and re-write history? Isn't that a big no-no in Git?
The re-encryption they're referring to is presumably just to protect future revisions (since you would ideally rotate all keys they had access to, git-secret or not, and publish new ones right away).
I definitely agree this should be used with heavy caution and only in private repos.
