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.
DMNO creator here - sensitive config values are able to be retrieved from a variety of backends using a flexible plugin system. We are certainly not telling you that you have to use the encrypted file method, and depending on the security requirements of your project it may not be a good choice. You can also mix and match those plugins, and segment items however you see fit - so it's not always a single key being passed around.
That said, it is a valid way that some folks use (see
https://dotenvx.com/, https://github.com/AGWA/git-crypt, https://github.com/getsops/sops) which can make sense for simpler projects with less stringent security needs. The bonus here is it does not require setting up, paying for, or integrating any external service, and helps save you from "secret sprawl".
We have a plugin for 1password (which many teams are already using anyway) and have plugins planned for many other popular tools, including Infisical.
Many other tools only really make sense for bigger enterprises, either due to cost, complexity, or both. Our goal here (or one of them anyway) is to make a tool that provides enough value to use in all cases, from very small and simple to very large and complex.
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.
DMNO creator here - sensitive config values are able to be retrieved from a variety of backends using a flexible plugin system. We are certainly not telling you that you have to use the encrypted file method, and depending on the security requirements of your project it may not be a good choice. You can also mix and match those plugins, and segment items however you see fit - so it's not always a single key being passed around.
That said, it is a valid way that some folks use (see https://dotenvx.com/, https://github.com/AGWA/git-crypt, https://github.com/getsops/sops) which can make sense for simpler projects with less stringent security needs. The bonus here is it does not require setting up, paying for, or integrating any external service, and helps save you from "secret sprawl".
We have a plugin for 1password (which many teams are already using anyway) and have plugins planned for many other popular tools, including Infisical.
Many other tools only really make sense for bigger enterprises, either due to cost, complexity, or both. Our goal here (or one of them anyway) is to make a tool that provides enough value to use in all cases, from very small and simple to very large and complex.
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.