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

61–70 of 74 posts

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

#61

Post by jcassee »

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/

Actually, you can make the vault password file an executable shell script containing

echo "$ANSIBLE_VAULT_PASSWORD"

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

#62

Post by startling »

tptacek wrote: post #33
siliconc0w wrote: post #26

Earlier quoted context omitted.

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.

No. If that were the case, there would be no purpose to rotating keys. The problem is that despite rotating keys, your old crypto keys have permanent access to secrets, because the old ciphertexts are by default retained in the git history. It's a bad idea to store secrets in any form in your source code repository.

I think what grandparent and others are saying is that you also revoke the secrets contained in the ciphertext, e.g. if it's an AWS key you would revoke that AWS key on AWS's side as well as encrypting new secrets with a different encryption key.

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.

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

#63

Post by elcritch »

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.

Doesn't the OP say that secrets aren't allowed to be stored unless they're in the gitignore file? Does this mean they're somehow not storing the secret's history? Say by rewriting the history of those particular files in the .gitsecrets file every time they're committed so they've only got the lastedt version?

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

#64

Post by mifix »

jedberg wrote: post #59
deathanatos wrote: post #50

Earlier quoted context omitted.

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

What you are describing is how to remove _access_ to the secret. The issue here is, that the former employee still has _knowledge_ of the secret. Hence you have to rotate the secret.

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

#65

Post by runholm »

gechr wrote: post #7

A word of warning to those considering using this. While I completely understand why people might want to encrypt/decrypt files within their public Git repositories, doing so doesn't come for free. 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, me…

Why would someone change a single bit in their key anyway? If keys are replaced, the new key should be generated independent from the old ones.

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

#66

Post by davedx »

Deinumite wrote: post #54
RRRA wrote: post #41

Earlier quoted context omitted.

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.

We don't encrypt all of the credentials, just the actual passwords.

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

#67

Post by iopq »

jedberg wrote: post #59
deathanatos wrote: post #50

Earlier quoted context omitted.

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

If a developer leaves they'll still have the plaintext of the keys from when they were working for you. You have to change your secrets at that point.

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

#68

Post by nsaje »

At Zemanta, we developed py-secretcrypt[0] and go-secretcrypt[1] for keeping secrets encrypted with Amazon KMS (Key Management Service) in our repos. They are then decrypted on the fly by the application.

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.

[0] https://github.com/Zemanta/py-secretcrypt

[1] https://github.com/Zemanta/go-secretcrypt

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

#69

Post by friendzis »

deathanatos wrote: post #50
tptacek wrote: post #46

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

In this case state of access control is stored along with code/secrets. The problem is that ACLs, secrets themselves and code change independently of each other. This only works if you assume no downgrading and homogeneous versioning across all instances.

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

#70

Post by [deleted] »

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

[deleted]
Post reply on HN