Stop Using .env Files Now!

Personally I don’t want my secrets being stored in a glorified text file.

So you store them at an external company? What if they are down, or have a data breach? (They are a bigger target than most of the websites). I'd like control over my secrets and not be dependent on third parties for such important stuff, and storing them in a .env is perfectly fine with the precautions and correct configuration mentioned by @ravavyr

Also, those services are not free. True, you can self-host HashiCorp Vault, but that costs also money.

But, how do you access your config server? At some point, there are credentials being held somewhere? If someone has access to your server where the code is deployed (which they must do if they can access your .env files) then they can also do what they will with your code to access whatever you have held in a config server.

Interesting, your screenshots are specifically from the Google offering, and you didn't disclose in this blog post that that is where you work.

Exactly, like, learn the BASICS of how to use them and you won't do that.
You should have a default gitignore that omits any "dot" files [chances are you don't want any of those to ever commit to your repo]

So yea, newbies make that mistake. Besides, so what?
You add it to gitignore , change all your passwords, and you're fine again.

Do use .env files to define environment variables in local dev (which is what it is for). Don't commit .env files to your repo. github.com/motdotla/dotenv#should-... .env was never ever meant to define environment variables in production/hosted environments, its for local env ONLY.

You make a great point because in AWS permissions can't be wrong. 0600 is really hard to get right, but IAM policy docs are super straightforward.

care to elaborate or you just know one solution and that must be the best safest way to do things all the time?

neat story:
portswigger.net/daily-swig/uber-ha...

and yea an admin screwed up, that's the point, people screw up, but that doesn't mean using environment files with secrets in them is the actual problem. Using them improperly is.

if you're gonna say someone did, point them out pls.

At the end of the day, your dotenv-vault is functioning like a config server.

At that point it doesn't matter who's spot, this is a win for me in my books and my principles are still in play!!

Good job, can't wait to try it out and see people using my principles whether they know it or not 😈.

every single security measure has its weaknesses, going by the original post here, using .ENV files is a thousand times simpler than what he proposes and maybe slightly less secure, but a thousand times easier to repair in case of an attack than the original post's process. That's all i was getting at and this thing blew up lol

Then why do the people who made dotenv explicitly tell you to NOT commit .env to version control? github.com/motdotla/dotenv#should-...

Depending on which service you use, you could slide by without an SDK.

I've never heard of a .env used for build validation, can you give an example.

Oh my, oh my. I'm feeling a sense of irony from some of my criticizers.

From what I understand , he's more like talking about a file-based config management solution, with git-based version control, meaning a dedicated private git service to manage the config file versions not exposed to outside access, that is quite different from "commit it in your repo" which means more about committing it in your application code repo.

Also you can easily have a system that automatically merge multiple config files into one .env file, which should not be directly accessible to anyone, so people updating the individual config files won't have access to configs in other files.

Like I said, you can have a file-based solution that achieves more or less the same goals as a database-based solution, which may be easier or harder to implement depending on your specific situation and needs. After all, databases are file-based solutions themselves, they too store data in files (well, some store non-persistent data in memory, but you get the idea :P )

I have read the article. I am very certain I understand what you propose. It does not work for the environments I work with and I know I am not alone. For the regular self hosted app running on a virtual private server, I would argue you also won't have a need for config servers.

I build industrial applications in demilitarized zones - low trust environments. The customer decides when to go online. We can't expect that an internet connection is there all the time unlike in a cloud application. Not when setting up the software, not when starting the software and also not when updating the software.

This is not a hobby project and it really misses a lot of tooling that yet has to be invented. Because neither docker, k8s or any tooling helps you in continuously rolling out your applications and updates to non-cloud environments. You need to have a very narrow Google-esque vision to assume every app is deployed, managed and run by some cloud.
The problem is a whole lot bigger than ".env files are not secure and don't version". There is a huge gap between the tooling and infrastructure a cloud provides, and the mostly self-baked solutions you have to apply for every tier below that. Docker and docker-compose does work for deploying, but there is an entire slew of tooling that we lack to properly update and version applications that don't run in the cloud.

You mostly have 3 ways of running your apps:

In the Cloud you probably have your complete kubernetes cluster and the entire infrastructure needed to run, monitor, update, version control and deploy your app and its dependencies. There you probably don't have a need for .env files. Even static site cloud hosts like netlify allow you to tune the env from a web ui.

On a virtual private server you have to come up with your own infrastructure. You can't expect everyone to run k8s for a business application. Even then, having too many moving parts can kill your software, as I outlined in my previous post. If I can avoid having a separate runtime dependency, I will avoid it.
All other external systems - A git repository, a CI server, a public key infrastructure, a letsencrypt ssl service, a monitoring service are all optional by design. You can still deploy an app if your CI server gets down. You can still build and package the software locally if your git repo is down. You just don't get monitoring data if sentry is down - the app will continue to run. A certificate will be stored locally and make your app at least secure for ~3 months. But your app won't even start, if your config server is not reachable or has other problems. Even for VPS I would use an .env file.

On bare metal - hardware demilitarized zones and low trust environments are very valid use cases for IoT or public service applications - Both industrial and homebrewn (e.g. smart home). You can't expect that the customer connects to the internet only to get some env vars when starting, installing or updating their app. And I also wouldn't recommend a nuclear power plant to connect to the internet - no matter how secure your communication is. Even for modern industries, sensor data is sacred and they want to very tightly control when software is allowed to synchronize its data with some cloud application. Your across-the-board suggestions "stop using .env files" stops to work here completely.

For Development For development and for documentation, .env files are still great. Setting environment variables for development on windows is a nightmare. In Linux you can at least do DB_PORT=3306 DB_HOST=whatever.com npm run start. But it still convoluted for development. Try to convey what environment variables are needed for your app in order to run to your coworkers. An .env file will document and communicate just that - a set of env vars required for your app to run. Configurable in one place.

We are very far away from having best practices or tools for running software on non-cloud environments.
Docker and compose make it easier, by having predictable deployments. But everything between is left as an exercise to the developer/devops guy deploying the application.

Before I start to figure out how to get rid of a well working tool like .env, I'd rather find out how to fill in the gap of all the missing tooling. Nx is a good job in providing better building tools, combining a slew of independent tools to make build less painful. GitLab is collapsing more and more tools into one tool - since we have experienced in the past years that running and combining a separate repository, a separate CI and a separate container registry is painful. I'd bet my money on these guys.

They read it, you're just ignoring anyone who disagrees with your opinion and assuming they're wrong, rather than listening

Using secrets in CI/CD adds an additional level of protection for secret values through additional access controls but it isn't the only security needed. Assume you have a public repo but want to keep the secrets safe from people who have access to the source code, or you are a company with contractors who need to access the source code but should not have access to secrets.

If someone is able to access the server then other security should be considered such as using a VPC for private API's. Security should have lots of layers, protecting secrets by moving them outside the source code is just one layer.

As I mentioned, it's essential to encrypt your secrets rather than storing them as plain text. This way, even if someone can read your env variables, they won't be able to use it because it is a useless scrambled string of characters. Additionally, you can set the file permissions so that only the owner can read it, further protecting your secrets. Take the following Unix command as an example:

chmod 400 .env

This will ensure that only the file owner can read it and that no one else can access it. This is a great way to keep your sensitive information safe and secure and ensure that only those who need to see it can do so.

Exactly! This is how I recovered some secrets back in the day. You SSH to the working machine, env MY_SUPER_SECRET_LOL and you are done and done.

Then where do you store the configs and passwords/encryption keys of your config server? Using a config server just means you store your application database passwords (and other things) in another database, then you still need to store THAT database's password somewhere, and eventually you will need to store SOME passwords and/or encryption keys in either plain text or environment variables.

I think your entire post is basically the same as saying "when you have to manage many complex systems, don't store their production configs and passwords in files, store and manage them in another database system", which is quite valid for the ease of config versioning, sharing and access control (albeit the same goal can be achieved with file-based solutions too), however in the end you have to store some configs and passwords outside of a database system anyway.

Also if data security is really important and you want to serve sensitive data like passwords via remote APIs, maybe you should just code some simple bespoke config management solution instead of using those enormous "config server" things. I'd say with several hundred lines of code and a handful of dependencies, you should be able to have most of those particular config versioning, sharing and access control capabilities you need, and you have full control of the code that manages your extremely sensitive data, instead of trusting those config server's thousands of lines of code and hundreds of dependencies that you have no grasp of, where a bug in the code or a vulnerability in some dependency may just compromise your "secret URL" completely.

Yeah, but you can commit something like this and generate the .env file upon build/deploy and set the values.

wj-config is a versatile configuration package that does for JavaScript what Microsoft did for .Net: A hierarchical configuration system composed by multiple configuration data sources. Main use case? Any JavaScript project, basically, that requires configuration that has the concept of environments or similar scenarios, like per-tenant configuration, for instance.

1. In your first point you rumble on that there is no good location for the .env file since you cannot put it in your repo (structure). If you don't see how this corelates to my statement and thus can be resolved with git ignore/exclude idk how to bring it to you...

2. And I said "and tools". With those tools you increase your attack surface by miles. And this is not a hypothetical thread. Just look at all the supply chain attacks and other (zero day) vulnerabilities in dev op tools of the last year alone. And for a tool which stores your very soul (secrets) of the whole operation there is simply no good reason to take that risk. You would need to do a 100% code review on every update of this tools and since it is open source you also need to update and that fast since vulnerabilities are also "openly" known. And again for a task as simple as this (just using .env files properly) you go for this risk for no good reason (besides finding the tool flashy or something).

3. Still you don't seem to even know the concept of pipeline variables (or understand it). In a very basic approach you could have one repo server and multiple build and deploy server which poll the repo. They also hold the secrets. Your devs never get in touch with them and never even know the secrets. The 'updater' (as you call it) of the secrets is the person in charge of that project and he also only has access to the build and deploy server for his products. This is just a very basic example and obviously pipelines in the real world are more complex than that but still very well and very secure doable with just bash and your typical and rock stable unix tools.

4. So you say a team of somewhat 5 to 20 devs (I rarely have seen more on just one product/scope which shares the same dev secrets - note that they only are dev secrets anyways and it wouldn't be mission critical if they get compromised) cannot share one small text file easily and secure enough? We have come far if the current generation needs a 10k+ loc tool with a flashy name for a task like that...

5. Than you seem to have more information on that topic than me. Strange though that all their infrastructure and most tools explicitly do support .env files 🤔 And do they just don't use .env files or config files in general? And on all projects or just some? I guess I would need more sources on that one 😆