7 ms·

Show HN: Open-source alternative to HashiCorp/IBM Vault

123 points by vmatsiiako 2y ago

thyrsus 2y ago
I looked at vault, but I opted for a simpler, less flexible solution: rrsync (restricted rsync) to a tree available only to an account with its .ssh/authorized_keys populated with the host public keys with forced rrsync commands restricted to that host's secrets. Root is the only account that can read a host's corresponding private key, so that means an attacker must crack root to get this extra access - but why bother when the secret (e.g. private certificate) is already on the host for root to read? Code to translate the known_hosts into the .ssh/authorized_keys file is a dozen lines more than a perl one-liner only because of triple checking to prevent damage to the result, e.g., in file system full circumstances. Chicken/egg: other means must manage host private keys and ssh_known_hosts. But you had to do that anyways.
martialblog 2y ago
There is also a Vault Fork called OpenBao https://github.com/openbao/openbao https://github.com/openbao/openbao
- shawabawa3 2y ago
  Terrible name imo If they wanted open in the name they should have gone with "opensesame"
  - martialblog 2y ago
    Afaik it is in the spirit of OpenTofu. OpenSesame would have been fun, but a interweb search reveals it appears taken.
  - INTPenis 2y ago
    Couldn't they use something that made more sense like OpenKeystore or OpenKeyvault? I know Hashicorp might be sensitive about them using the word Vault though, I just feel that it should be descriptive more than a game.
    - josegonzalez 2y ago
      At least to me, both of those imply a key-value storage system, not a secrets manager. `OpenSecrets` maybe implies less security to some, and developers tend to want to give products they work on a creative name.
- guappa 2y ago
  There is an "intent to package" for debian about openbao. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069794 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069794
- mirashii 2y ago
  That fork came out of IBM. With this purchase, there's a good chance it recombines with Vault.
minebreaker 2y ago
I'm always looking for the secret management solution for my self hosted apps. This looks very cool, but still unable to solve my biggest problem - how should I manage secrets to access the secret manager? 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.
- MadnessASAP 2y ago
  I hold my vault seal key in my KeePass database. It's set to start and prompt for the master password when I login and it integrates into the FreeDesktop/DBus secrets API (and ssh-agent). Obviously I only need the seal/root tokens when the Vault server reboots. Once it's running it hands out secrets and certificates to everything else.
- regnerba 2y ago
  I find 1Password and their CLI app great for my homelab.
- timrichard 2y ago
  If you run Docker in Swarm mode instead (docker stack deploy instead of docker compose up), then you can make use of Swarm secrets. You don't have to make full use of Swarm; it can be a single node with a single instance of the service(s). As I manage the host with Ansible, I'm able to use Ansible's Docker module with a play to communicate the current secrets to Swarm, so that they are available to the services. On the Ansible side, the secrets are encrypted at rest using ansible-vault.
  - salzig 2y ago
    Swarm mode is IMHO underrated.
  - 9dev 2y ago
    I’ve written a small Python app to deploy to Swarm mode from CI pipelines, and configure secrets and configs from CI environment variables, taking care of rotation and recreating Swarm secrets if the variable content changes. This delegates the whole secret management to the CI tool (BitBucket in my case). 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!
thunderbong 2y ago
Does Infisical have SSH management like Vault? I recently set this up in Vault and it worked very well
akshayKMR 2y ago
Has anyone built or know of a convenient secrets management/workflow for services deployed by systemd? My wants: - Secrets not visible by inspecting process env vars (/proc/PID/environ). - No secrets on disk (encrypted is fine).
- MadnessASAP 2y ago
  *Trigger warning: systemd* systemd does that, SetCredentialEncrypted= https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html 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.
