Git-secret – store private data in a Git repo
coderwall.com
coderwall.com
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.
Don't store encrypted secrets in git if you can avoid it.
The page says "When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore." but doesn't talk about rotating the secrets.
This practice seems unnecessary to me.
If someone has access to a shared secret and then shouldn't you should assume the secret is now compromised and rotate it. Rotating the keys doesn't solve this problem.
It's a bad idea to store secrets in any form in your source code repository.
Obviously this is a huge hassle and isn't easily done with all kinds of secrets (which is what I think you're getting at?). But it's also often necessary.
This doesn't have to be a Git repository, nor does it have to be the same repository as the code which uses the secrets.
> it's incredibly helpful to store the configuration along with the code
It's helpful, but ultimately means that the ciphertext is potentially available to the world and existing keys may decipher it in perpetuity. Thus this is not a recommended tradeoff to make.
a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.
seems like we should be making it easier to rotate secret values often and automatically.
When someone has unintended access to secrets (for example, the developer you just fired), you need to rotate both the key and secrets to have any semblance of security. Ideally you use deterministic encryption to create the secrets too.
We should be able to agree that not storing secrets in your repo dodges all these problems nicely.
If anything, I like the git repo idea b/c — presuming that the repository stores a history of who had access to what, when — it removes the question of whether you need to rotate a secret. You can look at the history, and if the secret didn't get rotated when access was removed or at some time afterwards, you know you're not secure.
Compare that to say, a random file somewhere, say on a deployment node in deployment code, or alongside that code so as to keep it out of a repo, that just keeps the latest copy of the secrets, where one doesn't know when access was revoked. Do the keys need rotation?
They'll have their own key, which will be revoked from the store, and they might have a single key that machines use to access the store. You should be rotating that machine key all the time anyway, so rotating once more when a dev leaves isn't a big deal. It's also much easier than rotating all of your actual keys, which in many cases is generated by a third party that may make such a thing very hard.
Obviously, nothing you do w/r/t secret storage is going to resolve the problem of what's in your employees' heads.
How is that different from the case of an employee having written down the secrets and leaving the company later on? In both cases the employee has had access to the secrets and in both cases the only way to be secure is to change them.
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.
I configure my application roles to be able to decrypt with the master key and I restrict what ciphertext they can read from Dynamodb.
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.
Access is per-repo, so if you have enough secrets and disparate interested parties, the number of required repos could make a dedicated alternative far more manageable.
> 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.
Agreed on the useless diffs however, it makes reviewing pull requests or changes much harder.
I wouldn't encrypt a whole playbook for example.
- 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.