31–40 of 74 posts
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.
I've been using https://github.com/ahoward/sekrets in private repos for years. Great tool. I definitely agree this should be used with heavy caution and only in private repos.
Earlier 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.
The problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code. 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.
Earlier 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.
The problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code. 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.
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.
Earlier 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.
The problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code. 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.
Earlier quoted context omitted.
Perhaps it's an alternative practice/behavior rather than a "bad" practice?
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.
Earlier quoted context omitted.
Perhaps it's an alternative practice/behavior rather than a "bad" practice?
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.
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.
Nice work! 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?
This 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
Perhaps it's an alternative practice/behavior rather than a "bad" practice?
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've been using ansible-vault to solve this problem in our infrastructure repository. A symmetric vault key is encrypted using gpg, and Ansible's vault_password_file is set to to an executable shell script containing `gpg --batch --use-agent --descrypt vault_key.gpg`. 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 fil…
More things about Ansible vault that are a shame: - 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/