Table Of Contents
- Hello Reader
- The problem with .env files
- Config servers to the rescue
- More Pros of a Config Server
- About the Author
Hello Reader ππ½
I've worked on huge enterprise systems and I'm disappointed to see 99% of all JavaScript tutorials tell you to use a .env for production config and secrets which is dumb.
It's time to correct this behavior plaguing the community. Let's explore the problem with .env files and the ultimate solution.
The problem with .env files π«
1. Storing the .env file
The problem is well... It's a file. You are not supposed to store your "production" file in your repo; where do you put it? Directly in the VM root? What about Docker containers, do you bake your secrets directly in the image? If the image leaks, everyone has access to your secrets.
2. Updating a secret config
What happens if you need to update a database password? Whoever updates the .env will have access to every secret in the file. I don't even have to explain why this is bad. Every time a config has to be updated whoever is updating it can see EVERY secret.
3. Versioning
Let's say you are deploying a new feature that requires updating your config / secret variables, something goes wrong and the application gets rolled back.
Uh-oh does anyone remember the last values we had in the .env? We have no history and the application requires the values we just deleted/overwrote.
Config servers to the rescue π¦ΈββοΈ
The perfect solution to all these issues is using a config server. A config server is an externalized application for storing configs and secrets. It's considered the central hub for managing secrets across environments.
Multiple cloud services can function as a config server like AWS Parameter Store, Google Secrets Manager, or HashiCorp Vault for my open-source enthusiasts.
Once you create a secret or config, most of the time you are given a URL like https://app.com/config/DB_PASSWORD/v1.
Let's see how a config server solves all the issues with .env files.
Solving: 1. Storing the .env file
With a config server, all the secrets are centralized in one place, encrypted, and can only be accessed by applications and users you approve.
Solving: 2. Updating a secret
With a config server, instead of updating a secret, you create a new version. After creating a new version, you update your secret URL like .../config/DB_PASSWORD/v2 or .../config/DB_PASSWORD/v3.
Solving: 3. Versioning
Like with solution 2, most config servers have automatic versioning. If you need to update a secret, create a new version and update the config URL in the application. If the application gets rolled back, it will automatically use the last config URL you had in place.
This way secrets are protected and your applications can get rolled back with no issues with the previous secrets.
More Pros of a Config Server β
Automatic Secret Rotation
Secrets can become stale which can lead to your systems becoming compromised! A centralized config like AWS provides automatic Secret Rotation.
If you team or org all pull the same config, they will automatically get updated with the latest values. No need to send it over slack, no need to get a "trusted" dev, or having the possibility of forgetting to update one of your .env files. Easy and painless!
VPC Endpoints
A config server is usually hosted on a VPC which provides a localhost like connection for your services. This allows the ability to pull secrets without them ever having to touch the internet (virtually no latency), nor allowing outsiders to query the server.
Audit Logs
Did a secret get leaked? Config servers usually carry audit logs so you can check when or where a secret was accessed.
Does an updated config cause an error? Check when it was last updated and if needed, preform a global update for all your services. No plain text file editing needed.
Final Thoughts π
I hope now developers will start using centralized configs for their production services. .env files are unreliable and have no access management, versioning, or safe updates.
I'm not saying .env file don't have a purpose. They can be used for local or development-oriented environments.
What I'm trying to say is don't store valuable secrets in simple files, especially if my data is in your service.
About the Author π¨πΎβπ»
I'm Gregory Gaines, a simple software engineer @Google who's trying to write good articles. If you want more content, follow me on Twitter at @GregoryAGaines.
Now go create something great! If you have any questions, hit me up on Twitter (@GregoryAGaines); we can talk about it.
Thanks for reading!
Oldest comments (290)
supabase has the password manager :)
Mind passing a link, would love to read its docs.
supabase.com/blog/supabase-vault
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.
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.
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.
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.
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.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.
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.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.
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.
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?
Honestly... This sounds great compared!!
Exactly
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
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.
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
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.
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
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.
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 supportGood 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.
.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 just store my secrets in Netlify and use them with ntl dev. Problem solved.
.env files work and are simple enough.
And could be improved and modernized!
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.
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"
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.
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).
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.