Secrets Management? Alternative to Hashicorp `Vault`?

[nelsonic]

We need a way to seamlessly share highly secure secrets as a Team. Specifically if more than one person in the team is testing the Auth App [running on localhost], there will are at least 10 evironment variables to be shared: https://github.com/dwyl/auth/blob/main/.env_sample We've done this in the past by sharing a .txt file via Signal. This works in a pinch because it's end-to-end encrypted, but it's really not a good way of doing it. 💭

At companies we've worked in the past the DevOps teams have used Hashicorp Vault: https://www.vaultproject.io

Just signed up and to launch a Vault instance is $25.92/month ...

Just to store secrets ... 💸 Feels like this should be a Serverless App that only runs when people are using it. Is there already a way of doing this where a Serverless App stores data strongly Encrypted on S3 and has strong access controls and team management?

Need to make time to investigate this so that sharing secrets with new team members is faster. 🚀 For now just going to continue using the Signal approach ... 💭

[SimonLab]

A simple solution if people have access to Fly.io application is to run flyctl ssh console then run printenv. It will display all the environment variables defined for the application.

It's simple and show the values that are actually used by the application. It might not be enough if we want more features from a secret management tool

[nelsonic]

@SimonLab thanks for reminding us of this option. It works for us currently. Though we will soon be "locking-down" this option and no new members will have access to prod.

Perhaps I should have made it clearer there are multiple requirements for a secrets management system of which none are satisfied by sharing access to the Fly.io instance for extraction of real (staging or production) Environment Variables or Data! Granting someone access to Fly.io means they can decrypt and read personal data stored on the Auth instance ... no bueno. 🙅

1. For a new individual contributor we definitely don't want to give them access to any Fly.io instances. Not because we don't "trust" them (though we shouldn't ...
   see: https://en.wikipedia.org/wiki/Trust_no_one_(Internet_security) ) Rather because we want anyone to be able to run Auth on their localhost without any intervention/permission from us. Someone learning PETAL that wants to proactively get started shouldn't have to axsk for permission to get access to Environment Variables.

Note: I'm thinking of making the localhost Env Vars in .env_sample real i.e. they will work! The risk is comparatively low. The keys won't be valid on any other env than localhost And will belong to a totally separate GitHub/Google/MSFT account.

2. We want to limit access to the Production Auth instance to the absolute minimum people this means that only a handful of people with great security hygiene (i.e. no cracked software or other attack vectors) on their PC.

As for "core" team members (those who are paid) we will still need a way of granting access to secrets that doesn't involve granting them access to Fly.io which we will 100% restrict and that needs to be clear to everyone. Ideally nobody should have access to Prod. but since that's technically infeasible, only 2 of us have access and we're never on the same flight/car, etc. You know, CocaCola Formula Protocol: https://en.wikipedia.org/wiki/Coca-Cola_formula#History

I've only opened this issue to capture our near-future needs. While there are only a handful of us, we can still send a secret via Signal. But in the future we need a proper system for this that tracks access and revocation. 💭

[nelsonic]

https://github.com/Infisical/infisical via: https://news.ycombinator.com/item?id=37090754 However the top comment is a warning.