Some cross platform tool that we've developed for our company which has some nice features
Git-secret – store private data in a Git repo
51–60 of 74 posts
Re: Git-secret – store private data in a Git repo
#52This should really work with ssh public/private keys¹. Public keys are probably already on the box the git server runs on, and users already have them generated to access git - no need to generate separate gpg keys. 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...
SSH keys aren't really used for encryption. Typical ssh uses some kind of DH construct, with the ssh keypairs just used for authentication. However, stackexchange is the right place to go if you want to use asymmetric secret storage in git. https://github.com/stackexchange/blackbox
Re: Git-secret – store private data in a Git repo
#53Earlier quoted context omitted.
It's a bad practice, because git makes keys practically irrevocable. It's not enough to rotate encryption keys, because the old ciphertexts are in the git history; you have to rotate the underlying secrets as well (people don't do this and shouldn't have to). Don't store encrypted secrets in git if you can avoid it.
No, this forces you to rotate your secrets because you don't get to pretend that losing access to the repo means losing access to the secrets. While dynamic secrets are best, static secrets (like API keys) should be stored in version control. 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're forgetting that if I have been storing all of the encrypted traffic all along and then get access to the keys I can unlock all of the history too. Once a secret is out of use it should be purged completely. This is why secrets should be stored on ephemeral storage if at all possible. This is however pretty advance for many people.
Re: Git-secret – store private data in a Git repo
#54Earlier quoted context omitted.
If you use show instead of edit it doesn't re-encrypt the file. Agreed on the useless diffs however, it makes reviewing pull requests or changes much harder.
I'm curious, why do you feel the need to encrypt every single file instead of just secrets (to keep reviewing possible)? :)
I usually only encrypt var files that contain things like db passwords or something. In our case it made it harder to spot typos in the username for example.
I wouldn't encrypt a whole playbook for example.
Re: Git-secret – store private data in a Git repo
#55If all you have is a hammer, everything looks like a nail.
Re: Git-secret – store private data in a Git repo
#56Earlier quoted context omitted.
No, this forces you to rotate your secrets because you don't get to pretend that losing access to the repo means losing access to the secrets. While dynamic secrets are best, static secrets (like API keys) should be stored in version control. 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're forgetting that if I have been storing all of the encrypted traffic all along and then get access to the keys I can unlock all of the history too. Once a secret is out of use it should be purged completely. This is why secrets should be stored on ephemeral storage if at all possible. This is however pretty advance for many people.
This is solved with perfect forward secrecy: https://en.m.wikipedia.org/wiki/Forward_secrecy
Re: Git-secret – store private data in a Git repo
#57Earlier quoted context omitted.
You're forgetting that if I have been storing all of the encrypted traffic all along and then get access to the keys I can unlock all of the history too. Once a secret is out of use it should be purged completely. This is why secrets should be stored on ephemeral storage if at all possible. This is however pretty advance for many people.
This is solved with perfect forward secrecy: https://en.m.wikipedia.org/wiki/Forward_secrecy
Great! It's "solved". No need to worry anymore!
Re: Git-secret – store private data in a Git repo
#58This project scares me because it helps foster a bad practice -- keeping secrets in a repo. You really shouldn't be keeping secrets in the repo. 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. [0] https://github.com/hashicorp/vault
Storing secrets in a repository is not bad. 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.
You are technically correct, the best kind of correct.
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.
Re: Git-secret – store private data in a Git repo
#59Earlier quoted context omitted.
We agree that if you store secrets in a repo, any time you change the encryption key, you have to go and purge the underlying secrets. We disagree that this is intuitive or that shops do this reliably. We should be able to agree that not storing secrets in your repo dodges all these problems nicely.
Well, I disagree. It doesn't matter where you store them, repo or not: even if they're not in a "repo", they're stored somewhere , and when you revoke access from someone to that somewhere, you still have the same problem: the party that you're revoking access from had access at one point. For all you know, they copied the secret while they had access. You can't "revoke" information from someone's mind: you MUST rota…
If you use a purpose built storage though then you can deny access to the actual keys to just about everyone, so if a developer leaves then they won't have the keys, and if they do you'll know because it will have a built in audit trail. And in many cases you never have to release the key from the purpose built store because it takes in crypto text and gives out plain text without ever revealing the key to the user.
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.
Re: Git-secret – store private data in a Git repo
#60Earlier quoted context omitted.
Storing secrets in a repository is not bad. 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.
You are technically correct, the best kind of correct. 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.
Yes, that could be appropriate.
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.