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

Show HN: Lockenv – Simple encrypted secrets storage for Git

github.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#21

Post by nothrabannosir »

peanut-walrus wrote: post #17

The main problems with these kinds of in-repo vault solutions: - Sharing encryption key for all team members. You need to be able to remove/add people with access. Only way is to rotate the key and only let the current set of people know about the new one. - Version control is pointless, you just see that the vault changed, no hint as to what was actually updated in the vault. - Unless you are really careful, just on…

Agreed with 1 and 3, just a tip re 2 though: sops encodes json and yaml semantically, key names of objects are preserved. Iow you can see which key changed.

Whether that is a feature or a metadata leak is up to the beholder :)

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#24

Post by SomeUserName432 »

mbreese wrote: post #15

Secrets management is hard. And proper secret sharing setups meant for larger groups are quite unwieldy to work with with smaller groups. Well, they are hard to work with for all sizes of groups, but it seems particularly overkill for small groups. So I see why you'd want to do this. I also kinda like the idea of just encrypting/decrypting .env files. It's a pretty clean design. But storing secrets in the same git re…

> or 1Password vaults are harder to work with

https://1password.com/blog/1password-environments-env-files-...

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#25

Post by pverheggen »

crote wrote: post #6
jillesvangurp wrote: post #3

Sounds useful. We do similar things with encrypted properties files. Also, things like Ansible come with ansible vault. If you use Github, you can use Github secrets of course. And AWS/GCP/etc. tend to have secret stores. The challenge with this solution is of course managing who has access and dealing with people leaving your team and no longer being trusted. Even if you still like them personally, just because they…

> The challenge with this solution is of course managing who has access and dealing with people leaving your team and no longer being trusted. Even if you still like them personally, just because they are outside your team would require you to change any credentials they might have. At least it's a clearly exposed problem: everyone who has ever cloned the repo has a copy of your secrets. With software like 1Password…

Regarding the sticky note problem, this can be mitigated with separate vault credentials for production. That way you can limit prod secrets to a much smaller group, and if you wanted to rotate when someone leaves, you'd have to do it much less often.

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#26

Post by n31l »

madeforhnyo wrote: post #23

Being a node dev - by necessity, I've settled on dotenvx [0] for committing encrypted .env files. [0] https://dotenvx.com/

Agreed, and it's nice and easy for anyone already using `.env` files, although the private key used to decrypt the dotenvx key-values is itself a secret.

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#27

Post by hersko »

n31l wrote: post #26
madeforhnyo wrote: post #23

Being a node dev - by necessity, I've settled on dotenvx [0] for committing encrypted .env files. [0] https://dotenvx.com/

Agreed, and it's nice and easy for anyone already using `.env` files, although the private key used to decrypt the dotenvx key-values is itself a secret.

Yeah i don't understand this. You still need to secure your .env.keys file same as you would be doing with a standard .env. Is the benefit just that you can track it with git?

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#28

Post by kevlened »

hersko wrote: post #27
n31l wrote: post #26

Earlier quoted context omitted.

Agreed, and it's nice and easy for anyone already using `.env` files, although the private key used to decrypt the dotenvx key-values is itself a secret.

Yeah i don't understand this. You still need to secure your .env.keys file same as you would be doing with a standard .env. Is the benefit just that you can track it with git?

Standard .env is unencrypted, while a dotenvx .env file has plaintext keys and encrypted values. Anyone with access to the repo would also need the DOTENVX_PRIVATE_KEY variable to decrypt the env file.

One key deployed to your hosts means adding new secrets doesn't take operations effort. Also, the process uses a public/private key pair, so adding a new variable doesn't expose existing variables.

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#29

Post by jamietanna »

peanut-walrus wrote: post #17

The main problems with these kinds of in-repo vault solutions: - Sharing encryption key for all team members. You need to be able to remove/add people with access. Only way is to rotate the key and only let the current set of people know about the new one. - Version control is pointless, you just see that the vault changed, no hint as to what was actually updated in the vault. - Unless you are really careful, just on…

Re 2 you can implement a custom Git diff tool, and so (with the encryption key) see what's changed, straight from `git diff`

Re: Show HN: Lockenv – Simple encrypted secrets storage for Git

#30

Post by helpfulclippy »

peanut-walrus wrote: post #17

The main problems with these kinds of in-repo vault solutions: - Sharing encryption key for all team members. You need to be able to remove/add people with access. Only way is to rotate the key and only let the current set of people know about the new one. - Version control is pointless, you just see that the vault changed, no hint as to what was actually updated in the vault. - Unless you are really careful, just on…

for 1), seems like you could do a proxy encryption solution.

edit: wrong way to phrase I think. What I mean to say is, have a message key to encrypt the body, but then rotate that when team membership changes, and "let them know" by updating a header that has the new message key encrypted using a key derived using each current member's public key.

Post reply on HN