3 ms·
That would require no secrets. All it takes is a misclick into a .env file. I’d assume you’re not coding on a production system so your secrets shouldn’t be to
by corobo 6y ago
That would require no secrets. All it takes is a misclick into a .env file.
I’d assume you’re not coding on a production system so your secrets shouldn’t be too hard to revoke, cycle them after your stream and any time you leak them.
- evan_ 6y agoPut a couple hundred line breaks at the top of your .env file so if you open it it’s just white space
- xxpor 6y agoSecrets should really be stored in services, not files outside of maybe a single bootstrap file (unless you're working on the secret storage service itself). I generate my secrets once, send them off to the secrets service, and then my service queries that service. I never see the secrets with my own eyes.
- tnorthcutt 6y agoCan you expand on this? What service do you use to store your secrets?
- dividedbyzero 6y agoWhat are you using for this? This sounds like a neat setup.
- corobo 6y agoIt is a single bootstrap file, it bootstraps your env variables I've not come across what you describe
- this-pony 6y agoThis sounds like a turtles all the way down kind of think... Then is it OK to keep the secret of the secrets service, or something in that sense.
- dfee 6y agoThe idea is that you keep the name of the secret, and grant access to the secret manager via roles / policies which are generally open to devs on a subnet for a development environment but locked down in production environments.
- VikingCoder 6y agoI think we're probably agreeing with each other, except I'm not willing to call those things "secret." They're public. If you can plan to properly publicize something, great. But work _hard_ to make sure you're really okay publicizing it.