Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git-secret – store private data in a Git repo

coderwall.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Git-secret – store private data in a Git repo

#41

Post by RRRA »

Deinumite wrote: post #17
perlgeek wrote: post #10

Earlier quoted context omitted.

To be a bit pedantic, all .yml files can be encrypted with ansible-vault, so also playbooks and roles. 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 d…

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)? :)

Re: Git-secret – store private data in a Git repo

#42

Post by YesThatTom2 »

TheHippo wrote: post #5

Similar project, that I personally use quite often: https://github.com/StackExchange/blackbox

I'm glad that blackbox is gaining in popularity. Future directions for the project are listed here: https://github.com/StackExchange/blackbox/blob/master/Versio...

Re: Git-secret – store private data in a Git repo

#43

Post by ChristianBundy »

tptacek wrote: post #21
Kinnard wrote: post #19

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.

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 use deterministic encryption to create the secrets too.

Re: Git-secret – store private data in a Git repo

#44

Post by RRRA »

perlgeek wrote: post #10
Confiks wrote: post #8

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…

To be a bit pedantic, all .yml files can be encrypted with ansible-vault, so also playbooks and roles. 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 d…

Uhm, for me edit brings up vi, I then :q and the file's modification date didn't change?

Re: Git-secret – store private data in a Git repo

#45

Post by RRRA »

rgj wrote: post #28
Confiks wrote: post #8

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/

A good trick I found was to have a file with your values assigned as vault_something and then in the clear version have the variable assigned as: something: "{{ vault_something }}"

But yeah, the "only one password" is the biggest pain for me...

Re: Git-secret – store private data in a Git repo

#46

Post by tptacek »

ChristianBundy wrote: post #43
tptacek wrote: post #21

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.

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…

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.

Re: Git-secret – store private data in a Git repo

#47

Post by paulddraper »

jedberg wrote: post #18

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

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.

Re: Git-secret – store private data in a Git repo

#48

Post by Tehnix »

perlgeek wrote: post #12

> When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore. 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.

Yes, he can still decrypt the secrets he had access to before his key was revoked, just as he could have written down those secrets before he was fired. There is no difference really, and the way to solve that is the same for both cases - you change your secrets after such an event.

Re: Git-secret – store private data in a Git repo

#49

Post by Tehnix »

tptacek wrote: post #21
Kinnard wrote: post #19

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.

>you have to rotate the underlying secrets as well (people don't do this and shouldn't have to).

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.

Re: Git-secret – store private data in a Git repo

#50

Post by deathanatos »

tptacek wrote: post #46
ChristianBundy wrote: post #43

Earlier 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…

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 rotate the secret to accomplish that.

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?

Post reply on HN