This is why I beg everyone to adopt workload identity federation.
Do not use secrets in environment variables
71–80 of 96 posts
Re: Do not use secrets in environment variables
#72ENV variables having the names with PASSWORD or SECRET should be ignored by logging and monitoring systems. Most of the web has been built on trust of following conventions.
common secrets used on server side - `JWT_SECRET`, `DATABASE_PASSWORD`, `PGPASSWORD`, `AWS_SECRET_TOKEN` etc.,
Being a long time developer, this breaks the standard of backend apps which mostly uses 12 Factor App[1]. This approach introduces a new dependency for fetching secrets. I see all new open-source projects using "paid" or "hosted" solutions. It is no longer easy/simple to host a full open-source app without external dependencies. (I understand -- things are getting complicated with s3 for storage etc.,).
Re: Do not use secrets in environment variables
#73This 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…
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.
Re: Do not use secrets in environment variables
#74I actually liked this article. A great explainer in why environment variables are a terrible idea. Nike actually open-sourced their Keystore solution if anyone is curious. It was called cerberus.
TIL Nike (the shoe company) has a surprisingly intense OSS presence. https://github.com/orgs/Nike-Inc/repositories
Oh you work in tech and never heard of the strong influence of the FAANG (Fila, Adidas, ASICS, Nike, Gucci)?
Re: Do not use secrets in environment variables
#75Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with N…
> Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets.
Not much use to an attacker if the token / approle is restricted to a specific IP / EC2 instance id.
Auditable too
Re: Do not use secrets in environment variables
#76In my experience, juniors don't know how to do a secure setup, and busy seniors are often willing to cut corners to complete business-critical tasks. Application secrets management needs a better default setup. The standard for application auth should be more similar to an IAM system.
The dev community needs to find a better default than .env files for secrets. While there are plenty of alternatives, they generally all require knowledge of some third party system, which most people, for many reasons do not have the time or interest to learn, and some 3rd party secret to unlock the rest.
We need better default abstractions around secrets management. The authentication step to fetch secrets should be pushed to something ephemeral, probably biometrics. Ideally, devs should almost never interact with secrets in any way. They should use secure and convenient MFA methods to authN/Z their access to services, and secrets management happens out of sight. And this should all happen automatically with default tooling.
It is fairly easy to authenticate between services without secrets in the context of a single platform like AWS using IAM policies and roles, but I think we need to solve the more general case for secrets management abstraction across platforms and services. OSs, browsers, and dev tooling are becoming more mature with respect to auth methods. Secrets management should be mostly the domain of a select group of people, like any number of other complex computer systems details.
Re: Do not use secrets in environment variables
#77Earlier quoted context omitted.
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.
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 fi…
> 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.
Re: Do not use secrets in environment variables
#78Earlier quoted context omitted.
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 t…
> 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 wh…
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.
Re: Do not use secrets in environment variables
#79I made a direnv extension for that purposes.
It loads env files and call hashicorp vault if the value is a secret.
I find it pretty neat to have an env file that describes all environments variables.
Re: Do not use secrets in environment variables
#80Don't use secrets in environment variables, but use this secret in environment variables, but this one gives you access to all secrets. Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with N…
> Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system. Indeed. But ideally the "somehow" that you pass that in is not an environment variable. Maybe somethin…
Sure there are more secure ways if you own the code base. But listen you have a mix of those in any system.
Consul template can render a config in memory. That is safer. But my gripe is the phrase. The phrase leads to worse situations.