Show HN: Open-source alternative to HashiCorp/IBM Vault
github.com
github.com
Can someone link something that explains it like I have 20 years in IT but I'm clueless.
I can't get past the fact that a key has to exist somewhere, a key that will give you some sort of access to a secret. So how is it any better if the key already exists in the CI/CD pipeline variables?
Another thing I'm curious about is rotation, which on paper is amazing but in practice would require your vault to have sysadmin access to all your systems, in order to do rotation. It just seems like a tall order to integrate.
The idea is that there is some system that is capable of provisioning access credentials and automatically providing them to resources based on their identity. This could be your CI runner, scping auth credentials into known locations when the system is deployed. This could be your cloud provider, using something like IAM roles and the metadata service. This could be your kubernetes cluster, providing a mount inside the container. Ideally this system is also capable of rotating these credentials too.
Then you have another system which is able to verify those credentials to give access. If you're fancy, you're doing something like mTLS on all your internal network calls so every endpoint on the other hand is verifying every other endpoint, but it could also be something like secrets manager or vault just dispensing out API keys based on your systems credentials provided in the previous step.
There is definitely a tradeoff here that the system that manages the credentials effectively has the keys to the kingdom and could if compromised provide identity for anything. Some companies respond to this by delegating the whole lot to their cloud provider, which has its own risks of course.
The advantages of doing this are basically:
- You only have to manage one set of credentials manually (whatever your system managing the instance/service identity is)
- You can then easily make credentials for things accessing each other short lived if you know they're getting replaced periodically, which helps reduce the impact of breaches/leaks
- Depending on your specific implementation, you can avoid secrets hitting disk entirely, which further helps reduce the impact of breaches.
As for how you change the secrets? You should have some automated way of pulling the current secret out of the vault, storing a future secret in the vault, performing an upgrade of the secrets, verifying the new secrets are deployed everywhere, and then moving the "future secret" into "current secret" and keeping a historical copy of the "previous secret".
Whatever configures your infrastructure automatically will already need to have root access to everything and so that's a good place to implement the rotation.
The system reading the token can verify its integrity based on the signature.
Now the vault obviously must have a master key to do the signature. It’s a very powerful privilege, that can impersonate, yet not quite as privileged as being sysadmin to all systems.
The main advantage of this is that tokens that the users use can quickly be revoked. They always need to go back to the vault to get new tokens, here you can add more powerful protections and logs, always MFA.
So what actually should happen here is your pipeline mints a JWT token with some near term expiry per run.
You send that token to vaults JWT endpoint, and it validates that it knows the issuer and the signature matches the provided keys.
When configuring the vault side, you can further validate the signed token data which will include things like the scm org, the repository name, the actor ( user who made the commit ), whether or not it's a PR, what branch it's against, whether the repository is private.
From there you can set roles within vault that allows different policy per risk, i.e. random PRs from the public shouldn't get deployment secrets.
https://docs.github.com/en/actions/deployment/security-harde...
You can do same with gitlab. Technically you don't need vault, you can auth direct to aws, azure, etc.
Even with a regular token the benefit is that if it is leaked (say, by a git commit etc) this by itself doesn't grant you access to the actual secret because it is stored in vault, and you'd need to have connectivity to the vault server(s) to make use of it.
If they wanted open in the name they should have gone with "opensesame"
In my day job, we use AWS SSM. It works great. For my home network, I just put secrets on my docker-compose.yaml. Obviously I shouldn't but I can't find a better solution.
The default implementation in Swarm has the problem that you cannot update secrets, so you’ll need to reconfigure and redeploy the service with a secret with a new name if that changes. That was quite a pain!
My CI runs as a container in that stack too, so in Jenkins I have an init.d Groovy script to establish Jenkins Credentials from the current Swarm secrets.
It looks unmaintained, unfortunately, and a link in the README to an article that gives some background is broken (but archived: https://web.archive.org/web/20201128160302/https://www.egt.r...)
Like I said, I haven't used it, I can't vouch for it, but it looked interesting for my own use, which is personal/small team, with an emphasis on simplicity.
Take that for what it's worth! :)
It's owned by VMware (Broadcom) now, so you have to decide which company you hate less.
My wants:
- Secrets not visible by inspecting process env vars (/proc/PID/environ).
- No secrets on disk (encrypted is fine).
systemd does that, SetCredentialEncrypted= https://www.freedesktop.org/software/systemd/man/latest/syst...
Provide a TPM encrypted credential (made by systemd-cred) and it will be decrypted and placed in a memory backed file within a private namespace mount.