Lately, I’ve been thinking of implementing a secrets management system such as Infiscal, etc. Does anyone use this or something similar like Hashicorp?
How hard would it be to deploy on a pre-existing set up? How does that work? Do you call the required secret in your Docker compose? What makes a secret manager more secure than pulling secrets from an .env file?
Which secret manager is the most popular/better among selfhosters?
There’s a software called gravitational teleport that looks pretty neat.
I think it’s overkill for homelab and over complex/additional failure points.
I use sops encrypted, published in my public git. When I apply my nix config, they are pulled and unencrypted on apply on the local machine.
Keeps it as simple as I can think of, with few moving parts.
I think it’s overkill for homelab
How about a remote VPS?
Depends on the circumstances tbh. Things like sops do load the secret unencrypted on the machine (with perms but still unencrypted. For remote VPS encrypted at rest is probably better. K8S has secret management but there unencrypted too.
Another alternative could be using Doppler secrets managment platform, I used it for a while
I doubt using secret managers is popular among self hosters. These products are targeted at larger deployments, not homelabs.
I have seen people use Ansible Vault to encrypt the .env file and use an ansible playbook to only decrypt the file when the playbook is running.
Ansible is one of those ‘on the list’ things to check out. It seems to have a broad range of applications.
Sounds like you have reason to bump it up the list now - two birds with one stone.
I need to do this too. I know I have stuff deployed that has plaintext secrets in .env or even the compose. I’ll never get time to audit everything. So the more I make the baseline deployment safe, the better.
Is it a single server? Maybe something like sops is all you need
There’s an oss fork of vault now as well. Openbao.
Is it a single server?
Well I run a hybrid set up of 3 VPS and one rack in the closet.
Maybe something like sops is all you need
Unpack that a little for me if you would.
Normally you wouldn’t need a secrets store on the same server as you need the secrets, as they are often stored unencrypted by the service/app that needs it. An encrypted disk might be better in that case.
That said, Vault has some useful features like issuing temporary credentials (eg. for access to AWS, DBs, servers) or certificate management. If you have these use-cases, it could be useful, even on the same server.
At my work, we tend to store deployment-time secrets either in protected Gitlab variables or in Vault. Sometimes we use AWS KMS to encrypt values in config files, which we checkin to git repositories.
as they are often stored unencrypted by the service/app that needs it
That’s what I’m worried about
An encrypted disk might be better in that case.
See, that is one of the ideas I’ve been toying with. I’ve never encrypted a remote VPS. I have encrypted all my local drives. There is some response loss on local drives it seems to me. Negligible, but still. I’m just wondering if there would be a performance hit.
Encryption will typically be CPU bound, while many servers will be I/O bound (eg. File hosting, rather than computing stuff). So it will probably be fine.
Encryption can help with the case that someone gets physical access to the machine or hard disk. If they can login to the running system (or dump RAM, which is possible with VMs & containers), it won’t bring much value.
You will of course need to login and mount the encrypted volume after a restart.
At my work, we want to make sure that secrets are adequately protected at rest, and we follow good hygiene practices like regularly rotating credentials, time limited certificates, etc. We tend to trust AWS KMS to encrypt our data, except for a few special use cases.
Do you have a particular risk that you are worried about?
Do you have a particular risk that you are worried about?
A couple of the Docker compose files I’ve used have non-hashed secrets in the compose itself. I am assuming, should someone penetrate the firewall, and gain access to Portainer somehow, they could see these compose entries just like I can. While I feel like I have adequately hardened the server (Lynis reports a score of 87) and I have rather robust ids/ips, firewall, and assorted accoutrements to support a secure server, there’s always that ‘what if’ scenario running in my brain and it causes doubt. Perhaps a secrets manager is over kill for a single user, docker container server.
Yeah, at that point I wouldn’t worry. If someone has docker access on the server, it’s pretty much game over.
In my homelab I use Bitnami’s sealed secrets to commit the encrypted secrets to git and deploy with ArgoCD.
That’s a K8s application I’ve never explored, and the ‘commit the encrypted secrets to git and deploy with ArgoCD’ is well above my pay grade at the moment. Not saying it’s not unattainable, however, I’m still trying to thoroughly understand Docker, which should take me quite a while. LOL
Oh, I didn’t realize this was for plain containers, sorry.
For that I use Ansible to deploy the containers in my server. The secrets are stored encrypted in my local machine with passwordstore and I use the passwordstore lookup plugin to load them in the playbooks/templates.
There are numerous automated systems for this, and almost every platform you use will have their own. Infiscal doesn’t seem bad, but I haven’t used it.
I always suggest engineers just use whatever is closest to their stacks instead of implementing something, UNLESS it’s going to cost a lot more money (looking at you, AWS).
Bitwarden/Vaultwarden+BWcli is also another workaround if you’re just using it for small projects.
Etcd can do value encryption, and Redia even, but you should really be looking at something that has solid RBAC, or ZTC rotation.
