121–130 of 223 posts
This is the only goal and this tool archives it. In the simplest way. While keeping you as secure as you were before, manually setting envs on heroku, railway, aws, jenkins etc.
GitOps FTW
GOAL: To be able to commit all your envs to git. This is the only goal and this tool archives it. In the simplest way. While keeping you as secure as you were before, manually setting envs on heroku, railway, aws, jenkins etc. GitOps FTW
With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.
dotenv has zero npm dependencies. dotenvx has 21, including a few I have never heard of. Is this really more secure?
Doubly the case now that env is natively supported by node now.
Earlier quoted context omitted.
A lot of modern cloud deployments read from a secret management system or vault at deployment time, and the secrets are made accessible to the application through various indirect methods so they cannot be accessed later on (i.e. if someone were to gain access to a running Kubernetes container). At no point does the application have access to the vault itself, and access to read the vault is guarded by IAM role permi…
Oh well, I really appreciate you taking the time to explain it. But honestly, I didn't understand a word. I recognize it is my lack of knowledge. I hope someone can do me a ELI5.
Instead, they both beat the alternative (which is writing secrets and environmental config directly in the source code). And they’re both part of defending in depth.
Defense in depth is hard to explain to a five year old, so think of candy. You’re five and you’re obsessed with candy. If I don’t want you to eat pounds of it every single day, I’ll likely do different things to stop you.
1.) I’ll give you a reasonable amount of candy.
2.) I’ll explain that if you eat too much candy, you’ll face health consequences like tooth decay or childhood obesity.
3.) I’ll put the candy somewhere both out of sight and out of reach.
Software security is like that too. Instead of relying upon just one method, you’ll do a number of different things. On their own, few of them are really very useful. But when you combine them all together, you can end up with a reasonably secure system.
In the case of vaults, it’s just a slightly safer tradeoff with its own problems. We’ve already established that it’s bad to write secrets and environmental configuration info in source code. One way around that is to put secrets in a .env file but then distributing that file becomes the weak link. Maybe you Slack them around, or email them or maybe you write all the secrets on a whiteboard in your office? A vault has a lot of flaws, but it’s better than writing them on a whiteboard. In some threat models, it’s better than Slack or email.
It adds depth but it’s far from perfect.
With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.
Encrypted with what key? Do you just mean obscured?
With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.
Encrypted with what key? Do you just mean obscured?
Importing a set of library and dependencies to handle reading a plain text file poses more risks than just leaving the file unencrypted. You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those? if someone is in your server you are pwned anyways. It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood. But…
> if someone is in your server you are pwned anyways. This is false and also a symptom of an all-or-nothing approach to cybersecurity, which isn't feasible in the real world.