6 ms·

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: p

by dolni 2y ago

This article has about as much insight as I would expect from a "nodejs-security.com" article. This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables. The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as a container entrypoint) and adds a bunch of complexity for something that is actually just worse. In local dev scenarios, app-parsed .env files suck because you often end up with some kind of dev-specific secret that you don't want committed to the app repo. In my experience this means developers figure out how to pass a .env file around. If you use an actual shell instead, the local-dev .env can shell out to something like the AWS CLI to get secrets from parameter store. Or you could grab them from Hashicorp Vault if you run that. And because a shell fetches it at run time, secret updates are seamless and properly access-controlled in one spot. In proper deployment scenarios, .env sucks because your deployment system (container orchestrator, Lambda, etc) will need to set those values appropriately for their current environment anyway. And by having a .env file the app loads, now you have two places for configuration. Applications simply should not have any involvement in setting values for their own environment variables. They are typically used for core infrastructure-level configuration. The source of truth for this is probably going to be available via something like Terraform. So the application should ultimately inherit they configuration through Terraform. Additionally, this article is simply wrong on environment variables being readable by any user on a Linux system. On Linux, a process's environment can be read by the superuser and the user who owns the process. That's it.

mhitza 2y ago
You're going from something simple straight to Terraform and secret storage systems like Vault (KMS and similar). While I'm not the biggest fan of where we are right now, it's better than the complexity of integrating with a secret engines. What I really think is ideal is to dump individual secrets into files and only load the decryption key into memory. That way at runtime secrets can be read and decrypted without polluting ENV and avoiding them from lingering around. Another integration, that would be great if it existed, would be if more web frameworks (the perspective I'm seeing this problem from) would integrate with the Linux memfd_secret api. Which would work great with implementations such as php-fcgi, but no so much with greeanthreaded systems.
- stackskipton 2y ago
  Alot of programming languages don't integrate with memfd_secret because while most stuff runs on Linux, very few people actually develop in Linux and thus the friction.
  - mhitza 2y ago
    Most people deploy on Linux. I think developers are doing themselves a disservice by chosing Windows/MacOS for developer machines, and maybe with the recent sentiment of "servers are better than the cloud" we might be heading to a direction where such integration is more likely. Or at least I'm hopeful of that. Heck, even developing directly inside VMs would be better in terms of absorbing production knowledge and finding more useful features one can use for their apps, than just slapping everything into a docker container.
    - giantrobot 2y ago
      > I think developers are doing themselves a disservice by chosing Windows/MacOS for developer machines When Linux runs as well on a laptop as my MacBook, I mean everything from touchpad gestures to power management, I'll switch over as my primary development environment. In the meantime I have to get work done that does not involve messing around to make sure my laptop works properly and/or fighting with a terrible touchpad. I have been using Linux for decades, its happily plugging away on several machines in my house right this second, however I have never been able to have it run as well on a laptop as macOS does on a PowerBook/MacBook. I do my development work on a laptop and unfortunately Linux is at best an 80% solution there. So I'm not doing myself a disservice not using Linux as my main development environment. I'm running a POSIX system and am interested in POSIX-compatible solutions to things like secrets management.
causal 2y ago
Also annoyed that the title has > and here's how to do it better And then basically just says go use a vendor solution. Cool.
- sshine 2y ago
  Yeah, equally disappointed. I know vendors secret stores are better. But what do I do that isn’t vendor-locked and is remotely as simple as environment variables?
  - ocodo 2y ago
    passwordstore.org ... use pass.
