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
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.
> 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 it is way too easy to blindly rely on built-in permission management. People implicitly assume that removing a person's 1Password access means they can no longer rely the underlying resource - but in practice they could've copied the secret onto a sticky note at any time, and it's not safe until you've rotated the secret!
With shared user accounts there's at least usually the possibility of using 2FA - but that's not exactly going to work with things like deployment tokens intended for automated use...
Of course in an ideal world we wouldn't have those kinds of secrets and we'd all be using short-lived tightly-scoped service accounts - but we don't live in an ideal world.
Absolutely agree. That is exactly why I made this tool - my projects usually don't have ansible, github, aws and other external dependencies, or have different sets of such dependencies, and teams are too small to use something enterprise level.
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.
We all keep reinventing the same thing :)
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.
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 it is way too easy to blindly rely on built-in permission management. People implicitly assume that removing a person's 1Password access means they can no longer rely the underlying resource - but in practice they could've copied the secret onto a sticky note at any time, and it's not safe until you've rotated the secret!
With shared user accounts there's at least usually the possibility of using 2FA - but that's not exactly going to work with things like deployment tokens intended for automated use...
Of course in an ideal world we wouldn't have those kinds of secrets and we'd all be using short-lived tightly-scoped service accounts - but we don't live in an ideal world.
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.
You got me interested. I've seen sharing of API keys via Discords in hackathons.
I have a git-based sync tool for my dotenv files. Maybe I can store my ssh keys, too