Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
I don't think there's any harm in storing secrets in a .env file, 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 .env file can be minimized. For instance, be sure to keep your .env file 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 .env file.
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 .env file.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
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).
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
This doesn't solve that anyone who updates it will have access to all your secrets in plain text. No matter how secure the .env it 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.
A developer with M.Sc. in Computer Science. Working professionally since 2010. In my free time I make music and cook.
Also I don't and after the recent events will not have Twitter.
Location
Budapest
Education
Eötvös Loránd University (ELTE - Budapest Hungary) Computer Science M. Sc.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
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"
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
As I mentioned, it's essential to encrypt your secrets rather than storing them as plain text. This way, even if someone can read your env variables, they won't be able to use it because it is a useless scrambled string of characters. Additionally, you can set the file permissions so that only the owner can read it, further protecting your secrets. Take the following Unix command as an example:
chmod 400 .env
This will ensure that only the file owner can read it and that no one else can access it. This is a great way to keep your sensitive information safe and secure and ensure that only those who need to see it can do so.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Now, the problem becomes tied to the party that you are sharing it with rather than the .env file 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.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
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.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
A software engineer that specializes in serverless microservices. I love creating helpful content about programming and reverse-engineering.
I am employed at Google; all opinions are my own.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.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).
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.