INTPenis 2y ago
Slightly on topic but we've been talking about vaults and keys for years now and I work in CI/CD but I still am no wiser to how I'm supposed to practically use this in my pipelines. 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.
- bogantech 2y ago
  If you use an app role you can define policies that limit the usage of said app role to specific ip addresses, ec2 instance ids etc so that even if someone steals the key it will be useless unless they somehow root the server hosting your application (and if they do that they're getting the secret no matter what) 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.
- Arch-TK 2y ago
  By centralising the secrets storage, you make it easier to change the secrets in one place rather than having to change a bunch of variables everywhere. 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.
- _w1tm 2y ago
  Workload identity federation is the direction the industry is taking. All the hyperscalers have their own version, if you’re on-premise look into SPIFFE.
asteriske 2y ago
Is there an open source alternative to Hashicorp Nomad? It's such a nice alternative to k8s/k3s.
- RandomChance 2y ago
  I'm looking for exactly this.
- cheptsov 2y ago
  Not exactly this, but something related. At https://github.com/dstackai/dstack https://github.com/dstackai/dstack, we build an alternative to K8S for AI infra.
Fabulous3447 2y ago
Bitwarden Secrets Manager might fit your needs as an open source alternative to HashiCorp Vault fyi. I am biased (I work at Bitwarden) but still a great option for those looking to switch from HashiCorp! https://bitwarden.com/products/secrets-manager/ https://bitwarden.com/products/secrets-manager/
- moaf 2y ago
  I always thought that Bitwarden, the password manager, was open source, but the Secret Manager was a paid add-on that was not fully open source. Is that not the case?
thayne 2y ago
It isn't clear how to build this without the enterprise proprietary components, except maybe to fork it and tear out all the code for the ee folders and everything that references it.

123 points by vmatsiiako 2y ago

I looked at vault, but I opted for a simpler, less flexible solution: rrsync (restricted rsync) to a tree available only to an account with its .ssh/authorized_keys populated with the host public keys with forced rrsync commands restricted to that host's secrets. Root is the only account that can read a host's corresponding private key, so that means an attacker must crack root to get this extra access - but why bother when the secret (e.g. private certificate) is already on the host for root to read? Code to translate the known_hosts into the .ssh/authorized_keys file is a dozen lines more than a perl one-liner only because of triple checking to prevent damage to the result, e.g., in file system full circumstances. Chicken/egg: other means must manage host private keys and ssh_known_hosts. But you had to do that anyways.

martialblog 2y ago

There is also a Vault Fork called OpenBao https://github.com/openbao/openbao https://github.com/openbao/openbao

shawabawa3 2y ago
Terrible name imo If they wanted open in the name they should have gone with "opensesame"
- martialblog 2y ago
  Afaik it is in the spirit of OpenTofu. OpenSesame would have been fun, but a interweb search reveals it appears taken.
- INTPenis 2y ago
  Couldn't they use something that made more sense like OpenKeystore or OpenKeyvault? I know Hashicorp might be sensitive about them using the word Vault though, I just feel that it should be descriptive more than a game.
  - josegonzalez 2y ago
    At least to me, both of those imply a key-value storage system, not a secrets manager. `OpenSecrets` maybe implies less security to some, and developers tend to want to give products they work on a creative name.
guappa 2y ago
There is an "intent to package" for debian about openbao. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069794 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069794
mirashii 2y ago
That fork came out of IBM. With this purchase, there's a good chance it recombines with Vault.

minebreaker 2y ago

I'm always looking for the secret management solution for my self hosted apps. This looks very cool, but still unable to solve my biggest problem - how should I manage secrets to access the secret manager? 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.

MadnessASAP 2y ago
I hold my vault seal key in my KeePass database. It's set to start and prompt for the master password when I login and it integrates into the FreeDesktop/DBus secrets API (and ssh-agent). Obviously I only need the seal/root tokens when the Vault server reboots. Once it's running it hands out secrets and certificates to everything else.
regnerba 2y ago
I find 1Password and their CLI app great for my homelab.
timrichard 2y ago
If you run Docker in Swarm mode instead (docker stack deploy instead of docker compose up), then you can make use of Swarm secrets. You don't have to make full use of Swarm; it can be a single node with a single instance of the service(s). As I manage the host with Ansible, I'm able to use Ansible's Docker module with a play to communicate the current secrets to Swarm, so that they are available to the services. On the Ansible side, the secrets are encrypted at rest using ansible-vault.
- salzig 2y ago
  Swarm mode is IMHO underrated.
- 9dev 2y ago
  I’ve written a small Python app to deploy to Swarm mode from CI pipelines, and configure secrets and configs from CI environment variables, taking care of rotation and recreating Swarm secrets if the variable content changes. This delegates the whole secret management to the CI tool (BitBucket in my case). 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!

thunderbong 2y ago

Does Infisical have SSH management like Vault? I recently set this up in Vault and it worked very well

akshayKMR 2y ago

Has anyone built or know of a convenient secrets management/workflow for services deployed by systemd? My wants: - Secrets not visible by inspecting process env vars (/proc/PID/environ). - No secrets on disk (encrypted is fine).

MadnessASAP 2y ago
*Trigger warning: systemd* systemd does that, SetCredentialEncrypted= https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html 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.

INTPenis 2y ago

Slightly on topic but we've been talking about vaults and keys for years now and I work in CI/CD but I still am no wiser to how I'm supposed to practically use this in my pipelines. 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.

bogantech 2y ago
If you use an app role you can define policies that limit the usage of said app role to specific ip addresses, ec2 instance ids etc so that even if someone steals the key it will be useless unless they somehow root the server hosting your application (and if they do that they're getting the secret no matter what) 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.
Arch-TK 2y ago
By centralising the secrets storage, you make it easier to change the secrets in one place rather than having to change a bunch of variables everywhere. 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.
_w1tm 2y ago
Workload identity federation is the direction the industry is taking. All the hyperscalers have their own version, if you’re on-premise look into SPIFFE.

asteriske 2y ago

Is there an open source alternative to Hashicorp Nomad? It's such a nice alternative to k8s/k3s.

RandomChance 2y ago
I'm looking for exactly this.
cheptsov 2y ago
Not exactly this, but something related. At https://github.com/dstackai/dstack https://github.com/dstackai/dstack, we build an alternative to K8S for AI infra.

Fabulous3447 2y ago

Bitwarden Secrets Manager might fit your needs as an open source alternative to HashiCorp Vault fyi. I am biased (I work at Bitwarden) but still a great option for those looking to switch from HashiCorp! https://bitwarden.com/products/secrets-manager/ https://bitwarden.com/products/secrets-manager/

moaf 2y ago
I always thought that Bitwarden, the password manager, was open source, but the Secret Manager was a paid add-on that was not fully open source. Is that not the case?

thayne 2y ago

It isn't clear how to build this without the enterprise proprietary components, except maybe to fork it and tear out all the code for the ee folders and everything that references it.