hinkley 2y ago
The dev secrets tend not to be as useful from the internet as they are from the intranet. They also often don’t work in prod, only in dev. Worst case scenario if you have to frog-march an employee out of the building, you revoke the dev credentials and distribute new ones. Dev team is locked out of dev for an hour tops. We were just moving into AWS secrets when I left. The API was simple enough, other than the fact that now everyone had to use aws login instead of just the few of us working in terraform, and the terribly chosen session timeout, which I don’t know if our people chose or AWS chooses. But the management of the namespaces/roles for secret visibility looked Stone Age to me. I did not envy the OPs team the problems they were volunteering to deal with. It feels like the same brand of tedious bookkeeping that led to the Arc security hole.
- dolni 2y ago
  > The dev secrets tend not to be as useful from the internet as they are from the intranet. For many companies this is a myth. Once you reach a critical mass of complexity and scale, you figure out that simple database seed files you can bundle into an app repo are not sufficient to test your application. So what solution do people look to? Taking data from prod and feeding it into lower environments. Depending on what regulation you are subject to, some amount of data scrubbing may be required. But even if it isn't, leaking users' data is a bad look. Is data scrubbing easy to do perfectly? The answer is 100% unequivocally no. You mentioned intranet too, and the thing about that is making dev services available externally is a common enough problem that Ngrok is financially viable. TL;DR: the assertion that dev secrets are low value is often not true.
  - hinkley 2y ago
    Not sure why you’re going to expose your dev cluster to the greater world but that would be a time to re-evaluate your security posture.
