3 ms·

Secrets in env vars in production is not too secure either, ideally you’ll move to your app pulling secrets in-process from your infrastructure at boot-up or up

• Etheryte 2y ago
  This just moves the problem to a different step. How are you going to manage access to said secrets, especially when your application lives off premises?
  • nevir 2y ago
    Many hosting environments give you this. For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)
    • jitl 2y ago
      This is still “env vars”, easy to read from /proc/*/env too see the decrypted secrets from a different process. Versus in-process only secret fetch where you’d need to scan the memory pages of the app, which is a bit harder - especially if you keep the credentials in memory in a scrambled format so a simple scan on process memory for “secret_prefix_” doesn’t find them.
      • Spivak 2y ago
        If an attacker can read other processes' envs you've pretty much lost as they're 1. Inside your process which means they can see the decrypted values. 2. Root which means they can get into your process to see the decrypted values. I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a file with the decrypted secrets and just leaving it there. All the security is already kernel security. I'm honestly not sure who dotenvx is aimed at. - No one security conscious is going to be cool just making the cyphertext available publicly or even internally. - Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key." - And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.
        • aforwardslash 2y ago
          In adittion, if I'm not mistaken, child processes inherit the parent env vars, so if your application forks or use subcommands, you may be exposing the whole environment trove to 3rd party scripts, no root needed. Also, most vulnerabilities that enables execution of code will happily leak the env vars, no root access or "being inside the process" thingy (I know, code execution is technically "inside the process", but without requiring privileged levels)
        • jitl 2y ago
          I’m advocating people use something like SecretsManager, not this thing. In-memory only > env vars > secret files on disk. I find env vars very precarious because harmless developer debug logging, actions like sshing into a container and typing `env` etc can easily expose them. File on disk can be read by an attacker with via subdirectory path traversal bug It’s much less likely for in process only secrets to be exposed by common mistakes/bugs
  • bbor 2y ago
    Yeah but it seems like the right step — deployment, not implementation. All my secrets are managed by GitLab AFAIR, but in general I feel way better integrating secrets into each service/container (I happen to use Dokku, so it’s as simple as something like `dokku add_secret APPNAME SECRET`) than having a central system. I am far too clumsy to trust myself to push secrets in encrypted form, personally
  • bluelightning2k 2y ago
    I've always wondered this. Seems like a password to get more passwords is potentially actually less secure (as in practice people will reuse master keys and they might actually increase the surface area, or make it a persistent threat after the keys themselves rotate)
    • jitl 2y ago
      In AWS and other clouds, you application can use an infrastructure provider API to create a secure session to access infrastructure APIs with per-application-instance credentials that are automatically rotated and can be used only by that instance. These APIs are how the cloud provider themselves provides environment variable injection features, but if your application consumes these APIs directly you can avoid having decrypted secrets hanging out in environment variables as a middleman between your app and the cloud runtime. Typically the application instance sessions are automatically rotated very frequently, AWS’s sessions are limited to 6 hours for example.
      • vinnymac 2y ago
        Dotenvx has a cloud hub from which the keys can be pulled. I imagine an eventual feature will be for the keys to expire, and you’ll have to re-authenticate with the cloud to get new credentials, just as you would with AWS.
  • smallerfish 2y ago
    Doppler is very nice, although it gets expensive at the middle tier, which is needed to separate by role.