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.<p>Can someone link something that explains it like I have 20 years in IT but I'm clueless.<p>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?<p>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.
There is also a Vault Fork called OpenBao <a href="https://github.com/openbao/openbao">https://github.com/openbao/openbao</a>
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?<p>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.
Has anyone built or know of a convenient secrets management/workflow for services deployed by systemd?<p>My wants:<p>- Secrets not visible by inspecting process env vars (/proc/PID/environ).<p>- No secrets on disk (encrypted is fine).
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! <a href="https://bitwarden.com/products/secrets-manager/" rel="nofollow">https://bitwarden.com/products/secrets-manager/</a>
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.
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.