Jakob 2y ago
As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without saving them in plaintext.
- mbrumlow 2y ago
  You can also do some nice things with https://github.com/getsops/sops https://github.com/getsops/sops, I store encrypted password and secrets on git with sops, but I also use nix so I have near perfect integration with my services.
  - mynameisvlad 2y ago
    I use `age` and `agebox` (https://github.com/slok/agebox https://github.com/slok/agebox) but same idea. I set up pre-commit and post-pull hooks to encrypt and decrypt all the env files I use in docker compose.
- thomascountz 2y ago
  For Mac, I use `security set-generic-password` and `security find-generic-password` to manage secrets using Keychain. Inspiration here: https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbee4404fd https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbe... Then you can use it like this: export OPENAI_API_KEY=$(keychain-environment-variable OPENAI_API_KEY)
  - ocodo 2y ago
    as a cross platform alternative, I use pass (https://www.passwordstore.org https://www.passwordstore.org) export OPEN_API_KEY=$(pass show open_api_key)
- chasil 2y ago
  Another exposure path is /proc. Everybody forgets about this. $ export DB_PASSWORD=foo $ sh sh-5.1$ cat /proc/self/environ SHELL=/bin/mksh DB_PASSWORD=foo
outworlder 2y ago
I had to do a double take and confirm the article's date. It talks about, say, restarting servers(implying downtime) and going to each one of them and updating one by one. If in 2024 you are still treating servers as pets, you are still subject to outages if a single machine dies, and you are still manually configuring them, you are doing everything wrong. And that's before we consider that most of the advice would not apply or have to be done very differently if the app was running in, say, Kubernetes.
- deleted 2y ago
  [deleted]
cbsmith 2y ago
Yeah, there was a ton of wrong here. You captured much of the highlights. I now understand why some developers tell me they think using environment variables for secrets is a bad idea.

by dolni 2y ago

mhitza 2y ago

You're going from something simple straight to Terraform and secret storage systems like Vault (KMS and similar). While I'm not the biggest fan of where we are right now, it's better than the complexity of integrating with a secret engines. What I really think is ideal is to dump individual secrets into files and only load the decryption key into memory. That way at runtime secrets can be read and decrypted without polluting ENV and avoiding them from lingering around. Another integration, that would be great if it existed, would be if more web frameworks (the perspective I'm seeing this problem from) would integrate with the Linux memfd_secret api. Which would work great with implementations such as php-fcgi, but no so much with greeanthreaded systems.

stackskipton 2y ago
Alot of programming languages don't integrate with memfd_secret because while most stuff runs on Linux, very few people actually develop in Linux and thus the friction.
- mhitza 2y ago
  Most people deploy on Linux. I think developers are doing themselves a disservice by chosing Windows/MacOS for developer machines, and maybe with the recent sentiment of "servers are better than the cloud" we might be heading to a direction where such integration is more likely. Or at least I'm hopeful of that. Heck, even developing directly inside VMs would be better in terms of absorbing production knowledge and finding more useful features one can use for their apps, than just slapping everything into a docker container.
  - giantrobot 2y ago
    > I think developers are doing themselves a disservice by chosing Windows/MacOS for developer machines When Linux runs as well on a laptop as my MacBook, I mean everything from touchpad gestures to power management, I'll switch over as my primary development environment. In the meantime I have to get work done that does not involve messing around to make sure my laptop works properly and/or fighting with a terrible touchpad. I have been using Linux for decades, its happily plugging away on several machines in my house right this second, however I have never been able to have it run as well on a laptop as macOS does on a PowerBook/MacBook. I do my development work on a laptop and unfortunately Linux is at best an 80% solution there. So I'm not doing myself a disservice not using Linux as my main development environment. I'm running a POSIX system and am interested in POSIX-compatible solutions to things like secrets management.

causal 2y ago

Also annoyed that the title has > and here's how to do it better And then basically just says go use a vendor solution. Cool.

sshine 2y ago
Yeah, equally disappointed. I know vendors secret stores are better. But what do I do that isn’t vendor-locked and is remotely as simple as environment variables?
- ocodo 2y ago
  passwordstore.org ... use pass.

hinkley 2y ago

The dev secrets tend not to be as useful from the internet as they are from the intranet. They also often don’t work in prod, only in dev. Worst case scenario if you have to frog-march an employee out of the building, you revoke the dev credentials and distribute new ones. Dev team is locked out of dev for an hour tops. We were just moving into AWS secrets when I left. The API was simple enough, other than the fact that now everyone had to use aws login instead of just the few of us working in terraform, and the terribly chosen session timeout, which I don’t know if our people chose or AWS chooses. But the management of the namespaces/roles for secret visibility looked Stone Age to me. I did not envy the OPs team the problems they were volunteering to deal with. It feels like the same brand of tedious bookkeeping that led to the Arc security hole.

dolni 2y ago
> The dev secrets tend not to be as useful from the internet as they are from the intranet. For many companies this is a myth. Once you reach a critical mass of complexity and scale, you figure out that simple database seed files you can bundle into an app repo are not sufficient to test your application. So what solution do people look to? Taking data from prod and feeding it into lower environments. Depending on what regulation you are subject to, some amount of data scrubbing may be required. But even if it isn't, leaking users' data is a bad look. Is data scrubbing easy to do perfectly? The answer is 100% unequivocally no. You mentioned intranet too, and the thing about that is making dev services available externally is a common enough problem that Ngrok is financially viable. TL;DR: the assertion that dev secrets are low value is often not true.
- hinkley 2y ago
  Not sure why you’re going to expose your dev cluster to the greater world but that would be a time to re-evaluate your security posture.

Jakob 2y ago

As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without saving them in plaintext.

mbrumlow 2y ago
You can also do some nice things with https://github.com/getsops/sops https://github.com/getsops/sops, I store encrypted password and secrets on git with sops, but I also use nix so I have near perfect integration with my services.
- mynameisvlad 2y ago
  I use `age` and `agebox` (https://github.com/slok/agebox https://github.com/slok/agebox) but same idea. I set up pre-commit and post-pull hooks to encrypt and decrypt all the env files I use in docker compose.
thomascountz 2y ago
For Mac, I use `security set-generic-password` and `security find-generic-password` to manage secrets using Keychain. Inspiration here: https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbee4404fd https://gist.github.com/bmhatfield/f613c10e360b4f27033761bbe... Then you can use it like this: export OPENAI_API_KEY=$(keychain-environment-variable OPENAI_API_KEY)
- ocodo 2y ago
  as a cross platform alternative, I use pass (https://www.passwordstore.org https://www.passwordstore.org) export OPEN_API_KEY=$(pass show open_api_key)
chasil 2y ago
Another exposure path is /proc. Everybody forgets about this. $ export DB_PASSWORD=foo $ sh sh-5.1$ cat /proc/self/environ SHELL=/bin/mksh DB_PASSWORD=foo

outworlder 2y ago

I had to do a double take and confirm the article's date. It talks about, say, restarting servers(implying downtime) and going to each one of them and updating one by one. If in 2024 you are still treating servers as pets, you are still subject to outages if a single machine dies, and you are still manually configuring them, you are doing everything wrong. And that's before we consider that most of the advice would not apply or have to be done very differently if the app was running in, say, Kubernetes.

deleted 2y ago
[deleted]

cbsmith 2y ago

Yeah, there was a ton of wrong here. You captured much of the highlights. I now understand why some developers tell me they think using environment variables for secrets is a bad idea.