3 ms·
I've seen Python CLI apps for internal tooling being very maintainable and setting up a Makefile with an "install" task makes it easy for everyone in the team t
by frenchman99 5y ago
I've seen Python CLI apps for internal tooling being very maintainable and setting up a Makefile with an "install" task makes it easy for everyone in the team to get started.
> Simple, you get the secrets very rarely: at deployment.
Do you mean writing custom scripts to get secrets? Where do you store secrets in such a scenario? What if you need to change secrets at runtime.
Vault is nice in that you can fine grain access:
- ACLs which allow some team members to be responsible for setting secrets and other team members for using them,
- temporary credentials for well known DBMSs which helps secure logs from leaks,
- PKI Management,
- temporary SSH keys.
And more. Not sure how you'd get that with a deploy time script.
- trabant00 5y ago> Where do you store secrets in such a scenario? Anywhere basically, a HTTP server with directory listing is enough. You don't need to roll your own security management, you can just encrypt secrets with ssh or pgp keys. > What if you need to change secrets at runtime I certainly don't need that as an infrastructure engineer. If you want that for development be my guest, pay the exorbitant Vault license and don't come crying to me Vault is down. Vault is always down, you just introduced a critical runtime dependency on an immature solution. Your problem, I have the email to prove you took responsibility for this decision against my recommendation.
- frenchman99 5y agoYou can totally have multiple secrets' sources: one for development that takes secrets from a plain text local file and one for production that takes secrets from Vault. I don't see an issue here. Also, what's immature about Vault?
- trabant00 5y agoHave you used in production at a decent scale for significant time? It's an SLA killer.