by peanut-walrus
5 subcomments
- 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 one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
- 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 repository just seems off to me. I don't like the idea of keeping the secrets (even in encrypted form) with the code I'm deploying.
There should be a better balance somewhere, but I'm not sure this is quite it for me. Shared keepass files (not in git) or 1Password vaults are harder to work with, but I think lean more towards the secure side at the expense of a bit of usability. (Depending on the team, OSs, etc...)
- I’ve been using git-crypt⁽¹⁾ which is transparent (you put the patterns you want to encrypt in .gitattributes) and lets you use GPG keys or symmetric keys. And it's been around for quite a while.
⁽¹⁾https://github.com/AGWA/git-crypt
- This looks nice, but I think I lean towards fnox (by the author of mise) - because of the flexibility and support for external storage:
https://github.com/jdx/fnox
- Very similar to a tool I built about a year ago! We've been using it with our 6-person team, and it's been working great. It uses a shared keyring.json to manage public keys, so we don’t have to duplicate the same keys across every repo.
https://github.com/stefanoverna/kavo
It’s built on top of age for encryption (https://github.com/FiloSottile/age).
by jillesvangurp
2 subcomments
- 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 are outside your team would require you to change any credentials they might have.
In our case, our team is small and I simply ignore this problem. So, we have a keepass file with shared secrets and repositories with encrypted properties files and a master password in this keepass file. Mostly, it's just me handling the password. It also gets configured as a Github secret on repositories for CI and deployment jobs. It works. But I'm aware of the limitations.
This is an area where there are lots of tools but not a whole lot of standardized ones or good practices for using them. It's one of those things that acts as a magnet for enterprise complexity. Tools like this tend to become very unwieldy because of this. Which is why people keep reinventing them.
by andreineculau
0 subcomment
- I understand the simplicity angle. https://github.com/elasticdog/transcrypt has been around for a long time and strikes that balance very well in my opinion. And it's just a bash script that can also be committed so the git repo is atomic.
- This is great! Coincidentally, I just started replacing my collection of bespoke security bash scripts with an app like yours. WIP here: https://github.com/leolimasa/age-vault
We all keep reinventing the same thing :)
by Barathkanna
1 subcomments
- This actually looks handy for the “small team with a couple of env files” use case. Most secret-management tools are great once you’re at scale, but trying to explain sops or git-crypt to a team that just wants to stop pasting secrets into Slack is… not fun. A simple password-protected vault committed to git is a reasonable middle ground.
I like the OS keyring integration too,removes a lot of friction. Curious how it behaves in multi-machine workflows and whether you plan to add any guardrails around accidental plaintext commits, since that’s usually where lightweight tools get tripped up.
by madeforhnyo
1 subcomments
- Being a node dev - by necessity, I've settled on dotenvx [0] for committing encrypted .env files.
[0] https://dotenvx.com/
by mrinterweb
0 subcomment
- This reminds me of how rails manages encrypted credentials. https://guides.rubyonrails.org/security.html#custom-credenti.... The big differences, this is portable and sets values as session env vars instead of application vars.
by sureglymop
1 subcomments
- I understand the thought but my honest advice is: do not commit secrets to git, even if they are encrypted.
Secrets are not configuration, they are state (and I would say, an even stricter form of state that should ideally only exist at runtime in memory).
by chrisweekly
1 subcomments
- Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)
by akabalanza
0 subcomment
- That looks amazing, thanks for sharing!
I have a git-based sync tool for my dotenv files. Maybe I can store my ssh keys, too
- I use a Makefile target with GPG :)
Hacker News