Personally I appreciate how straightforward and dead-simple environment variables are. Easy to check values with `env | grep ...', I'm content.
This looks rather complicated. What is the advantage here, i.e. Why is my existing configuration "dumb" and "unsafe" (the opposite of what dnmo purports to be)?
I like the simplicity of envars too, but they shouldn't be used for secrets. They are not designed to be secure, and are too easy to leak. Containers often allow placing secrets into files, and specifying the filepath in an envar. Files have access controls that are designed for security, so while it takes some thought, they are easier to secure.
It appears to me that DMNO gathers then sets your environment variables at run time. It can gather them from a local config or from a multitude of network locations like a git repo or a website or a S3 bucket or run a function to calculate it now.
You could already be doing all that with any scripting language, maybe Ansible and friends, but DMNO is more focused and seems to depend on Vite, so it’s also got a narrower (but huge) audience.
DMNO also includes multiple features that test if any environment variables are being accidentally leaked somehow.
> Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
Don’t do this. Having all your secrets in git, encrypted with the same key, allows anyone with access to the repository to try decrypting sans any throttling. By looking at older commits, they get a helpful list of comparison values to infer your rotation schedule (if any) or possibly interesting targets.
If the attacker succeeds, or even just an employee with the decryption key leaves, you’ll need to rotate every single secret at once; you don’t control access to the secrets and don’t have an audit log, except for maybe logs of the git server.
I repeat: do not store secrets in git. Set up Vault or Infisical, or your cloud provider‘s secret management solution, and do it properly.
Personally I appreciate how straightforward and dead-simple environment variables are. Easy to check values with `env | grep ...', I'm content.
This looks rather complicated. What is the advantage here, i.e. Why is my existing configuration "dumb" and "unsafe" (the opposite of what dnmo purports to be)?
I like the simplicity of envars too, but they shouldn't be used for secrets. They are not designed to be secure, and are too easy to leak. Containers often allow placing secrets into files, and specifying the filepath in an envar. Files have access controls that are designed for security, so while it takes some thought, they are easier to secure.
It appears to me that DMNO gathers then sets your environment variables at run time. It can gather them from a local config or from a multitude of network locations like a git repo or a website or a S3 bucket or run a function to calculate it now.
You could already be doing all that with any scripting language, maybe Ansible and friends, but DMNO is more focused and seems to depend on Vite, so it’s also got a narrower (but huge) audience.
DMNO also includes multiple features that test if any environment variables are being accidentally leaked somehow.
Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
Having a proper schema on secrets is also nice, I've ran into problems where a dev changed the name of a secret and broke everyone's local dev setup.
> Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
Don’t do this. Having all your secrets in git, encrypted with the same key, allows anyone with access to the repository to try decrypting sans any throttling. By looking at older commits, they get a helpful list of comparison values to infer your rotation schedule (if any) or possibly interesting targets.
If the attacker succeeds, or even just an employee with the decryption key leaves, you’ll need to rotate every single secret at once; you don’t control access to the secrets and don’t have an audit log, except for maybe logs of the git server.
I repeat: do not store secrets in git. Set up Vault or Infisical, or your cloud provider‘s secret management solution, and do it properly.
4 capital letters
https://www.youtube.com/watch?v=Yt0kHiRsnHA&t=1880s
"printed in gold, 'cause plaintext makes the folks sweat"
Is there some sort of explanation of what DMNO is?
https://dmno.dev/docs/get-started/what-is-dmno/
Somehow I knew just from the title that this would be a JavaScript project.