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.
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 :)
you're enrolling a particular users public/key and encrypting a symmetric key using their public key, not generating a single encryption key which you distribute. You can roll the underlying encryption key at any time and git-crypt will work transparently for all users since they get the new symmetric key when they pull (encrypted with their asymmetric key).
> Version control is pointless
git-crypt solves this for local diff operations. for anything web-based like git{hub,lab,tea,coffee} it still sucks.
> - Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
With git-crypt, if you have gitattributes set correctly (to include a file) and git-crypt is not working correctly or can't encrypt things, it will fail to commit so no risk there.
You can, of course, put secrets in files which you don't chose to encrypt. That is, I suppose, a risk of any solution regardless of in-repo vs out-of-repo encryption.
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.
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.
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.
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.
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.
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.
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
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.
That's handy and obviously a major security increase compared to sharing on Discord, but I feel compelled to quote the age README:
> Keep in mind that people might not protect SSH keys long-term, since they are revokable when used only for authentication, and that SSH keys held on YubiKeys can't be used to decrypt files.
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.
it strikes me as reasonable for 1-10 people teams (well, small businesses).
the real problems/risks only creep up for mid to big size businesses, which i don't think the tool is concerned with.
from my understanding the big problems would be:
- auditing/leaking risks that come with bigger headcount/turnover
- bad uncontrolled use & problems with policy
- operational inertia when problems happen
these are not real for most (healthy) small teams.
the really touchy problem is decryption key management and running state management.
Consider even just the chance that at some later point you want to remove the secrets. Now you have to rewrite history and also force that on all contributors.
at that point keep them in there, quit using the "secrets in repo" strategy from now on and rotate all your secrets in your new vault.
you also have the option to cut a new repo. it's a small team, you don't have behemoth inertia.
(secrets in repo if your code is open-sourced is indeed not a good idea at any scale. it's also a bad idea if your secrets cannot be easily meaningfully rotated, like putting your social security number in a secret.)
- Maintaining stateful secrets at rest gives me the heebie-jeebies.
- The tools shouldn't let me shoot myself in the foot.
- The tools should ideally not have such a high learning curve that I won't actually use them.
You can put your secrets in a separate repository and not think of them as the same kind of repository you'd publish.
Like... I wouldn't put a git-crypt'ed / sops-nix'ed repository online, simply because I don't like the idea that now anyone needs is brute-force; I know quantum computers aren't there yet wrt. brute-forcing stuff made by random people like me, but even hypothetically having this attack vector open, I don't like it.
So there's only two good solutions:
- You put secrets in a (hashicorp-style) vault that only decrypts temporarily in memory.
- You put secrets in an encrypted database with only safe tool integration.
The things I don't like about git-based secrets management:
1. You might mix your secrets into projects and then later someone else might release that (against your current interest)
2. The solutions I've seen (sops-nix, agenix, secrix, etc.) are hard to set up and even harder to onboard people on
When something's hard to set up, you might make a mistake or skip some concept.
Well-done secrets management that isn't based on a service like AWS Secrets og GitHub Secrets should be much, much easier.
I like the idea of how easy this is. Now, if it would just be best practice in every possible way at the same time.
The (admittedly well-known) problem with lockenv is that you can't revoke access once a password is known.
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.
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 :)
git-crypt solves all 3 (mostly)
> Sharing encryption key for all team members
you're enrolling a particular users public/key and encrypting a symmetric key using their public key, not generating a single encryption key which you distribute. You can roll the underlying encryption key at any time and git-crypt will work transparently for all users since they get the new symmetric key when they pull (encrypted with their asymmetric key).
> Version control is pointless
git-crypt solves this for local diff operations. for anything web-based like git{hub,lab,tea,coffee} it still sucks.
> - Unless you are really careful, just one time forgetting to encrypt the vault when committing changes means you need to rotate all your secrets.
With git-crypt, if you have gitattributes set correctly (to include a file) and git-crypt is not working correctly or can't encrypt things, it will fail to commit so no risk there.
You can, of course, put secrets in files which you don't chose to encrypt. That is, I suppose, a risk of any solution regardless of in-repo vs out-of-repo encryption.
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.
Re 2 you can implement a custom Git diff tool, and so (with the encryption key) see what's changed, straight from `git diff`
Here's another one:
- using a third party tool to read and store credentials is an attack vector itself.
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...)
> or 1Password vaults are harder to work with
https://1password.com/blog/1password-environments-env-files-...
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).
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.
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.
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.
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 :)
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.
> stop pasting secrets into Slack
You got me interested. I've seen sharing of API keys via Discords in hackathons.
You can use the age tool to encrypt secrets based on ssh public keys.
Here's a small shell script I use https://github.com/mhitza/toolbox/blob/main/scripts/encrypt-...
That's handy and obviously a major security increase compared to sharing on Discord, but I feel compelled to quote the age README:
> Keep in mind that people might not protect SSH keys long-term, since they are revokable when used only for authentication, and that SSH keys held on YubiKeys can't be used to decrypt files.
https://github.com/FiloSottile/age?tab=readme-ov-file#encryp...
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?
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.
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.
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).
it strikes me as reasonable for 1-10 people teams (well, small businesses).
the real problems/risks only creep up for mid to big size businesses, which i don't think the tool is concerned with.
from my understanding the big problems would be:
- auditing/leaking risks that come with bigger headcount/turnover - bad uncontrolled use & problems with policy - operational inertia when problems happen
these are not real for most (healthy) small teams.
the really touchy problem is decryption key management and running state management.
Consider even just the chance that at some later point you want to remove the secrets. Now you have to rewrite history and also force that on all contributors.
at that point keep them in there, quit using the "secrets in repo" strategy from now on and rotate all your secrets in your new vault.
you also have the option to cut a new repo. it's a small team, you don't have behemoth inertia.
(secrets in repo if your code is open-sourced is indeed not a good idea at any scale. it's also a bad idea if your secrets cannot be easily meaningfully rotated, like putting your social security number in a secret.)
Committing the vault to git gives me the heebie-jeebies. (Not that I have a better solution with anything like this convenience.)
The way I think about it is:
You can put your secrets in a separate repository and not think of them as the same kind of repository you'd publish.Like... I wouldn't put a git-crypt'ed / sops-nix'ed repository online, simply because I don't like the idea that now anyone needs is brute-force; I know quantum computers aren't there yet wrt. brute-forcing stuff made by random people like me, but even hypothetically having this attack vector open, I don't like it.
So there's only two good solutions:
The things I don't like about git-based secrets management: When something's hard to set up, you might make a mistake or skip some concept.Well-done secrets management that isn't based on a service like AWS Secrets og GitHub Secrets should be much, much easier.
I like the idea of how easy this is. Now, if it would just be best practice in every possible way at the same time.
The (admittedly well-known) problem with lockenv is that you can't revoke access once a password is known.
It's a big ask.
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 :)