Any suggestions for secrets management to distribute API keys/DB secrets/etc.?

For a self-hosted use case.

Currently, manually SSH into VPs and updating env files but not sure if its best practice.

CGamesPlay 2 days ago | parent | next [-]

SOPS reduces the surface area you need to cover. You can use Age as a backend and then you only need a long lived private key on the server. https://github.com/getsops/sops

▲

Nextgrid a day ago | parent [-]

The bad guys will steal that private key and decrypt the encrypted secrets the same way they can steal the unencrypted secrets directly.

	▲	CGamesPlay a day ago \| parent [-]
		If they are already in your server, what are you protecting then?

▲

Nextgrid a day ago | parent | prev | next [-]

If it's a single application exposed to the internet that is using those tokens then an env file is perfectly fine. If the application gets breached the secrets will be in memory anyway (as the app needs them to do its work), so they will get exposed no matter how they were sourced.

If your vendors support IP-based restrictions (few do, thanks to "zero trust" and other bullshit), a very strong defense would be to enable that and restrict use of those secrets to your server's IP, so that the tokens become useless to anyone else even if leaked.

▲

SlightlyLeftPad 2 days ago | parent | prev [-]

I’d use the native secrets of your VM platform or something like 1password with an functional API.

	▲	Nextgrid a day ago \| parent [-]
		Yes if you get the hypervisor to provide the secrets this in theory means the secrets will be safe at rest... but if the VM gets breached (which is the scenario we're assuming here, as his VM is the one handling untrusted traffic from the internet), the secrets still get out. One option is to use separate "proxy" VMs that proxy traffic to the external services and applies the secret. The main application VM uses those proxy VMs to talk to the external services. This means a compromise of the application VM will not be able to exfiltrate any secrets - it will merely be able to make use of them (by talking to the proxy VMs) while the attacker still has access. Post-breach remediation becomes easier as not only do you not need to rotate the secret (as it wasn't stolen, merely misused) but your proxy VM can provide a tamper-proof audit log to tell which malicious activity has happened, if any.