Table Of Contents
Hello Reader
The problem with .env files
Storing the .env file
Updating a secret config
Versioning
...
For further actions, you may consider blocking this person and/or reporting abuse
I get it...you're like overly cautious.
After years and years of dealing with hundres of sites/apps/applications I can tell you one thing.
NO ONE gets hacked via their .env file. Ever.
First of all, it's really easy to lock it down so no one can access it except for the devs who need access. At some point there's at least one human being [preferably 2 in case one gets hit by a bus] who should know where and how to access and change all your passwords. Therefore having them in one place is just as safe as having them in 20 different places where you will absolutely 100% guaranteed forget some the next time you need to update things or something is on fire.
Overly cautious security leads to a mountain of steps to get to sensitive info that just hurts development and recovery times more than it helps to actually protect anything.
In other words...it's a pain in the buttocks. Don't do it.
Use .env files and learn the few steps it takes to protect them. There is NOTHING wrong with that.
Sounds like more work in my opinion. With a config server, there is no need to trust the "2 devs" since the server has permissions and access restrictions so only permitted devs can add secrets without viewing existing ones.
I don’t think it’s overly cautious, it’s being modern. There is no mountain of steps. Whitelist your application and use the config url like the examples in the article, easy and no pain in the buttocks.
Please re-read the article, I explained how easy recovery (roll backs) and development time is simplified using a config server. I COULD use a .env file and take steps to secure it, or I could live in 2022 and use a config server with permissions, auth, versioning, real-time updates, and an audit trail for extra security.
Personally I don’t want my secrets being stored in a glorified text file.
Thanks for the comment!
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
.envis perfectly fine with the precautions and correct configuration mentioned by @ravavyrAlso, those services are not free. True, you can self-host HashiCorp Vault, but that costs also money.
True, nothing is full proof. But that's why we choose techniques or companies that gives us the best guarantees.
Also no matter how secure you keep that
.envfile, you are giving someone FULL view of all secrets whenever its updated.The services I listed have free tiers. HashiCorp can be self hosted for free forever, Google Cloud has a free tier for 6 secrets, AWS has a generous free tier for storing configs in parameter store.
If you don't want to go with an external company and want full control over your secrets, thats fine. There are free, open-source, or self-hosted alternatives. There's Spring Cloud Config, Github Secrets (if you trust the company enough), or roll your own.
I think the point that @tristan is making rather well is that your recommendation is just increase the surface area of your vulnerable systems.
The mindset that doesn't even trust employees with private information would deem providing that information to a third party (especially a faceless tech company) to be less secure than, keeping it contained within a closed system that is completely under their control.
The arguments you're offering for using a third party to host private information are actually the arguments against using such services. They are the weak points: If a system is compromised, it's almost certainly due to leaky abstractions like this...
It's an increase in surface area, but with the benefits I listed above.
Its not distrusting employees, it's being safe and following a secure practice. I don't know about faceless companies, I mentioned Google, AWS (which is the leading in the market for cloud) and other credible companies which provide a config service. I may be a little bias since I am a Google employee.
And if thats the case, why trust anything? Why host private code on Github or deploy on Digital Ocean? Its for the ease and guarantee.
I also mentioned open source config servers that you can host or deploy yourself.
If a system is compromised, most likely its from using bad practices...
DigitalOcean with firewall configurations is the problem solver. Only SSH works on my IP and only Cloudflare can access the HTTP directly. My name literally says "trust me".
What happens if your service expands and you have to share common secrets across different teams?
Do you just copy and past the file or use a centralized config?
I could very well say let's use Github/DigitalOcean for secrets and containers, but I work by myself and I have one project that runs about 20 servers (API's, webhooks, crons, etc.) with each having different slightly different .env's. I code in Rust instead of PHP or JS in the backend, so I'm more concerned with supervisor's configuration more than the actual env.
@tristan If you're having serious infrastructure you're already relying on external providers (whether it's AWS, GCP or Azure) so using different service for secrets doesn't make much difference.
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
.envfiles) 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.
People absolutely get their secrets stolen through .env files if they commit them to their repository.
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.
Or you can use a config server and never have to worry about that "newbie" making that mistake with a modern solution.
@ravavyr, you're fine until another newbie comes into the team and needs to edit .env but makes a backup of it to avoid making a mistake, since it's not in GitHub. Later, when doing a
git add .the person forgets that the backup isn't in .gitignore -- he/she may not even know what a .gitignore is -- and accidentally commits the secrets.This scenario might sound a bit far fetched, but I have seen things like this happen many times. Also, some people will hide the mistake instead of going and changing all the passwords... it's easier to just pretend it didn't happen, that reverting the commit will fix the problem, and that no hackers will ever look at git history. :)
I will say that config servers were initially very intimidating, but once I got used to it, I personally can't imagine going back.
From a security standpoint, it's not perfect though. A tool is still only as good as the people using the tool. We still struggle with how to avoid getting the secrets into the config server. IT has the access, but the devs all have the know-how regarding what the secret is for. Sometimes this means devs create the secret and then share it in the chat system (a bad practice) so that the IT person can then add it in the config server... I guess things can still not make sense even with a config server.
I was strictly referring to your somewhat bold statement:
If your secrets became public then the env is already irrelevant.
No one gets your secrets from your env unless they've already gotten into your server.
Even the most basic servers have [dot] files blocked from access (or should, i'll admit some don't do it by default)
And yes, if your env got into your repo, changes the passwords and keys and make sure you add it to gitignore so it doesn't happen again.
Either way, the .env file has never been the problem.
If .env is in your repo, it public knowledge. Even if its a private gitlab, nobody keeps track of what secret is where and secrets in repos should therefor always be considered public knowledge.
There's plenty wrong with using
.envfiles, especially in production. Permissions could be wrong, it could expose passwords to folks who are authorized to support the application but are not authorized to access the database, it could be slurped, version-controlled, etc.Just because it is easy to maintain security of a single file in a single filesystem doesn't mean that the
.envfiles sitting on your laptops and production servers (if you're using containerization and clusters than it's one copy per machine).Add on to that the fact that if you use
.envfiles then you have to go manually change the files whenever you rotate or change tokens/keys/passwords, which frequently leads to people not changing those aforementioned credentials.Use a security service which encrypts, like a Secret Manager (GCP, Azure, and AWS have these), you could use Hashicorp Vault, there are a bunch of choices.
Don't use
.envfiles, the odds that your program will suffer a security event or will perpetuate bad security hygiene is substantially higher than if you use a vault or managed service for your secrets.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.
The passive aggression isn’t helpful. It is possible for us to have a respectful conversation while disagreeing.
IAM is an auditable, traceable mechanism which can be monitored and alerted on. I can see who makes an api call to fetch credentials in CloudTrail. I can see if my policy statements are too permissive with things like AWS Config, Trusted Advisor, or Access Analyzer. I can set and forget those roles, and make access to credentials something that adheres to least privilege.
I’d much rather risk a detectible fault IAM policy documents and roles than try to manage
.envfiles across a bunch of infrastructure, and constantly monitor engineers who will accidentally commit and push credentials to source control.If we were still in the days of monoliths on bare metal servers running in data centers, I wouldn’t be disagreeing as I am. But we’re not, at least not all of us are. The threat is much bigger than you seem to be giving it credit for. Using
.envfiles for production workloads in contemporary containerized cloud deployments is clearly a security anti-pattern.Lol I was just messing around. You're right though. There's definitely not a way to audit syscalls about file and attribute operations and send those to a SIEM and alert on them. And even if that existed it's not like it's best practice to monitor those things anyway. So yeah I'm in your camp on this one.
Lol mate...
You're so dead wrong on every point.
This is why nconf with it's ssm layer exists.
care to elaborate or you just know one solution and that must be the best safest way to do things all the time?
use what ever solution you like as long as :
So yeah, that pretty much eliminates your one trick pony.
you don't even need nconf, i could come up with something in several languages that do this:
Didn’t Uber just got hack recently because they put their secret in their script?
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.
Please can you teach me the the proper way to use . env file?
no one you know or no one ever ?
if you're gonna say someone did, point them out pls.
I won't point them out cause I'm not here to expose anybody, but I've seen it personnally, on multiple occasions.
Good for you if you got some likes but your comment makes no sense to me. Besides, why fuzzing/hacking tools would include
.envin their list if it's that irrelevant.Look, i can't help you see the reason this entire argument is pointless.
Suffice it to say that all security measures are flawed because they are implemented by human beings and have to be maintained by human beings.
What does hurt projects often [that i've experienced with at least half a dozen clients] is being overly paranoid and trying to secure everything to the point where basic assets are not accessible and sites go down when they shouldn't. At that point it's hurting more than it's helping. And having a .ENV file in 16 years has not once been the problem. So per my experience, it's not an issue. You claim otherwise, and as everything in this industry, we can leave it to personal preference.
I see you're really concerned, but you don't demonstrate anything. Why do you consider not using .env is being "overly paranoid"?
If you care about error 500 and other inconveniences, it happens a lot with .env, and many beginners have difficulties using them properly. Most of the time, teams use it because the framework forces them to use it, not as an internal methodology.
I don't know you, but it sounds like "I don't want to change my habits, I've been doing that for 16 years." If you're careful, which I assume you do, you might be ok with that approach, but that does not mean it's the best one.
Config files like that are primary targets that will be automatically scanned, and sadly, people tend to use the same credentials and API keys in all environments, sometimes making the attack even easier.
lol
500 errors only happen if you wrote bad code or didn't debug it enough. This is fact. I fully expect 500 errors if i forget to setup the correct configs in the .env file. You're supposed to fix those across your application and account for any combination of them and make sure to log them and keep an eye on those logs for new ones and then fixing them.
note, my habits extend 16 years, which means i've been coding since before env files existed and i still run some older monolith systems while also keeping up with various frameworks, platforms, services, tools and whatever else people keep coming up with. Config files only get scanned automatically if you don't secure the damn things which again shows that maybe you just lack experience in the field. Credential sharing happens yes, and it's just as bad as not securing your env file from external access, but so is clicking on a bad link in an email, or not setting folder permissions correctly, or a mountain of other issues. ENV files are not the problem, nor were they ever.
Discuss starts with "lol." If you think this is a battle, then win. Sorry to say that again, but you don't demonstrate anything. I've seen many uses of
.envfor convenience I did not find convenient or particularly efficient, but if I have to use them, then I use them.Does not mean it's the best strategy out there. Does not mean you have to migrate all legacy projects right now because someone said you have to. Maybe think about other approaches for your next project.
I think @ravavyr is largely spot on here.
That said, .env files do have their weaknesses. We are addressing those with dotenv-vault - from the same people that pioneered dotenv.
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 😈.
Yes, you are correct.
I think we are toward the same end here. You recognize the problem we see as well.
But throwing out the .env file will be a mistake. They need to work together. The config server should layer on top of .env files.
Currently, all implementations of config servers require you to learn a new proprietary system, rewrite code, and get locked into it. Plus, there is training on the new system for your dev team.
That's why we think all config servers should be built on top of the defacto .env file standard. This way, you get all the security benefits of .env files PLUS solve the insecure sharing and config issues.
That is what we are doing with dotenv-vault.
This has the added benefit that you could choose to leave dotenv-vault, and everything would still work. Or you could switch to a different provider that syncs your .env files for your team.
Sounds good to me no matter the underlying system as long as the benefits listed in my article gets implemented.
But seriously guys good job, it feels good to have the brains behind the bases of my very argument make amends with me. I’m so happy right now!!
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
True, and he also forgot to mention the dependency of SDK, .env isn't bad, if steps are taken to secure it, and infact there's no way people are going to directly update the code or version the .env, they are going use it for local development, and rather build validation in code to check for environment variables and add up new vars progressively, Secret Managers are special purpose services, they add up complexity for small systems, but solve the problem of scattered and untracked env for large systems, obviously with overhead of using client sdks. Still if you still wish use some secret store for even local dev, use Doppler.
Then why do the people who made dotenv explicitly tell you to NOT commit .env to version control? github.com/motdotla/dotenv#should-...
People never stop to disappoint me with their clinging to bad practices.
not commiting it to version control is the right thing to do, but using it as source of truth for your variables is simplest thing to do, if one needs unified way of injecting secrets, from various sources there are tool out there like tlr.dev/ which can source secrets from AWS, Vault, etc. all in one place without even using any SDK. That totally depends on choice of the devs.
Depending on which service you use, you could slide by without an SDK.
I've never heard of a
.envused for build validation, can you give an example.That's kind of an overstatement. A quick regex search on Github reveals tons of projects still include their .env in the repo, and of course with their secrets in it
Exactly
Honestly... This sounds great compared!!
Read this and join me in knowing that people definitely do get their secrets exposed through .env files...
dev.to/mittal69353530/adding-an-en...
Oh my, oh my. I'm feeling a sense of irony from some of my criticizers.
It is myth busting time.
1.
.envfiles are unreliableHaving the environment settings come via network adds a whole lot of overhead.
A lot of bad things can happen.
You can by all means make a web service reliable. But how is an external web service more reliable than a file I have access to locally?
Sure, you can write bad code that allows attackers toaccess arbitrary files. But you might as well leak your environment variables even when you would retrieve them through a central environment provider. Object property injection is a thing. Essentially allowing you to instruct your server to serialize and send you the
envvia any API.There is absolutely nothing from preventing you to write bad code. No matter if env is directly injected to the app or read from an
.envfile.2.
.envfiles have no access managementYou can. Both locally and remotely.
How do you run your apps? If I run my docker containers, I can have my compose file read from an
.envfile and provide that to the containers. The app doesn't even need to know an.envfile exists. But the only user starting apps would have access to the.envfile. You can control very well on any system who is going to be the guy that gets to run apps.Secondly, you can also manage access who is allowed to read and write the
.envfile.3.
.envfiles have no versioningCheck your
.envfile into git - no, not the public project. Create a separate repository that you can make private and only give access to limited people.4.
.envfiles have no safe updatesThere is a little bit of lack of tooling here maybe, but you can create a contract between your app and what environment it expects.
In TypeScript and NodeJS you can simply overwrite the nodejs
process.envinterface, providing a clean contract between your app and the environment vars it needs. It would be even better, if you could generate that from a.envfile. Problem solved.When I roll out a new container, I update both my repo containing the new .env file for compose + the app.
Summary
.envfiles are a battle-tested and widely adopted and supported feature. They make deployments predictable and secure. If you have trust issues, then you can sufficiently lock it down and only inject it via docker containers.I absolutely don't see a need for involving yet another server.
I'm not sure you read the article completely.
Yea, nothing is full proof; anything can go down, doesn't mean its not a viable option. When config variables are updated, they keep the same entry point ex.
config/DB_PASSWORD/v1. Only the value is changed, this is how an paper trail is kept.When that .env is updated the updated has full access to all secrets, no matter how secure that file is nothing will change that. My point wasn't that the file couldn't be stored properly.
The creaters of dotenv tell you not to commit it in your repo. Look below, tons of comments say the sme thing.
Summary
Please re-read the article, your points are not aligning with what I was saying. Yea its widely adopted, but change takes time.
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 )
Sounds interesting but still opening one .env exposes all secrets in it. A config server mitigates that risk while giving feature like audit logs and automatic secret rotation.
You also get the benefit of a ui if you care about that.
The point is in such a file-based config management solution no one should be able to directly open the .env file, it should be dynamically generated and managed by the system, more akin to a "flat database file" if you like to think that way. And features like audit logs and automatic secret rotation can be implemented with no more than a couple dozen lines of code, without the need of a config server. Like I said, the main point of your post is actually not about "config servers" (albeit you are advocating their usage), but rather about storing the config data in remote databases vs. local files/environments.
And the existence of a UI can be a pro or con in the case of config administration depending on specific needs. It's also quite trivial to setup a simple database admin UI if you decide to store config data in remote databases anyway.
Honestly at this point you are just implementing a config server yourself. Every feature I mention you are saying just write it. If that's what you want to do by all means. We can agree to meet in the middle at this point.
That means you can just implement a file-based "config server" with .env files, and your "config server" itself would also use .env files for config, and it could have better security, cleaner code, and maybe even easier and faster to implement than trying to deploy and adapt to use one of those enormous "config servers" you mentioned in the post depending on your particular needs.
Which is exactly the point:
1) .env files (or config files in general) based config management solutions are not inherently worse than those based on remote databases. Don't just blindly diss config file based systems in favor of those based on remote databases, they both have their pros and cons, and one may be improved very easily over the other depending on your particular needs.
2) for experienced devops, it's usually quite trivial to implement a bespoke config management system for things like config versioning, sharing and access control, and it could likely be the preferred way over using one of those enormous "config server" with tons of code and myriads of dependencies.
Yea, just like you can implement a no sql database with json files, we have tools built for various use-cases. How do you know config servers are enormous, have you used or checked one out? How is tons of code a useful measurement in this conversation again?
All these features you are saying that are trivial to mention can also grow into these "enormous" config servers you keep mentioning. OOOR you can use an already established and battle-tested implementation to avoid introducing the very bugs you are talking about.
And not to be rude, but how much experience do you have?
I have checked the "config server" you mentioned in the post,, it has hundreds of dependencies and more than 600k lines of code, which is really ENORMOUS considering the fact that only several hundreds of lines of code are needed to realize the features you mentioned most in the post.
log4j was established and battle-tested, struts2 was established and battle-tested, and when there are orders of magnitude of difference in the amount of code involved, then it's a useful measurement. When it comes to managing important sensitive data like passwords in devops, I'd always trust 600 lines of code written by myself with a handful dependencies than 600k lines of code written by other people with 500 dependencies, when they basically serve the same goals for my particular needs.
And nope a simple bespoke config management solution is next to impossible to grow into those enormous config servers, for example if you code a simple server with koa and several self-made middlewares for your particular needs, it will never grow anywhere near the size of Spring or Rails. From what your post suggests, using a "config server" with 600k lines of code and 500 dependencies just to address pain points like version control, config sharing, access control, data encryption and secret rotation kind of stuff, that sounds like you wanting to deploy an entire Spring Cloud infrastructure just to serve a simple website. Or like wanting to use a NoSQL database when a plain JSON file is more than sufficient to store your data.
And like I said, the solutions to those pain points mentioned in your post is really not about config servers vs. dotenv files, but more about centralized remote databases vs. local config files.
I'll just say I have lead teams of devops with 5 to 10 years of experience, using many kinds of configuration management solutions across various projects of various sizes, from simple bespoke solutions based on config files and/or centralized databases, to distributed systems based on things like zookeeper, and tools for k8s, etc. From what I can see, those "config servers" mentioned in your post are simply WAY overkill as replacements for some config files to just address those handful pain points you mentioned in the post.
Again. WHY DO YOU KEEP BRINGING UP LINES OF CODE AS A METRIC OF USEFULNESS??
About half of HashiCorp Vault's code is unit, system, and integration tests.
They thoroughly test the front-end and the back-end. And to take it a step forward they have end-to-end tests and acceptance tests.
Tests written to avoid these "vulnerbilities" that you keep preaching have multiple lines of code create.
Ok then you can write a config server yourself if you are scared of vulernerbilities. While you are at it MySQL has a vulnerbility back in May so you might want to write your own database engine while your at it.
Also, Chrome just recently had a vulnerbility too. Don't forget to build a while web browser as well. Actually, Dev.to has a bug page, yikes you might wanna re-write this website too.
I mentioned in the article that config servers are usually accessed form VPCs so even if one of those "hundreds of dependencies" has a bug, the config server is protected from the internet.
Also I find what your saying kinda funny.
If a project uses tons of dependencies, then the project is bad. Instead, if they write the features by hand which increases the lines of code, that also makes the project bad.
You really need to read what others' saying before replying completely irrelevant things. If I just need to store 1k of data, I'll not use MySQL, I'll just use a JSON file. If I just want to download a file, I'll not use Chrome, I'll just use curl or wget. You must have some serious problems with your eyes IF you can't properly read what others write.
I clearly said those handful of pain points you mentioned in your post does NOT require those enormous "config servers" to address. Those are some simple goals achievable with some very simple config management solutions based on config files, or if you want, with centralized databases, which may take even less time and easier to implement than deploying and adapting to one of those "config servers" mentioned in your post. If you want to call such simple config management solutions "config servers" too, fine. I guess you can call both koa and Spring as "web frameworks", but their differences are huge.
Like I said, using one of those enormous "config servers" to address those pain points mentioned in your post is like deploying an entire Spring Cloud infrastructure to just serve a simple website with features that can be done by using just koa and a handful simple self-made middlewares. Yes you can try deploy a complete Spring Cloud stack to just serve a simple website, but it will take more time, use more resources, and exposed to more potential vulnerabilities UNNECESSARILY, so noone would recommend that.
When you can address all your pain points regarding dotenv files with some simple bespoke solution of several hundreds lines of code, deploying and adapting to an enormous "config server" mentioned in your post to achieve the same goals is really not something to recommend.
Next time try really read and understand what others have said first.
===
You seem to really have some serious problems with your eyes, or your English comprehension skills. What I said is that achieving the same goals with less code is good, and if by orders of magnitude less amount of code, then that's really really good. More dependencies usually means more code in total to achieve your goals.
And about the lines of code as a useful measurement, yes they are when the differences are ORDERS OF MAGNITUDE kind of huge. A simple "Hello World" program practically has zero bug (of course it has next to nil functionality too), 600k lines of code may not differ from 500k lines of code much in terms of complexity and potential bugginess, but if THE SAME GOALS can be achieved by 600 lines of code instead of 600k lines of code, that's some big difference.
I don't think we are going to get anywhere, we are clearly at a disconnect and throwing insults isn't going to solve much. Let's just agree to meet in the middle on this.
no insults, just curious, is English your first language? I kinda understand what you are trying to say with "agree to meet in the middle" here, but that sounds really a little odd here, just saying.
Yes english is my first langauge. What i mean by meet in the middle, I'm saying we both respectfully acknowledge the other person side and agree to disagree.
Yeah I know what it means, just don't see it usually used like this.
I don't want to keep pinging you so I'll make this the last message, but I'm curious, how do you normally see the phrase used?
usually when there's no compromise it's just agree to disagree.
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
.envfile.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.Would love to have @jarrodhroberson opinion on this :)
They read it, you're just ignoring anyone who disagrees with your opinion and assuming they're wrong, rather than listening
Hard to believe that when most of my responses are well typed and counter-points, and most of who disagrees are the ones who assume I'm wrong, haven't read it, and don't listen.
Recently, I've decided to leave this article in the past for now. Take care!
I'm pretty sure you are the one who doesn't read counter-points of others, and doesn't listen to those who make them
.env files should only be used locally in a dev environment. Not sure using them in production is a thing anyone does?
Using something like KeyVault for production makes sense but I prefer to use CI/CD secret services that github / gitlab provide. Makes sense to me that secrets belong to the build / deploy process.
A word of caution with this approach - make 100% sure you're not exposing your secrets in your artifacts!
Can you explain why? If you're configuring secrets in your environment at the build step, they would still be accessible in the deployed system, thus no less vulnerable than if they're in a
.envfile aren't they?I mean, if I have enough privilege to access a private file on a server, then theoretically, I can inspect the server's environment anyway.
I just feel like I'm missing something here...
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.
I think this depends on what kind of secrets. CI/CD secret can be used for CI/CD, eg: secrets to access Docker, K8s cluster, artifact stores ... Application secrets are different layer, so we need extra tool to provide those. All artifacts should be stateless, loading application secrets is likely effect that happens on runtime instead build/deploy time.
I don't think there's any harm in storing secrets in a
.envfile, as long as the file is kept safe and secure. In fact, I believe it's a good practice to follow the Twelve-Factor App's recommendations.In their chapter on Config, they state that config should be in environment variables. This is good advice to follow, as it can help keep your application secure.
Moreover, by taking the necessary precautions, the risks of storing secrets in a
.envfile can be minimized. For instance, be sure to keep your.envfile in a secure location and make sure that only authorized personnel have access to it. Additionally, you should encrypt any sensitive data that you store in your.envfile.By following these guidelines, you can ensure that your secrets are safe and secure while still being able to take advantage of the benefits of using a
.envfile.This doesn't solve that anyone who updates it will have access to all your secrets in plain text. No matter how secure the
.envit doesn't change that.Also, environment variables are global to that machine, if someone gains access then they can read out your variables. This was one of the main techniques when the Log4J was exploited.
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:
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.
What about sharing a secret to other? With a config server it’s as simple as ‘corp.secrets.com/config/DB_PASS/v2’.
In this case, you can create an Inbound firewall rule or add an entry in the ACL to allow only specific users to access this file.
Again giving full access to every secret in the file to that user.
Now, the problem becomes tied to the party that you are sharing it with rather than the
.envfile itself. There is a risk in giving away your secrets to a centralized third party(Like Config servers), as it can become the main target for hacky wacky organizations. It is important to consider who you are sharing this information with and whether or not they can be trusted.The best solution sounds like hosting your own config server so you don't have to consider if the person you're sharing information with can be trusted while utilizing permissions and access restrictions. Win:Win.
Exactly. However, many startups nowadays are content to take the easy way out, opting for quick and easy solutions that don't really offer much in the long-term. They don't understand the risks involved in this approach, and only realize it when it costs them time and money.
Exactly! This is how I recovered some secrets back in the day. You SSH to the working machine,
env MY_SUPER_SECRET_LOLand you are done and done.I think that's probably because your ssh'ed into the server as the owner of the file or have root access. However, one thing you can't do is open a session to the server and get access to its environment variables. Nor can you log into a shell on that server and get them unless you have root access or own the web server process.
Exactly, it's more or less a moot point to talk about security if the root access to the system is already compromised. If someone has root access to the application system, then it's trivial to extract/intercept the passwords, whether you store them in files, environment variables, or get them from "secret URLs"
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.
Sure, build your own solution if you don't want to trust a third-party. If your config url was exposed it wouldn't matter. Most config servers are connected through VPCs which prevent internet access and can only be accessed by your servers.
Well, remote APIs are inherently less secure than local access, and using config server just means you move your sensitive data from local files to a remote database. Of course it can be less prone to human errors and much easier to use, but in the end I doubt either approach (remote database vs. local file) can be said decisively safer, it really depends on the specific situation and implementation.
I do agree if you are managing many complex production systems you should not manage configs with individual files, unless you have some good file-based config management solution in place.
But then in the end the configs and passwords for this remote database/config server thing still needs to be stored in some environment variables and/or .env files (or rc files, or whatever local config files you want to name them) anyway.
When using a VPC you are essentially using local access. Yes you are moving sentive data behind permissions and access retrictions. I do however believe that .env should be used for local / development oriented enviornments like I mentioned in the article.
I guess we can agree to meet in the middle.
You should never commit your .env to version control: github.com/motdotla/dotenv#should-...
Yeah, but you can commit something like this and generate the
.envfile upon build/deploy and set the values.But why? All hosting providers I can think of, provide a way to specify environment variables. Why make it more complicated than it needs to be? Environment variables: it's in the name, they're specific to an environment. It's illogical and a potential security risk to put something thats environment specific into something that is not (your source code/version control).
Despite the grabby article headline that I usually avoid on principle. I vehemently agree that .env was and is a terrible idea from multiple viewpoints, including software delivery and security. The best solution though, is to use passwordless identities to establish trust then nobody, including developers, need to know any secrets and when they leave the organization their access leaves with them. PKI should be considered first, not last.
I don't get it, like I mean
.sshpasswords and keys are also stored as files somewhere on your server. Having a.envfile in your www folder (or whatever you are using) is not inherently insecure. Obviously if you made it publicly available, it would be. I get that GCP or whatever builds this into vaults and that's great if you're using GCP, and perhaps Google builds in extra security, but there is really nothing inherently wrong with using a.envfile.If you're an experienced security consultant working with other experienced security consultants, I'm confident no one will commit that file, but most developers who are not in the security field just don't think that far ahead.
In my experience, someone will eventually commit that file. It won't be you or me, but someone at some point will do it, and it also might not be discovered for months until someone like you or I does an audit and discovers it in the commit history.
With that said, people can still misuse the config servers and secret managers too. At the end of the day, the tools are only as good as the people using them.
Great article.
I worked at a company using docker, we build docker without any user inside, eg you could use the service it provids but it hade no user inside to access.
If we hade to fix any thing, just build a new one.
Anders way of thinking about security in a modern cloud environment works for me, it's the 'cattle-not-pets' approach: deploying immutable closed systems (no user access) that have no need of configuration / comissioning, a nice blog post here: tempatrumah.blogspot.com/2021/07/e...
This strategy allows security controls such as full system integrity monitoring and automated intrusion / modification handing (eg: isolate and freeze the affected system for forensics, deploy another one via the automated scaler / pipeline).
Add a well-thought out separation of concerns strategy (be that managed access to deployment pipeline data that gets baked into the system, in-cloud secrets managers that lean on machine identity for access control, separate production data repo with managed access, whatever works for your scale) and you have addressed most of the risk being discussed here.
The problems arise with production systems that are pets, lots of humans poking about and little to no chance of spotting a problem fast enough to act effectively.
Interesting. I will make some time to investigate these and see if I can integrate support for them into wj-config. Basically create a data source that understands how the server works.
And yes, I agree that
dotenvis not the greatest. If it were, I would not have had to make wj-config in the first place.What is the main use-case for wj-config?
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.
The author seamingly has no idea of git ignore/exclude (decades old), the concept of pipeline variables (which obviously can be files or generate files as well) and the multiple risks which come when you hand over your business secrets to third party companies or tools (regarding technical security as well as business stability).
So I don't say that too often but don't listen to that load of bull crap and DO use .env files and DO use them correctly (which can depend on company size but yes, even as multi million dollar comapny and above this is still the right approach!).
Please re-read if this is your conclusion.
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...
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).
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.
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...
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 😆
I don’t know know where to go either with this point.
Nothing is full proof not this site, not hosting your code on GitHub, or deploying on Digital Ocean, GCP, AWS, etc…
So a person seeing all secrets is ok because he is in charge? That does not sit well with me. At Google you can be the VP of a project and you still don’t have clearance to view a secret.
Change takes time, why use anything? Tools are built to make life easier. We don’t need to copy and paste or trust anyone because we have a tool with permissions to do that for us. And it doesn’t matter how many lines of code it has, why is that a metric that need to be brought up?
AWS Secrets Manager has been incredibly valuable in terms of managing
.envfile configs for our team. No need to worry that you've got the wrong config, just set up a bash command to pull down the latest from AWS.My thoughts on this:
To solve including your .env files inside your docker images use volumes. Mount your .env files during deployment not build. That's how Azure DevOps and Kubernetes does this to protect the secrets.
Exposing your database password inside a file is not a big security issue on its own. The DB server (or any other service protected by credentials you use) should not accept connections from untrusted sources by default so even with leaked username/password the only way to get in is to have application execution access or user access to the shell of your application server - and if the attacker has it, it's too late for anything.
How are password servers protected? Again username/password? Where are those stored? It's the same dillema just shifted away behind another SPoF node.
Can you please elaborate how it actually improves anything?
Secrets aren't fully exposed when someone wants to edit a secret. Thats a big plus for me.
Config servers provide an audit trail for who / when secrets where accessed or updated.
Access control and permissions.
Versioning for roll backs or deployment strategies.
Less likely of a human error, like messing up a key-value pair and causing a parsing error.
And yea, almost every problem is just shifted behind another node, but that doesn't mean we can't improve along the way.
.envfiles just seem kinda primitive at this point.FYI - It doesn't have to stop with simple usernames and passwords; we now have physical keys and biometrics.
All this is solved by CI/CD servers that store secrets and generate .env files during deployment.
Generated artifacts make it easy to roll back or forward.
They provide interface to securely edit only permitted secrets with audit trail based on user authorization.
There's no need to introduce additional SPoF that can fail and render your application unusable.
Commiting a DDoS attack against config server might be in the end easier than DDoS ing Cloudflare, etc.
Config servers introduce additional unnecessary latency where a read of memory-mapped file with secrets would suffice.
Config servers are usually hosing on internal VPC to prevent DDoS attacks.
Where would the latency come from when it’s on an internal VPC (a local host type connection).
Even still a major issue still stands, the entire file of secrets is exposed when someone makes an update.
The latency comes from processing on the client and the config server:
DNS resolution + TCP handshake + SSL/TLS key exchange & encryption + HTTP L7 protocol + deserialization & serialization of data + DB query
Then you have the secrets stored in the application memory anyways.
Your application is anyway authorized to read the secrets so they're not secrets anymore. What's the difference to reading them from a file?
I don't see a service in a VPC generating a wait time more than a few milliseconds unless there was an issue with the underlying service itself.
Unless you have an application vulnerability, data in application memory is safe, unlike
.env. If an attacker gets access to the host machine, then they could just read our the system environment variables for the.env.Also you gotta remember, environment variables are global to that machine unlike the application runtime.
If an attacker gets access to the host machine you have bigger problems than passwords in environment variables.
To access secrets from another server you need some authorization and/or authentication. You can use source IP address restrictions and/or username/password but you anyway have to store it on the application server.
You gained nothing because if an attacker has access to the host machine he's able to read the secrets anyways.
The only thing you did was to add additional latency and SPoF and security vulnerability to the whole solution.
It seems to me you don't exactly know how .env files work.
.env files are owned by superuser (root). When the container is starting they are read into environment variables after which privileges are dropped to regular application user that starts your application/application server. There's no way to read .env files from the filesystem after your container has started unless you gain shell access to the container and then root access. But as I said, when this happens you have bigger problems than that...
Think about the log4j vulnerability. The main exploit was reading environment variables. If a config server was used, you wouldn't have had much worry about environment variables getting leaked. An extra layer for extra security.
Log4j has no root access unless your application code is running as root, which in and of itself is pretty stupid idea. Also exposing DB server to public is kind of stupid. If you follow basic security rules you can happily share your DB username and password on twitter.
I guess you also store JWT secrets in config server and SSL certificate private key as well? Let's make your applications unnecessarily slow on per-request basis for no added benefit.
Not sure of how much you read?
No addded benefit, let's ignore a centralized store for your teams to easily share and update configs, or the benefit of secret rotations, and so forth.
Unnecessarily slow? If adding a config server made your application slow then it's more your fault and your application was most likely already slow to begin with.
I also mention that config servers are usually access through VPCs which throws the arguments of "performance" out the window.
Chances are, you 99.5% already have a CI/CD server.
CI/CD servers generating .env files are already centralized.
CI/CD servers provide centralized, AAA protected access to secrets.
CI/CD servers do not require your applications to query multiple secrets on each request over network.
I see only drawbacks, no advantages over CI/CD.
Less latency, less dependencies, less maintenance, less security = profit.
If you claim VPC connected services are fast then I don't see why people are going crazy over memcached and Redis. Am I missing something?
TBH you probably are. In the cloud world Redis / Elastic Cache / Memcache are used HEAVILY. When I worked at AWS, having a cache in-front of an api that would get get 1m+ times saves 100k in computational power. It's very important, and can use VPC endpoints as the icing on the cake. An yes VPC no network requests.
No drawbacks, when you have thousands of applications deployed across multiple regions, you can change a single config and have all your applications pick them up on restart without having to rebuild.
Automatic secret rotation for more security.
If you only see drawbacks thats fine.
Most developers here aren't / haven't worked at the scale to notice the issues my article addresses.
If you use k8s, there is another choice.
For configurations - ConfigMap
For secrets - Secrets
However, in order to update the configuration without downtime, you generally have to create your own configuration center and provide API
Secrets plus external secrets (external-secrets.io/v0.6.0-rc1), perfect combo inside k8s clusters
Thanks for the article. I have known for a while now not to commit secrets, but I hadn't seen a way to easily keep track of them.
I want to address a couple of niggles I have seen in the discussion:
The phrase is "fool proof", as in protected from fools. However "full proof" is a common eggcorn, so I understand where it comes from.
I have not encountered the phrase "agree to meet in the middle" before, but that could just be my sheltered lifestyle. "Meet in the middle" is used in sentences like "I'm trying really hard here, can you at least meet me in the middle" or "It seems like we can meet in the middle", meaning compromise.
What you seem to be saying is that you want to stop the discussion where it is, so you want to "agree to disagree", because you can't reach a compromise or other agreement, which I suppose is a compromise of sorts!
Foolproof? I didn’t even notice, imma have to take that up with my MacBook autocorrect.
Using “meet in the middle” is a habit for me, I never really liked plainly using agree to disagree because we just agree to stop the argument there which seems a little shallow.
I liked the phrase because to me it insinuates we take the time to understand the other person then once we meet at the disconnect then we agree to disagree.
That’s just how I see it. Maybe I should switch back, might cause less confusion.
Yeah, autocorrect can be very frustrating!
No need to switch! I saw an interaction with another user and mistook your question about their interpretation of the phrase to mean you thought it was a well known idiom. My mistake.
We use .env for local Dev and versioned secrets for prod. I don't know that I've ever seen someone using production.env 🤷♂️
Maybe you've had bad luck.
I would warn against coupling local-dev to a config or secrets manager though.
I know I'm bias but I like your take 😂.
I share some of the blame, I should have been clearer in the article. Also, I should have taken into account that not everyone has tons of experience in the cloud space or the experience of working on huge enterprise projects. Especially when devs are saying things like "we have 2 trusted devs" so he can view the secrets.
Hahahahaha. I love this 🔥🔥🔥🔥🧯🧯🧯🧯 kind of articles. I just only can tell, I didn’t have any problem with .env files in my life. But is true that the cloud system. Looks better in terms of maintainability.
But the title was perfect to have some enemies.🤣🤣🤣🤣🤣
For the same reason as you, I’m not using dotenv. I’m storing all my secrets in environment variables and those are loaded on start time or compile time.
On AWS it works both for react (stored in pipeline) and spring (in config of EB).
I didn’t know about AWS Parameter Store, thanks for the tip.
Aren't those services the main target for hackers? A single bug could expose information for millions of companies and secrets...
Or is there a master password that is not stored on those services? But then again, you would have to keep this local secret secure...
Hey Marco, can you elaborate on what you're trying to say?
Are passwords encrypted end-to-end on those services? Or, in case of a data breach, the hackers can read all the passwords?
If self hosted, config servers are usually hosted on VPC's.
You can check the documentation for cloud services, for ex. Google Secret Manager.
Data is encrypted in transit with TLS and at rest with AES-256-bit encryption keys.They also allow you to access the service behind a VPC.
VPC Service Controls supportDon't forget Doppler. It's free and lets you have multiple environments.
I don't think I'll be getting in on this heated discussion myself - but I just wanted to say that I enjoyed the article. It was well thought out and reasoned and good examples were provided. I found it interesting. I also found the comments interesting and you have done a good job rebutting most peoples claims that you are wrong. I tend to agree with you (but I am newer to actual software engineering, have spent many years as a cloud (Azure) architect, though). Anyways, thanks for the post and please keep them coming!
Thanks, I really wanted to teach others another practice.
Don't hesitate please give your side. This is probably the most fun I've had on a forum site where people actually give opinions instead of being hive minded like on reddit or stackoverflow.
I was really confused about the person complaining about an SDK side. It's just a wrapper over a web API not the development kit for an Xbox.
With you approach I like that you can detect errors immediately, not waiting for the CI/CD pipeline to success just to start your app and realize something failed then having to re-run the pipeline again.
With a config server, you could update the relevant configs and just restart the server.
I don't get the obsession of "i could write it myself". You don't agree with me because you can write all the features yourself? I hope they realize once they write all those features they built a config server and did a complete circle 🤣.
Super good to know. I love the versioning baked into the URLs
Yea, makes it super easy to keep a paper trail of secrets / configs.
We must know that we can't control everything and some times we must trust even if we won't in other peoples.
So what I means is that if we don't trust why we should host our project in the cloud by starting, why we use cloud services for our projects?
Thanks for this article. I'm gonna follow this article
Good concise article with pros and cons listed nicely. I didn't knew any service like that existed (or maybe i was living under a rock all these years while working on different projects lol). Will definitely give it a try in my next project.
Although the main takeaway from this is that its totally upto the size of your projects and what method you choose. But it's good to have different options to use secrets in your projects securely.
I tell you what, keeping env files across multiple environments is a pain in the ass!
If that vault tool can help with that, I'm all for it
great writeup 👍✨💯
Thanks Madza! I enjoy all your articles, you write nothing but bangers!!
supabase has the password manager :)
Mind passing a link, would love to read its docs.
supabase.com/blog/supabase-vault
Muchas felicidades por tu articulo, yo considero que es una buena opción, generalmente para llegar a la misma meta, puedes elegir diferentes caminos. Personalmente creo que es un buen articulo y estaría encantado de ver un video explicando el funcionamiento en un proyecto básico.
Felicidades y saludos desde México 🌮
From your description, I think you've seen some bad practices, so here goes:
.envfile should never be committed to the repo -- it should be in your .gitignore!.env.developmentor.env.examplewhich could be used to set up a dev environment..env.examplewould contain a bunch of lines likeVARIABLE=with no value set, so that a dev could copy that to.envlocally and set the appropriate values..envin your docker container - the whole point is that these files specify environment variables, if they aren't already set. In other words, your prod runtime could just have these variables set by the launcher somewhere (eg via config in your deployment tool (we use Octopus) which is spat out somewhere.I don't have a problem with config servers, just that I think if you'd seen good practices upheld with .env files, you may not fear them as much.
Exactly the response I was about to write, you saved me some time bro!
Never commit your
.env(.env with secrets inside should be in you.gitignore) but commit a.env.examplewith empty values.This ^.
I only use .env files in a vs code dev container just to hydrate a local dev environment. REAL secrets belong in AWS secrets manager or some config service like you mention.
Thanks you 🙏
I just store my secrets in Netlify and use them with ntl dev. Problem solved.
I am clearly biased but I'd recommend taking a look at Doppler: doppler.com
Finally an interesting comment section with mostly devs arguments/discussions!
Thanks for the article 🙌🏼
Very insightful, the versioning complications didn't even occur to me. Thank you Gregory
Well yes security is a spectrum right. There is nothing "wrong" with doing these things, but different organisations have different risk tolerances. For orgs with lots of failure points (see: lots of people), you may want to avoid these things for reasons you listed. But for single developers or people aware of those risks this would work fine. I just think a sweeping statement like "stop using .env files" really raises the barrier to entry for people getting started on sites like these, and with little justification I find this article to be a bit clickbaity.
Funny you should say that because I set the experience level for the post to the highest I could to avoid that very issue. Either DEV needs higher levels or some people are lying about how much experience they have. Joking aside.
Little justification for entry level people who haven't encountered these issues, but big improvements for large projects with experienced devs who understand the issues and how this could improve their process.
What? Storing .ssh keys in the .ssh folder is literally how ssh works..
This article is lacking in nuance. If people have access to your local configuration files they already have access to your system.
Outsourcing trust to some third-party company doesn't make my work more secure. It just makes my operations more convoluted and expensive.
As opposed to an unknown number of people having access to everything via a third party hosted service.
There are self-hosted options that mitigate that risk.
I mean you trust a third-party company to host your code, sites, passwords like Github, Gitlab, AWS, Digital Ocean.
If thats an issue why use anything?
The fewer third parties I have to involve the better in my estimation.
Self-Hosted is a good option, but its more work maintaining the infrastructure which makes it non-trivial for small projects.
My primary contention with your article is that it espouses config servers as a blanket solution disregarding nuance in all other aspects.
I'm not a proponent of .env files, but I do not believe in over-applying general advice.
I’m pretty sure the options can be weighed. I don’t expect someone’s personal blog to have a whole config server but I do expect it from a company that brings in revenue and holds customer data, can never be too safe for your users.
I don’t think it’s a good look to argue against using a more secure practice. How does that look to consumers?
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 🫰
Thanks!!
It seems a little arrogant from you to say something like this, I would be curious to compare the CVs.
In any case if I'm wrong with my assumption you can just explain why I am wrong and what I am missing. That would be much more useful and interesting. If you don't give any explanation and just offend other's opinions, that is not constructive behavior.
Lol I should, but I don't want to seem pretentious, thats why I didn't detail my work experience.
I haven't been following this thread. I think your comments where important for showing a different point of view. If you could, I think it would be better if you restored it.
I'm a moderator here and even I don't have the power to restore comments.
To sum it up, I don't agree, I won't have words pit in my mouth, I have to put my son to bed and I don't care about this, more notifications please 😔
Great article. I also suggest using doppler
Don't forget Azure KeyVault
So that means you have an .env file for the config server in your application with all the secrets to your config server and everyone who has access to the .env file has access to all configurations.
No. There are no .env files involved.
How the application know about the config server?
What about different config server for different environments?
What about credentials?
That just creates a whole swaith of new issues no?
Like not being about to run any of the app if the config server can't be connected to, for any of myriad reasons.
Or even better than added yet another layer of complexity, do the opposite: Commit all of your
.envfile to your repos. This way, everyone on the team has access to them, so there's no need for a credentials manager, no need to connect to a remote machine to update its configuration, and 100% guarantee that everyone has the same local environment configurations available.The simple fact is that if your system enables an unprivileged user to access machines in your private network and connect to any containers they're running, you've already failed.
Having a database username, host and password should not be sufficient information for an unauthorised actor to compromise your systems.
If they are, you're doing it wrong and you've already been compromised.
yourlogicalfallacyis.com/appeal-to...
Because anyone could claim to work at Google or another Big Tech company without a proper LinkedIn link or reference to a "Our Team" / "About us"-page with their name & profile photo.
Also, how does the app know which URL to call to to get the credentials?
How does the credential server know the request for credentials comes from a valid app?
Hardcoded URL? Hardcoded app-identifier?
Ewwww. A text file which could be edited without the need of a developer would be more fitting. Let's name it .env and put a symlink to it in the main root of the project.
....Wait, what?
Personally you don’t have to believe where I work but if you need to know here’s my GitHub where you can see that I’m part of the Google org. But let's ignore that, there are way better talking points than my employment.
Your app connects using a VPC which is pretty much a local host like connection. You can hardcode this url not like it’s gonna change much.
Orrr wait let’s think outside the box, instead maybe you could define the url as a constant? Lol no text file needed.
I don't see
.envfiles going anywhereWhile yes, there are definitely better approaches for deployment scenarios to store and pass your secrets, it's still the most effective way to define them for feature development locally.
One thing I've done with my org to help improve the workflows around this file is to leverage 1Password. I'm able to create a
.env-templatefile with reference pointers instead of values, and the 1Password CLI will generate a.envfile using the template and fetching the values from my vaults stored in the 1Password cloud. I've written about how to do that here.Stop Using .env Files For Secrets Now!
There, I fixed it for you. ;)
Joking aside, your points are valid for secret storage. .env variables can leak into exception messages echoed to the client and be captured into log files too.
However, .env files are great for non-secret configuration. Especially for customising Dev environments such as which port to expose a test server on. If the .env file is gitignored then each developer can tweak non-production-affecting params and not worry about overwriting each other on merge.
One thing I don't see you address is performance. Maybe you can make a point for secrets but then you mix configuration with secrets.
Should we have to pay the price of a round trip to the configuration server every time you need a certain configuration value? This is madness! 😜
Not if your config server is hosted on a VPC (ex. Google Secret Manager or your self-hosted). An application, it only needs config vars on startup, so a quick fetch isn't going to affect performance. If it does, then the config server is not your issue.
Additionally, since config variables are fetched on startup, you can freely update config variables knowing your service will always get the latests version.
Madness sold separately. 😜
Posting the same thing as I did on the rebuttal...
Definitely a bigger fan of .env, but don't really enjoy either article because I think this is a stupid debate.
IMO do whatever is more efficient for your team. If there is actually a benefit to using the cloud vs .env files then use the cloud.
However, on my "small scale" projects, the time/costs required to implement a config server are not worth it. For me, it is more efficient to use a .env file.
.env in production is dumb I agree. But for localhost it's fine. I disagree that you necessarily need a config server or that you need to cough money to FAANG(bezos in particular) to feel secure. Env is simply a cover for an archaic functionality, wait for it, yes I'm talking about system environment variables. They are perfectly fine in production. Why do you ask? Well if someone breaches your server you are pretty much a goner as far as secrets go. Secondly, a lot of frameworks integrate the secrets in the final bundle during build time (NextJS server side is one example) and honestly using a config server there is just as dumb as relying to .env file.
You are right using a config server during build time would be dumb, thats why its not. Your server reads from a config server on startup.
First of all: This is really good advice! And I find it good when Googlers take the opportunity to help spreading good practises.
But ...
it is muddied behind bad communication skills.
I think if you dial down the paternalistic tone a bit it would not make you sound like you are selling snake oil.
There are simple scenarios where a .env file may be okay and a centralized solution might be a bit over the top. And there are many scenarios where this may be the appropriate solution but people do not use it for whatever reason.
If your intention is really to help people you may want to hold back a bit of your ego which may turn people off from evaluating your idea and instead evaluate you. That is countrary to your intention.
Thanks for the criticism, a lot of people took this as a personal attack which was not my intention.
The idea of having an .env file in a repo is to have a TEMPLATE of the needed ENVironment variables as documentation which variables need to be set. They could have default values but as we all know they should never contain real username and passwords.
The application (or deployment workflow) should then load this template .env and look in other places to override this default values depending on the current environment. This could be a .env.local file on the system, already set system environment variables or variables from a config storage.
The point is don't stop using .env variables to document which variables need to be set/cared about on the system where the application runs
The title might mislead beginners who are working on a Frontend project.
If you're on a Frontend project (React, Angular etc), I'd say keep using env variables to store simple configs based on dev/prod/sit environments (api url, or other non secret configs). Since most of the react projects are rendered on client side, there's no need to overcomplicate things.
BUT, if you need to access secrets, then you MUST store them in a key vault and access them from backend with managed/system assigned Identity, do whatever you need to do with those secrets and pass the data back to frontend. NEVER pass the secrets to frontend. You can't access values from key vault from frontend anyway because those key vaults restrict your access.
Definitely some good points.
I've seen so many people forget a simple and extremely important security tip:
cycling keys and secrets after an employee has left/no longer works for the company.
Making a process to re-create secrets and keys every so often is important.
⤜(ⱺ ʖ̯ⱺ)⤏
So what's worse: plain text password storage in 2022 or overused secrets and keys?
This seems like a non-issue...env files are not dumb IMO.
1 .env as a file can just be added to .gitignore file and most will recommend this if it's not already apparent to an experienced developer.
2 if a secret or key is being updated, it's more that likely by someone who is allowed access to all keys.
3 In my 15 years as a developer I've never run into this scenario. Not saying it doesn't exist, but it seems like a minor issue with many possible solutions.
we manage this with our deployments - Octopus already handles this kind of thing at deploy-time; of course, if you're looking to live-update, that's a different story, but if you're reading config every time from some remote service, good luck to ya
Going to jump in here. Ideally, you only load your configs on startup. A config server generally have very low QPS.
Even if you had to query it rapidly, you should be accessing it from a VPC for little to no latency. So using the description of a "remote service" doesn't really apply in the context of a VPC.
Has it happened? yes
Does it happen? yes
Is the problem having environment files with credentials? no
The problem is always people setting those files up wrong, and not securing them adequately.
That's literally where i was going with my original comment and everyone on here decided i was saying "we should all willy nilly throw env files everywhere! woooo!!!!"
I've got 16 years experience, worked on over 400 different customer sites/applications. Trust me, i've seen plenty of hacked systems, broken systems, badly programmed systems and well frankly there is no system that doesn't have holes, they don't exist. Oh and corporations are the worst, no one takes responsibility for anything and no one knows anything further than the tip of their own nose, which is often why different tools and systems conflict or rules in one place cause something in another place to break. I see that last part damn near every day, so when it comes to the credentials being the problem, that's the problem maybe 0.1% of the time. 90% of the time it's some non-tech person edited something they shouldn't have and broke it. the other 9.9% are the myriad of infinitely complex complications that may or may not happen at any given time. :)
There is missing important piece, is to clarify which is a secret, which is config. I can see everyone using .env for everything, but we should start thinking about separation of those.
For config, it's easier to manage and put in the source code directly. The versioning will go long with the release we make. Not necessary to have versioning from mentioned secret stores.
For secrets, it's also possible to manage by Git itself plus some secret tools like SOPS, git-crypt, git-secret,...
For certain service, the normal secret model need to be enhanced. When applying secret stores, or .env, it can be dumped from the process (talking about which layer being exposed). So there are tools (eg: berglas for example), which help us to maintain this. But comes with trade-off, that means more calls to external source.
An amazing git-based resource to control that your secrets are not exposed in the codebase is GitGuardian ! With this tool you can also check if there is a secret in the pre-commit event thanks to git hooks .
An amazing git-based resource to control that your secrets are not exposed in the codebase is GitGuardian! With this tool you can also check if there is a secret in the pre-commit event thanks to git hooks.
For me there's a point missing in this article, how is this more secure than an .env file? I'm not that much into security and that's why I read that article, how does it work? How can I be sure the URL is only accessible to the authorized entry points?
Hello Maxim, can you take a quick re-read of the article. Usually, confg servers are accessed from VPCs.
How do .env files and config servers compare latency-wise? Especially if you're not hosting your app with the company that hosts the config server? Would it make sense to cache the credentials in case the config store goes down?
Personally, I use GitLab secrets to build the .env files during deployment. This way it's not part of the repo and only an individual with access to the server could read it. Once you're on the server, you can also access the secrets within a credential server, so that doesn't matter. The only downside I can see is that this approach still lacks versioning.
You usually access a config server through a VPC which is little no no latency. If you are hosting your own, I recommend also hosting it within a VPC. Yes caching is a valuable option, having a redis store in-front of a config server can save you from unexpected downtimes.
All options are good just choose the correct one when needed.
if you need to give access to user's secrets then use Vaults, but I will add, create a cached of this info encrypted and timed, just last week AWS when offline for a few hours, and the funny thing that AWS said please use another alternative
Also if you need to have user .env files on your git use some encryption
git-secret.io/
There are plenty of solutions out there to stick to one.
All of them have pros and cons, If you can merge them
I think one source of friction is that .env files can be used very easily, even by the frontend code, with no network requests. Isn't there a little (or a lot) more code needed to use a secrets service?
Yes, there would be extra code added for a config pulling component. But you have the benefits of what I wrote in the article while also being able to dynamically update configs for your front-end without having to redeploy the site.
What a crazy bullshit. .env files should not be in repo, they should be in .gitignore - that’s it, problem solved. You can generate .env in CI before execution.
An interesting conclusion. It might be worth taking a second thorough reading if this is what you got.
If your IDE has access to a config server URL, then you have access to the same URL.
I’m not sure what this is supposed to mean.
Ideally, config server can only be access from a VPC or from users / applications you approve.
I guess If you IDE can access the url if you are allow listed? Does that cover what you are saying?
We use a .env-example file that contains env values to be used only on a local development environment or simply empty values for sake of documenting them.
On a production environment such as Azure, AWS, Vercel or really any other, the env variables are defined in the environment build settings passed down as system environments variables not as a file. The .env file is simply a standard way for a program to read local environments variables, and technically speaking it is not able to distinguish whether those values come from a system env or a local .env file.
And this is where the premise of your article breaks. If you assume storing environment values in a VCS file is the correct way of using those then you already started wrong.
But nothing wrong in using a .env file. As long as you do it correctly.
.env files are fine in most cases, especially during development. Config servers are best for massive apps that have widely distributed architectures, or for apps that need high security, such as those handling confidential information or financial data.
But for a simple app with a few thousand users, it's just extra complexity. KISS applies in this case. You can always refactor things to use a config server later when you decide it is needed.
Your solution for a local and user access restricted file is a 3rd party server with all your keys? And if that get hacked and have security problems? How's is that better than securing your server so only authorized people has access!? Or let's say something go wrong and your app restart and your key server is down as well?? Just let the service down?? I get your point, but sometimes simplicity is more efficient. If you manage to get to my env file... you probably have root access to my server at that point abd there are worst things to do by then than reading my env file.
I also mention open-source / self-hosted solution, you don't have to use anyones service. And every cloud service has a threat of going down, why use any cloud service then? Why host our server or code on Github, Digital Ocean, etc...
Sometimes, you have to get some difference. For example, when you send automatically an email each month, or depending on any event, you have to run a different setup on dev mode to run tests, to try several emails during the next hour, seeing your email directly on the console. Another example, you could need to call another api on dev mode than on prod...
Hackers don’t compromise systems, they compromise people.
That buffer overflow bug, code written by a human.
That bad admin password on a publicly accessible resource, entered in or accepted as a default by a human.
That phishing email clicked on, by a human.
Storing your secrets in an env file or a config store or any number of other means, is somehow accessible or was created by a human.
Compromise the human, compromise the system.
Ooh, we are getting poetic and philosophical now! I like it!
That's pure clickbait.
Would you mind explaining how?
Hackers don’t compromise systems, they compromise people.
That buffer overflow bug, code written by a human.
That bad admin password on a publicly accessible resource, entered in or accepted as a default by a human.
That phishing email clicked on, by a human.
Storing your secrets in an env file or a config store or any number of other means, is somehow accessible or was created by a human.
Compromise the human, compromise the system.
Ooh, we are getting poetic and philosophical now! I like it!
And how do you configure the configserver?
I don't understand, could you elaborate?
Why not just use placeholders in .env and replace them at the build process with ci/CD variables from your git provider. Seems less complicated to me instead use another 3rd party service...
Btw. Never ever commit secret values to your code repository.
What if I need .env files for the config server? Where do I store them?
Then convert your .env file to variables in the config server like so:
You don't have to worry about storing a .env anywhere.
So how would this be used in a JavaScript app? Would I use fetch to call this api? If that is the case that would be really dangerous.
That depends on how you structure it.
Generally anything in a front-end JavaScript is visible to the user regardless if you where using a config server or
.env.Well NodeJs is a server side language [JavaScript], so I doubt you would be sending .env variables to the client. Or you could make a REST API call using a server side language. In Coldfusion we use CFHTTP.
My preference is to store my secrets in a DB table. They are encrypted, not hashed.
I mostly agree with OPs sentiment on storing sensitive info in plaintext anywhere. It's why you hash/salt passwords before storing them in a DB (at least I hope you all do).
However I disagree with the articles title. Using .env files and even checking them in is fine, as long as you are cognizant of the things you're putting in there.
Of course plaintext storage of any sensitive info that gives authority to impersonate and possibly do harm is never a good idea. But things such as urls, appids, config values, etc that are public by nature or relatively easy to figure out is okay in my book. There are some gray areas like internal ips for example, in which enforcement is subjective to how important the information is and weighing the risks should it be known.
There's nothing inherently wrong with .env files and storing them. It's a rather simple and convenient tool to manage environment specific values. Ultimately it's up to you to weigh the pros and cons of using them.
I can give another reason to avoid .env files.
.env file (or .env.prod + .env.dev + ...) are predefined files by definition. Literally, an application dictates you what your environments should be.
It is totally Ok, if you can negotiate it with devops guys. But what if they use ephemeral environments with a backend URL like "bugfix-123.example.com" for a short time being?
Would you dynamically generate .env and rebuild docker for that for each branch?
Remember: an application SHOULD BE environment agnostic!
Otherwise it is as weird as a library dictating to a wrapping framework what to do. Management should be directed in opposite direction: from complex to atomic.
Call me when you come up with a solution that doesn't require a couple dozen fetches form an external service per request handled.
If you need to fetch a couple dozen configuration vars on every request, then you have a bigger problem that's beyond my article.
Most real-life problems are "bigger problems".
I believe that one day we will get an article called: "Stop living Now !"
Hopefully with a lot of evidence and well presented ideas.
The way I handle with teams I work with, is to agree to have in the repo, a .env.example file with no real information, and add .env to .gitignore.
If you adjust the title to "do not commit .env files to your repo", I will 100% agree.
Calling dumb for storing secrets in .env file is wrong. Because third-party apps won't recover your losses if they got hacked or got data breach due to some reason. Then the person or company who trusted that third-party app will be dumb here.
Yea there is always a risk when using third-party services like AWS (the leader in cloud), Google Cloud, Azure, Github, etc.. Thats widely know. Why host code or sites anywhere then?
I also listed open-source and self-hosted option.
the sign of a good post is lots of discussion. while I don't necessarily agree with you on this, it's an important topic that certainly merits discussion. Looks like you got it.
I respect that; change does take time.
Honestly I feel like this was a conversation that needed to happen. I love how big the convo is with everone explaining their side.
"Change does take time". OMG the hubris.
Yes and no. File .env could contain defaults. You could use another one to override defaults (then all keys must have a default value already defined). The problem is when you have ex. .env.secret but someone adds it to the repo (to prevent this you must add this to ex. .gitignore). So "no" here.
Then injection of secrets is a better way on prod. Or a vault. With proper implementation you could publish an image with default values to run it locally or for tests. Image would hold no secrets. When starting on prod you simply inject proper values keeping it a secret even from developers. And you can close network then (image is already built so no need to leave system). Thus "yes" here.
Hackers don’t compromise systems, they compromise people.
That buffer overflow bug, code written by a human.
That bad admin password on a publicly accessible resource, entered in or accepted as a default by a human.
That phishing email clicked on, by a human.
Storing your secrets in an env file or a config store or any number of other means, is somehow accessible or was created by a human.
Compromise the human, compromise the system.
Ooh, we are getting poetic and philosophical now! I like it!
Kind of a red herring argument. I've been programming for businesses of all sizes and I never saw anyone storing passwords as plain text in files. If the target audience for your post is the very few misguided souls who are doing that then it's good advice. But for the rest of us the .env file is where we store things that are not secrets, like server names, URLs, numeric values, etc. Very easy to maintain, very easy to access, zero downtime. Can you say the same thing about a config server?
Yes:
Store configs like server names, urls, numeric, and so forth.
Easy to maintain, yes a global config access system with permissions and audit logs.
Easy, access. Some have a UI that you can access with a hierarchy.
Zero downtime? Only if that cloud hoster goes down, in that case your whole app is down.
Bottom line. Yes!
“It’s time to correct this behavior plaguing the community” - yikes! That’s not the way to start any discussion
.env files ar not supposed to be versioned.
Eventually you can have a kind of .env.example which will allow freshly cloned repository to copy and rename to .env.example to .env
Versioning is aimed towards production secrets / configs, not local development .env's if thats what your asking.
Regardless, versioning is useful for predictable / reproducible builds.
Looks like no different to me? Or even worse? What if someone can access this app.com/config/DB_PASSWORD/v1 ?
If this is a backend service than the users won’t have access to the url. If the config server is access through a VPC, then the config server will have no access to the internet making it safe.
.env files work and are simple enough.
And could be improved and modernized!
What if the user has spotty internet?
They can't use any of the website even if the rest would be able to load.
And AWS and Google servers have went down plenty of times
I'm not understanding, please correct me if I'm wrong.
The users internet has no affect on the service.
Of course it would, if the get request fails, then the whole app wouldn't load, no?
Yea that’s the users problem, nothing to do with the service?
I don’t understand what you’re trying to say, try your statement again plz.
if a user cannot use the website, that's a issue with the service.
Whereas plenty of website using a simple
.envfile would load in fine, no issues, and are even optimised to work whilst the user is offline as long as the first initial bundle of html/js loadedHey George I'm not sure how experienced you are but I'll try to break it down.
If a user cannot use a website and the issue is server side then its the service fault. If a user has spotty internet and can't connect it's the user's fault.
A PWA has nothing to do with a server, thats just a client side app. Thats just like downloading something then running it locally. That has nothing to do with its access to the server. Am I being clear?
.envfiles for local development work only. Inprodno.files at all.Good security practices, including PIM and PAM access are critical to being successful.
You should use Infisical for that. Solves all the mentioned problems and it is end-to-end encrypted.
ah I see makes sense you put it high - I might've missed that. In that case the article makes more sense/seems right.
I don't want to dismiss what you where saying. I get what you are trying to say. I also could have been clearer in the article about who I was targeting (the people who would have encountered said issues).
yeah no, same.
Never seen/worked for a company that used .env files.
All the tutorials are aimed at the small/hobby apps
You'd be surprised.
Nothing wrong with informing others of alternative practices.
whole post is good, but you missed the last step - to show how to use those secrets in code :(
If you familiar with containerized application or use Kubernetes before, you would never write this post ever. No one use .env file in production.
I am, but there are apps that exist outside of using containerization.
Ipse dixit
I use Kubernetes Config Map.
How do you think?
Thanks? Lol
Perhaps a better title for the article can be ".env file alternatives for enterprise systems". You must understand that not everyone is involved in developing enterprise systems.
If you're not self-managed, most of the app services at aws, azure these day have configuration/app setting where you can set the environment variables.
Tell me what open source solutions exist that I can deploy myself on a standalone dedicated RHEL instance, I'm not interested in paying for a service I can set up myself.
I didn't realize Vault could be self-hosted, maybe I jumped the gun there.
Possible to use any Vaults or ScreteManager services or other Cloud platform central repos to be used
Nothing of interest here. Just yet another everybody-is-stupid-except-me, FUD-based advertorial.
I do want to mention that you can substitute with OS variables or .zshrc (and can split / import / ...) .. so the .env file in the project never contains actual data but ${YOUR_SECRET}
Add to the discussion