3 ms·
I’m a huge fan of the berglas approach where you pass “location” of the secrets in env vars and the app loads them by itself. This allows you to keep permissio
by seer 4y ago
I’m a huge fan of the berglas approach where you pass “location” of the secrets in env vars and the app loads them by itself.
This allows you to keep permission grants separate, and you can safely send “.env” files and (gasp) save them in version control.
You can change where and how you store and encrypt them, rotate keys etc. all transparently.
- mLuby 4y agoAm I understanding correctly that everyone with read access to your version control also has your production secrets?
- tnzk 4y agoI guess it's about to check in just .env file, not files that contain secrets.
- austinjp 4y agoNot the secrets themselves, but their location, eg /opt/secrets/some-database.sqlite3 I'm not parent commenter, but that's how I've done it before. The file on disk has the appropriate permissions etc. I'm sure there are issues with this, so if anyone can enlighten me I'd be interested.
- sph 4y agoThat's a unix access problem. It's a little harder to do on containers, but the UNIX way is having the secrets file root-readable only, your daemon spawns as root, reads the configurations and drops down to a less privileged UID.