3 ms·

It should be mentioned that none of that should ever make its way into a Git repo in the first place. If a secret is committed to Git, it's compromised, period.

It should be mentioned that none of that should ever make its way into a Git repo in the first place. If a secret is committed to Git, it's compromised, period. Suck it up and generate a new secret.

cat199 9y ago
only if your git is published.. I assume this is what you mean - that said: separate integration repo containing encrypted keys + separate, manual managment/configuration of the decryption process is fine for most cases. but yes, bare and in mainline and published, I will agree this is terrible. see also: http://docs.ansible.com/ansible/2.4/vault.html http://docs.ansible.com/ansible/2.4/vault.html
- shkkmo 9y ago
  No, you should never commit your secrets, not even to a private github repo, and not even to a privately hosted git server. Doing so increases your attack surface, sometimes in surprising ways. Now, if your secrets are encrypted before being committed (using something like ansible vault) and the encryption key is not stored in the repo, that may be ok. However, you still need to be aware that any time you rotate that key, you also should to rotate every secret hidden behind that key.
  - kuschku 9y ago
    So how do you do version the configuration management for the cluster that runs everything? It needs to be versioned, and yet with just the data in it you need to be able to recreate your entire environment from scratch.
    - shkkmo 9y ago
      If you want your secrets under version control, then they should be encrypted. There are lots of ways of doing this. git-crypt is one that is configuration management agnostic. Most CM tools have their own way of dealing with secrets and there are CM agnostic tools like git-crypt. I'm not personally familiar with anything besides ansible-vault, but this article seems to provide a pretty good summary of several options: https://www.threatstack.com/blog/cloud-security-best-practices-finding-securing-managing-secrets-part-2/ https://www.threatstack.com/blog/cloud-security-best-practic...
chrisweekly 9y ago
Amen. https://12factor.net https://12factor.net
smoyer 9y ago
Agreed ... use a pre-commit hook to scan your repository for high-entropy strings before they are forever enshrined in your history (https://github.com/dxa4481/truffleHog https://github.com/dxa4481/truffleHog).
- tachyoff 9y ago
  To be fair, though, history can be rewritten, albeit sometimes with some difficulty.
  - ameliaquining 9y ago
    If a secret has ever been in Git then you probably can't know where it's been copied to and should treat it as likely to have been leaked.
    - tachyoff 9y ago
      Oh, absolutely. That’s what’s important. But if youre embarrassed or just want the commits gone, there are ways to pretend it never happened.
- djglass 9y ago
  Great idea! Thanks for linking to that tool.

It should be mentioned that none of that should ever make its way into a Git repo in the first place. If a secret is committed to Git, it's compromised, period. Suck it up and generate a new secret.

cat199 9y ago

only if your git is published.. I assume this is what you mean - that said: separate integration repo containing encrypted keys + separate, manual managment/configuration of the decryption process is fine for most cases. but yes, bare and in mainline and published, I will agree this is terrible. see also: http://docs.ansible.com/ansible/2.4/vault.html http://docs.ansible.com/ansible/2.4/vault.html

shkkmo 9y ago
No, you should never commit your secrets, not even to a private github repo, and not even to a privately hosted git server. Doing so increases your attack surface, sometimes in surprising ways. Now, if your secrets are encrypted before being committed (using something like ansible vault) and the encryption key is not stored in the repo, that may be ok. However, you still need to be aware that any time you rotate that key, you also should to rotate every secret hidden behind that key.
- kuschku 9y ago
  So how do you do version the configuration management for the cluster that runs everything? It needs to be versioned, and yet with just the data in it you need to be able to recreate your entire environment from scratch.
  - shkkmo 9y ago
    If you want your secrets under version control, then they should be encrypted. There are lots of ways of doing this. git-crypt is one that is configuration management agnostic. Most CM tools have their own way of dealing with secrets and there are CM agnostic tools like git-crypt. I'm not personally familiar with anything besides ansible-vault, but this article seems to provide a pretty good summary of several options: https://www.threatstack.com/blog/cloud-security-best-practices-finding-securing-managing-secrets-part-2/ https://www.threatstack.com/blog/cloud-security-best-practic...

chrisweekly 9y ago

Amen. https://12factor.net https://12factor.net

smoyer 9y ago

Agreed ... use a pre-commit hook to scan your repository for high-entropy strings before they are forever enshrined in your history (https://github.com/dxa4481/truffleHog https://github.com/dxa4481/truffleHog).

tachyoff 9y ago
To be fair, though, history can be rewritten, albeit sometimes with some difficulty.
- ameliaquining 9y ago
  If a secret has ever been in Git then you probably can't know where it's been copied to and should treat it as likely to have been leaked.
  - tachyoff 9y ago
    Oh, absolutely. That’s what’s important. But if youre embarrassed or just want the commits gone, there are ways to pretend it never happened.
djglass 9y ago
Great idea! Thanks for linking to that tool.