3 ms·
We use shh for secrets (https://egt.run/shh https://egt.run/shh). It's designed to integrate really well with your existing CLI tools like vim, xargs, and diff
by hellcow 6y ago
We use shh for secrets (https://egt.run/shh https://egt.run/shh).
It's designed to integrate really well with your existing CLI tools like vim, xargs, and diff. It offers user-based permissions, and secrets are encrypted into a single file that's safe to commit into your git repo. We can stream secrets out of it directly to our remote servers during deploys.
Unlike Vault you don't need to manage infra to run it -- it's just a file. Unlike cloud secret managers, there's no lock-in.
- ahnick 6y agoA couple of questions.. 1. Does every client have a copy of shh to interact with the secrets? Or are the secrets in the file served from a single centralized node? 2. What is your process of exchanging user keys with shh? 3. If someone leaves the company, what is the process you go through to change the secrets and rotate keys?
- hellcow 6y ago1. Every client (i.e. developer) has their own copy of shh but interacts with a shared .shh file in the project root. Secrets can be decrypted locally in memory then streamed to the remote servers over ssh. You could in theory run this on a server to help address your third point. 2. Exchanging public user keys is done via email when an employee starts, then added to the .shh file and committed in the repo. 3. You'd need to write a script for this, which probably involves `shh rm-user {email}`. There is no silver bullet here for changing secrets; since developers have access to secrets, any secret they had would need to be regenerated. `shh` makes no assumptions about how you deploy, what secrets you keep, or their formats.