Table Of Content (TOC).
- Introduction.
- 1. Storing The .env File.
- 2. Updating a secret config.
- 3. Versioning.
- Why
.envfile? - Securing an .env file?
- Advantages of using an
.envfile. - Problems With Centralized Config Servers.
- Conclusion.
- Bonus For Linux Enjoyers.
π Inroduction.
We all know that first impressions are essential. The same goes for the first sentence of an article. In fact, it might be even more critical for an article because the first sentence is what will determine whether or not someone keeps reading.
But, in the case of this article, stating that working with large-scale systems would make you eligible enough to write about the topic is quite funny. This sentence has a psychological effect that makes readers feel like they are stupid and doomed, assuming they are all working on "Hello World" kind of projects.
Needless to say, as a reader, you may start to wonder: "What in the world does he mean when he said he has worked on large-scale systems?" I mean, literally, everyone is doing that nowadays. I don't think it can be used as a unique selling point or anything; nearly everyone has experience working with large-scale enterprise systems.
Even the most junior engineer has likely worked on a system that processes millions of requests/records daily. So what makes working on large-scale systems so unique? What makes you think your experience is worth anything special? You need to show that you have something unique to offer; otherwise, it's just another redundant sentence in your article. But anyway, let's move on.
Let's start by criticizing each point that looks like a problem with .env files when in reality, they are not problems at all but rather misconceptions.
π 1. Storing the .env file.
π Go To TOC
This section started by:
The problem is well... It's a file.
Well, I don't know about you and which OS you are currently using, but everything in Linux is literally a file. This includes devices, processes, sockets, files, pipes, etc. However, the critical question is: what's wrong with it?
If you think it is not a good idea to make everything in Linux a file, including env vars, then you have to invite Linus for a debate and discuss the drawbacks of this approach. Provide your solution instead.
Additionally, containers are based on Linux cgroups, namespaces, and other components, which means that they are also built around the concept of everything being a file. This makes Linux a very powerful os for running containers, as everything can be easily managed and controlled via files.
Moreover, everything in k8s is also a file, a YAML file. This concept makes k8s extraordinarily flexible and customizable. You can literally configure anything you want, and there are very few restrictions.
As the author is now working at Google, he has the chance to discuss with the brains behind k8s, argue with them about the drawbacks of files, and share his insights with us. We would love to hear his thoughts on this matter!
Besides, the question is: Who is committing an .env file to public repos? Literally, no one with at least two brain cells is willing to commit an env file, as far as I know. Some developers on github, me included, commits only templates of this file to help other understand the env vars used in a particular project. There is a .gitignore file in case you want to ignore that file from being committed; that's the basics, and everyone should be aware of that.
Even if you don't like to include a .gitignore file for each new repo, you can add a new entry in a global ~/.gitignore file, so you don't have to worry about including that file each time when creating a new repo.
Now, you may wonder: well, how to share the .env file with other developers? And the answer goes like this: If you're collaborating with other people on a project, it's essential to keep your .env file private so that only invited collaborators can see it(e.g., create a private repo for the .env file).
π 2. Updating a secret config
π Go To TOC
I have never had access to updating a database password throughout my years working at companies. This is because there is always someone responsible for managing databases. Having access to update passwords would be a huge responsibility and could potentially lead to security breaches.
So, having someone responsible ensures that passwords are kept up to date and secure. It also means that if there is ever a problem with a password, there is only one person who needs to be contacted to fix it. This system may not be perfect, but it is the best way to protect company data.
All I can get are env names and use them within the app. That's it; Nothing else. This is why having a designated person is so important. Not only does it make life easier for employees, but it also helps keep everyone on the same page, safe, and secure.
π 3. Versioning.
π Go To TOC
Environment variables are not parts of the app code, so there is no need to version them. I have never used an app that keeps track of password history changes, and I see no reason why this would be necessary. They are just static values and don't change often.
But in any case, if you want to apply versioning to an .env file stored in a private repo, you can release a new version for each value change.
Then the author proceeds to provide a solution to a problem that doesn't exist. What's even funnier is that the solution leads to potential security risks. So basically, let someone else do it for you if you don't want to manage your secrets, not to mention that the party you share with is a centralized place. If it gets compromised, everyone's secrets in the whole damn world will get exposed.
So, everyone would instead have control over their secrets and not depend on third parties, especially in case of sensitive information.
π Why .env file?
π Go To TOC
We, as developers, use .env files to store environment variables. These files are not meant for use in production and should be removed/ignored from the codebase before deploying it to production. If you have ever worked with containerized apps, you would know that.
The idea of having an .env file in a repo is to have an example or template of the required env vars as a form of documentation that tells which variables are needed for this project. They could have default values, but as we all know, they should never contain plain text credentials. It is like telling other developers that X, Y, and Z are used in this app as env vars. Having an .env template file in a repo sets expectations for other developers and maintains best practices. This would help new developers clone the repo and work with it without any hassle.
The application should then load this template .env and look for other places to override these 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 config storage. If you ever used Jenkins or built a DevOps pipeline, you probably encountered that.
We get it; it is not a good idea to use .env files in production because they can contain sensitive information like database passwords, API keys, and other credentials that should not be accessible to others.
However, one thing you can do though is to take additional precautions to keep your .env file or env vars secure and safe.
π Securing an .env file?
π Go To TOC
An .env file is not secure if it's being used for production purposes. Anyone with access to the machine can view and modify it without permission.
However, you can set permissions for this file. I don't know about you, but you can use the following command to secure your env file:
chmod 0400 .env
Doing so, the .env file can only be read by the owner and no one else. You can use this command in a docker file if you need to copy it into the docker image. But, usually, it is not encouraged to do so. In the case of docker, secrets can be used, which are discussed later in the following sections.
If you have ever worked with laravel, the chances of using the .env file in production are high. And that is ok as long as you keep it secure. The following is a typical security practice used by Laravel developers:
#Disable index view
options -Indexes
#hide a Specific File
<Files .env>
order allow, deny
Deny from all
</Files>
In docker, you can import env variables with docker-compose using the following command:
docker-compose --env-file .env
Or you can specify the env file within the YAML file:
version: "3.8"
services:
frontend:
image: awesome/webapp
env_file:
- .env # path to your .env file
If you want to pass secrets, then you can define a secrets section within the docker-compose.yaml file:
version: "3.8"
services:
frontend:
image: awesome/webapp
secrets:
- server-certificate
secrets:
server-certificate:
file: ./server.cert
If you are building a docker image, you can create an env file to store secrets and mount the file to the container.
PYPI_USER=dev_bro
PYPI_PASS=my_super_duper_secret_token
Now you can load the .env file and give it an id called my_secret. We can use this key in the next step to access the .env file. Then modify your Dockerfile so that it mounts the secrets.
FROM python:3.9-slim-buster
COPY build-script.sh .
RUN --mount=type=secret,id=my_secret . ./build-script.sh
# build-script.sh:
cat /run/secrets/my_secret
Now, you can build and inject the .env file into the container:
export DOCKER_BUILDKIT=1
docker build --progress=plain -t "my_app" --secret id=my_secret,src=.env . --no-cache
Note that these env vars are not logged into the history, so running the following command won't reveal the secrets:
docker history my_app --no-trunc | grep PYPI_PASS
For more info about secrets in docker, you can refer to this piece of docs.
Additionally, if you are using k8s, there are API objects like ConfigMap to store config data and Secrets to store confidential data. Or, you can set env vars within a pod.
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
name: special-config
# Specify the key associated with the value
key: special.how
restartPolicy: Never
I have worked on many projects, some of which are open source. In some projects like this one, I used env vars to store my secrets within circleci to publish a new version to PyPi automatically.
Moreover, for security reasons, I have noticed that PyPi has implemented a feature to allow authentication with their servers through using api tokens without the need for passwords anymore. So, now you can store encrypted PyPi credentials within env vars.
If you ever built a pipeline with Azure DevOps, you probably wanted to copy the .env file into the docker image using Copy files task:
steps:
- task: DownloadSecureFile@1
displayName: 'Download secure file'
inputs:
secureFile: .env
- task: CopyFiles@2
displayName: 'Copy Files to: $(System.DefaultWorkingDirectory)'
inputs:
SourceFolder: '$(Agent.TempDirectory)'
Contents: .env
TargetFolder: '$(System.DefaultWorkingDirectory)'
If you are using Jenkins, you can inject env variables using plugins like envinject
So, as you can see, it depends on the type of applications you are dealing with to follow the best practices to securely use an .env file.
π Advantages of using an .env file.
π Go To TOC
There are so many advantages to using .env files or environment variables, such as:
Ease of management: Having worked on so many backend projects, I find
.envfiles easy to manage because they are self-explanatory and don't require additional documentation.Simplicity:
.envfiles simplify the task of managing different backends because it allows you to configure all the necessary settings for each backend in one place.Debugging and testing: It becomes easier because developers can modify a specific environment for each application.
Sharing:
.envfiles templates like.env.examplecan be added to git repositories, so other developers on the team know what environment variables were used for that project.
π Problems With Centralized Config Servers.
π Go To TOC
Several potential problems can occur when using a centralized config server for an application. If the server goes offline, the app will not be able to start. If the server updates and renames an environment variable that the app is not expecting, the app may crash on the next restart. Finally, if the app is hosted offline, it will not be able to start without an internet connection to load the env vars from outside.
π Conclusion.
π Go To TOC
At the end of the day, .env files and environment variables work fine and are simple enough for development purposes, as long as you know how to use these files. However, it is totally up to you to choose the best approach that aligns with your personal preferences, what works best for your particular application or system.
π Bonus For Linux Enjoyers.
π Go To TOC
On Linux, if you want to print out a specific environment variable, like LOGNAME, of the current process, then run the following command:
strings /proc/$$/environ | grep LOGNAME
And last but not least, remember that everything in Linux is just a file including the command that you have just executed:
cat /usr/bin/strings
Note: This article is not meant to insult anyone by any means; I just wanted to share it with everyone to clarify the situation with .env and give some tips on how to use them.
Have a lovely weekend, folks.
Cover image by Mike Souza, on Flickr.
Top comments (119)
Ayy, thanks for the shout-out! Let me plug my article here.
Stop Using .env Files Now!
Gregory Gaines γ» Sep 19 '22
First let me say I like how your only cons against config servers is that it can go down and it's remote. Wait till you learn about what a database is, you'll probably be using a json file for the rest of your life!
Also what's your obsession with bringing up my file statement? Is the
/usr/bin/strings"file" carrying production data? If not, then I don't have a problem with it.As large as Google's? Lol. Im Jk. Nice burn tho.
Funny enough, internally all secrets / configs must be stored in enterprise stores like HashiCorp Vault or Google KMS.
New people, people who don't know? In-fact, .env files have their own vulnerability listing because of how much it has happened
https://www.acunetix.com/vulnerabilities/web/dotenv-env-file/. So a-lot I assume.One of the benefits of a config server is reproducibility. This won't be an issue. Config servers keep a trail of all configs.
If your database goes down your app can't start. If your hosting platform goes down your app can't start. Anything can go down, doesn't mean it's not viable. You can introduce a cache within your application so it only has to read variables one time.
What if your private repo gets leaked, now everyone has access to all your **** secrets! What is someone downloads the whole repo to their laptop and it gets stolen? Or someones personal laptop has one of these
productionconfigs and someone decides to a take a peek?Just saying with a config server, a stolen laptop means nothing since you have permissions and access management. Someone can't just come along and copy and past a config server.
--
And some points still stands.
β-
Final note: I should have taken into account that most devs reading probably havenβt operated at the scale to notice the issues my article is addressing. Maybe thatβs one of the major disconnects.
Iβve noticed a lot of I havenβt had these issues therefore it doesnβt exist type replies.
A practice adopted by Google doesnβt automatically become universally applicable for every project.
At a big tech company it might make sense to reduce security risk by taking layers of precautions. But if itβs just a small personal project, obviously people shouldnβt care too much about setting up a separate config server, or doing credential rotation.
Keeping secrets away from repo is still a common practice. However, the way Gregory presented it just isnβt very helpful. The βI work in Google so I must be right. The audience hasnβt operated at Google scale so they donβt understandβ attitude is simply naive and arrogant.
If I came off as naive or arrogant, I'm sorry I didn't mean to come across that way. The reason I brought up my work experience is to give credibility behind my statements. In fact, people have brought up my Google experience more than I have.
I also did admit to the fact people haven't worked at the huge scale where they experience the problems to makes my article useful and I'v already admitted that myself. Even in my original argument I mention that
.envfiles have their place which people seem to miss.I never said since people haven't worked at Google they don't understand nor have I ever implied that. I only mention scale which you yourself proved in your comment above.
If you need to have to back up your credibility in order to make your point is no good idea. It's basically arguing with authority (you in this case).
Your point should be good independently the speaker is working at google or at some 2 people random startup.
I see it as having a good point and worked in the environment to apply those points. I decided to give a little insight into how I came across those points, not have people take it as a personal attack.
I read a lot of the comments on your article and the common theme seems to be the added dependency. I'm curious about the Google secrets manager now and will give it a spin since I find myself copy & pasting environment variables between environments and two dev machines. The service would allow me to have one central point to manage them (yes, also a single point of failure).
Yes, but only if you need it or it will make development easier.
And wow! someone willing to understand the approach instead of throwing an insult!!
I really can't see why so many people show hate on this approach. This is a good approach for development AND production environments because you have one central point to manage all secrets. I have been using this approach now for a year without being in a big company which is FORCED to do so. I just love how easy it makes every step of development and it removes the possibility where secrets could potentially get leaked. And if you structure all your secrets your life as a developer will become so much easier :)
Thanks for a really good, but misunderstood (?) article! Keep on writing about you experience because I will for sure read them :)
Thank you Tony. Iβll drop more bangers be sure to follow to get notifs.
good
I must side with Gregory here on this one. We at Intel also have to separate secrets and everything.
dotenvdoesn't seem a suitable candidate AT ALL. I removed alldotenvuse from the React projects. wj-config allows me insertion of K8s secrets or config files while maintaining the separation between data source and consumption.Bottom line is: Don't get stuck in the past.
I am curious, what secrets you are keeping in react projects at Intel...
You know, any "secret" the client has is no longer secret to anyone accessing that UI.
The whole story behind wj-config was to make sure it worked in both NodeJS and React. In our particular project yes, we did not have any any secrets in the latter, but we had a URL mess.
A whole lot of time wasted by devops trying to figure out why a deployment is not using the real env var, just to figure out
dotenvis loading some file and shadowing them.Yes I agree,
dotenvis some weird file configuration pretending to be env configuration. That would be pretty good example of how not to use .env file.If you are using a private repository, you can add contributors without sending emails. Just add the GitHub handle to that repo as a collaborator.
Again if you have to edit a file, all the secrets are exposed to the editor.
You hire someone who is responsible for all his/her actions, right?
Commit history?
Why do you need that?
At Google you can be the VP of a project and STILL don't have access to see secrets. Thats just how things work. It's like moving to a safe neighborhood. There's no crime but you still lock your doors.
Wasn't the point of a
.envwas that it goes in the .gitignore?The fact you asked that scares me a little lol. Rotate AWS Secrets, CyberArk Rotate Secrets
As mentioned in his post, you can have a private repository to share the env file with other team members. If someone changes the values of these environment variables, it will be logged into the commit history.
Maybe I'm not being clear enough. No one person SHOULD EVER have access to view any secrets at anytime, unless they are initially adding it (which even then shouldn't be possible but I don't want to increase the scope of this discussion).
It doesn't matter where that .env is. In a repo, the moon, under a volcano, or area-51. The rule above still applies.
I am not quite sure on what you base the assumption that people are using .env files in production. This is why you sort of come up as arrogant. You seem to somehow assume people are clueless.
Your actual deployment secrets would usually come from your, well deployment config, and can come from many places. These can be sealed secrets, gh actions secrets, and the vast majority of devs will not know, or care what and how the production environment does it.
In my experience.env, just as docker-compose are part of your dev setup. There is absolutely nothing secret there. The whole point of having these as env variables, rather than a config file of some sort you read directly, is to replace them later, rotate them and whatnot
It was more of a PSA than a hey you do this assumption. I never claimed anyone did anything so Iβm not sure how I came off as arrogant but Iβll work on it. Also I did not mean to challenge anyoneβs intelligence.
I didnβt mean for anyone to take my article as a personal attack.
It's a big like saying stop using docker compose, is not good for production. Sort of moot since most people know and don't.
Now the funny part is there are many ways to deal with secrets, depending on your deployment, including yes encrypted files you can keep in your repo. And your solution actually will not work, or be redundant in many cases.
As of why you sound arrogant? Well, "I have been driving fast cars on the highway, let me explain to the yokels why pickups suck", lol. Sort of missing the use case.
I think a better comparison is "I've seen 99% of car guys saying you can beat a mustang gt with a pt cruiser and here what to buy to do it" lol. And of-course I see the commenters at the pt cruiser enthusiasts telling me you don't need a new car, just mod your existing one, eventually making it as fast as the gt instead of outright buying the gt.
I put the use case in the first sentences, but i digress. My solution is completely viable, plz re-read if you don't think so because you example has nothing to do with making my solution not viable or redundant. Or can you try connect them better?
Oh boy. The problems you are solving are not problems because people don't use .env files the way you think they do. The world won't end if you know the local postgres container password is "password". So no it does not need encryption, or rotation or whatever the heck, because it's just a placeholder password, for a placeholder db, for placeholder data.
To repeat once more. In vast majority of cases .env is used to manage environment variables for a local container or app, in a development setup. The reason it's shared, or rather an example .env is for people to know what env vars need to be set.
Your production deployment will vary. If you deploy to AWS you will use the AWS secrets manager. If you deploy to GCP you will use the GCP secrets, naturally.
So telling people to not use .env, is rather uninformed as to what people use .env for.
I know .env donβt need those things, Iβm saying they canβt do those thing thatβs why I bought up a config server and heβll out those who might need those things.
And not everyone uses .env files for what they are for which caused the birth of my article. I feel like we are in a circle.
I was literally searching for the use case of KMS servers, your points and explaination completely makes sense to me.
One thing, I would like to add:
Both the things have their own use-cases, KMS is better at a scale like Google. .env is better in smaller engineering teams who know what they are doing. Like in my case, one person is responsible to set ENV in production environment. Rest of all, gets only test credentials.
One can move from .env to KMS when project goes so big (people count increases) by Changing all existing secrets.
Well said, still then I'd argue even if you're small scale you should use the best practices.
Fundamentally it's not a matter of scale or not, it's a matter of security.
Even the one person you mention might have a compromised system at any point in future. Better do it now than be sorry later.
I work in large enterprise (we're competitors to Google ;) ). Your article makes a lot of great points.
I'm not sure if Google has something similar, but we use AWS Parameter Store to centralize our "env". We have robust permission system that allows only the app to consume the secrets, and certain users to edit the parameters.
In a large enterprise this helps us separate our concerns. Our developers can focus on developing rather than securing an .env file. Our DevOps can focus on secret management. We also frequently rotate values in our "env" which would really annoying to keep all the devs in sync, securely. This central place allows for someone to edit the value Once and All developers now have the latest values.
Additionally, our parameters are fetched at run time vs at build. Meaning we can rotate a value without restarting the services. The services automatically pick up the new values next time it's called.
Unfortunately this method adds a lot of overhead. Unnecessary in small / solo projects. ENV files would probably best. But in enterprise, in large teams, and teams with strict security protocols (separation of concerns) there are alternative solutions that may be better.
Databases can be hosted locally next to the app and connect to it using Linux socks so essentially you can pull the ethernet cable out and it would work.
Config servers can be hosted on VPCs giving a local host like connection to your application. No internet traversal required.
But if you pulled the Ethernet cable out then how could users connect to your application? Wouldnβt it not be useful at that point? Am I missing something?
You are missing the difference between development environment and production deployment.
You usually run a bunch of services locally on your laptop, while you work on one of them. Your users are not connecting to that.
E.g you could have frontend, backend API, proxy, message broker, db or two, worker services which consume from a queue. And you can be working just on one of these, but you need working setup.
These would need configuration, including secrets shared between services. You don't need to worry about these being secret, because only db or service you can use them for are said services you run locally.
This is what majority of people use .env files for, i.e. keep environment variables for local environment.
Granted, you can have secrets for third party services there, so it's never good idea to commit .env in repo, in case someone adds something actually secret there. Also why it should always be in .dockerignore, so you don't push it to image registry
Your production deployment and configuration are a whole different beast. How you keep your the real secrets depends on your setup. At this stage usually you would separate secrets, and regular env vars and treat them differently. You would not keep your logging level as a secret for example
If one keeps actual production secrets in .env files, that is indeed very very noob move. Then there are things as Laravel which seem to just use .env as some sort of .ini file.
I know the difference between local and production. If you read my article, I say myself
.envvariables are useful for local / development oriented environments and I was specifically talking about production.I knew there was a disconnect! Nice conversation, you seem very passionate.
You are focusing on specific case, i.e. production (or third party access) secrets, as if that's the only use case for .env files, and as if secrets are the only env vars your app needs on production. Are you really going to keep everything in a sealed secret or a vault server of some kind?
To quote you - "What I'm trying to say is don't store valuable secrets in simple files"
Not sure why do you think people do. There is nothing secret or valuable on placeholder password for local development, or most env vars.
Just because I'm focusing on one use-case doesn't mean I'm saying thats the only use-case.
Maybe I'm not being clear? Again, I mention .env are useful for development oriented environments which excludes my points from those environments. Development oriented environments including local.
So with other words, "continue using .env files as usual" i.e. not for keeping production secrets, which you probably don't have access to anyway. Glad we agree, lol
Yeah lol Iβd phrase it as βkeep using .env not for production and only if your using them right as usualβ.
We were going in a big circle. I should have made by target audience clearer which I feel is the biggest issue people have not my article itself.
Nice chat your passionate, glad we could talk!
Offline on-prem self-hosted exists in 2022 btw.
Can we all agree on one thing? That there should definitely be a
.gitignorefile in every repo with atleast this content:From a dev perspective thats the only thing that matters anyways =p
For the sake of argument, not really (though I personally always do, because you don't want your env to be overwritten by the latest pull).
Say you have a frontend repo. If you use any secret stuff in your frontend build, it ends up baked inside your UI, and anybody using your UI can see that "secret" API token you cleverly hid from the repo:D.
If I had a dime for every UI which emits API tokens neatly in every request, but went through the trouble to hide it from every dev but the general public.
If your front requires any secrets - it probably should not.
About which part do you disagree exactly? Putting FE "secrets" (nothing in the FE is ever secret) in a .env doesn't solve the issue of the "secret" getting baked inside the FE during build.
There is no need to hide .env from repo to hide secrets, since they are public
But that's exactly where the risk/problem is... Someone on the team will interpret the .env as something where they can put local secrets (because that's what it is for) and BAM secrets are now leaked into version control and you have a problem. There's no benefit from committing .env to version control so don't do it. If you have FE "secrets" that don't change based on environment, just put them in a json file or return them through a BE api if they should change per environment.
Thank you for the points. I couldn't agree anymore.
I see a little polemic unfolding, lol :)
Thank you so much for that ππ€
It's a bunch of files
Sure, but adding an unnecessary layer of potential downtime for literally nothing is just stupid.
Reading your comments, you're clearly delusional and I doubt you have any experience. Stop misleading junior-devs.
Same for me. i also doubt if he is actually a Google employee or just trolling this platform.
Or maybe I'm just above your level of understanding that just can't comprehend it therefore it feels like trolling lol.
In JK, on a seriously note, I would love if you could give some pointers. Throwing insults isn't interesting. And wow the commenters are more interested in my work than me.
The clickbaity title is enough evidence for trolling.
Nice chat, have a nice day!
Lol yβall love taking that files quote. You donβt look at a database and say yea thatβs just files. Itβs a complex storage and retrieval system with permissions and access management like a what?? Drumrollβ¦.. like a config server ππ. Your a funny guy π€£.
Insults with no counter points isnβt very insightful. But maybe since I have no experience like you claim then I probably havenβt learned that it is π€.
Again, I admit most developers have not worked at the scale to experience the problems my article addresses. If Iβm delusion it seem your included in that group.
Plz re-read my article and donβt just free throw. Thanks!
When your first 4 paragraphs do nothing but criticize 1 sentence in another post, at least some of your readers will leave without ever getting to whatever technical content your post contains. I read the post you refer to. It was a good read that made good points, and lead to an interesting discussion in the comments.
I clicked on your post because the title implied that it would offer a counterpoint to the other. So I assumed would be just as interesting. But I won't ever know because the attitude of your first 4 paragraphs has sent me away.
You are correct. The author exaggerated a bit by criticizing this sentence. But I totally agree with him. It is wrong in all 4 directions!
Same for me!
It's a bad thing for new readers who stop reading right away, I think, because there is still a counterbalance to the referenced post.
Thanks for sharing. Bookmarked! Docker secrets look interesting, never used it before.
Excellent rebuttal to a narrow opinion previously shared here.
Recently, I began to use 1Password to store the values I normally hard code in
.envfiles so team members in my organization could more quickly get up and running, I've documented that process hereI donβt know about 1Password. From what I did see, it functions like a vault / centralized configuration utilizing the benefits I mentioned in my article. Iβm proud!!!
I am feeling a sense of irony reading your reply tho. Good job on your solution!
FWIW calling your article a narrow opinion is meant to be a constructive point of view. You do bring valid points and reasoning, but I view that .env file as just a tool in the toolbox. You just have to know what makes it the right tool for the job, and there are A BUNCH of situations where the .env file is not the right approach
I don't understand what's narrow here lol. I won't talk about how he's contradicting himself
The headline, for starters.
I wonβt deny thereβs valuable content, but the narrative did have an off-putting effect to readers.
Even though I think that you've gone a little bit too hard on the author of the other post I can't shake the feeling that clickbaity posts such as those do more harm than good since they don't elaborate in detail why that approach is lacking.
This is a great rebuttal though and now both sides of the approach can be taken into consideration.
I was sure I sent the first half listing issues and then give solutions? Was I not clear enough? Even then this article doesnβt even counter all the points I made in the original article.
I'll have a thorough read once again in that case, though I'm not for dropping the approach completely. It is a nice discussion, though!
This is a great article! Thank you for sharing your knowledge.
While this article eventually has some somewhat interesting content, it is pathetic that the author has chosen to criticize another post in such a childlike manner. The other post did not come at you personally, yet you took it that way. It's sad, honestly. @gregorygaines may be right or he may be wrong, but he has posted an article with good reasoning and points and has been very respectful in his replies. You, however, picked a fight for no reason and are now reminding everyone of their annoying little sibling. Grow up and leave the toxicity behind. One can debate interesting topics and still maintain a demeanor of respect. Good Lord.
What do you mean? The article was so formal and highly professional. Did you ever consider reading it? Or just cowardly assumptions?
I did read it, including the very beginning part, It may have some well-written parts (note where I said 'While this article eventually has some somewhat interesting content'), but it also has a an intro and several parts that sound like a snotty-nosed child said them.
Here is the thing: let's imagine you are having a good dinner at MacDonald, and out of the blue, a guy comes up to your table and tells you: "Stop Eating Tacos, or whatever, Now.". Would you be offended? Probably not. But what if they said it in an insulting, aggressive way? Then you might be offended.
This post is clearly not a personal attack or an assault on the other author. But instead of getting mad at this post, take a moment to appreciate the author's time and effort in writing such a response. This person has written nothing but facts, and it takes guts to write something like this. So kudos to him for having the courage to speak his mind.
1) I can genuinely say I don't think I understand your first paragraph.
2) Sure, it takes some guts to say anything, I suppose. Although, I don't think it takes that much guts to type something on the Internet. That aside, the post would have been great if it had just been to the point, but instead it included a level of toxicity that wasn't necessary to make the point. That is what I commented on. I love sharing ideas and learning new things - I really do, but I can also do without the toxicity that is already so prevalent elsewhere on the Internet. It'd be nice if people as smart as software developers could get rid of the ape mind and just have an academic discussion or debate without taking pot shots that don't add anything.
So that's why so many of google's applications are being taken down π jkjk.
Anyway here are my two cents:
I agree with most of it. And focus on the word "most" of it. Just the part where you make one person responsible of all the secrets and then try that person if a breach (of contract; its implied in an NDA right?) happens. But in any case, forget for a few mins you are dealing with a corporate giant who has literally an army of lawyers in their pocket to fight for them, if it were a startup or a company transitioning from startup to a medium sized company/firm/org, their reputation would've already passed through the shredder by the time they wake up and realize what has happened.
You just need to be bit by a snake to really grasp the intensity of the poison. Maybe you haven't been bitten by that snake yet.
But yes, if we forget the above point that one person is responsible for every secret, your explanation is pretty constructive and there's a lot it leaves to debate over.
A good article indeed.
And hot damn i didn't know a soldier boy has already posted an anti to this article π this community is golden!
We get taken down but at-least we not getting secrets leaked. Sounds like a win in my opinion lol.
Yes. But honestly, think about what I said. The person in charge of secrets at your corporation is afraid of life ruining legal repercussions and that's only because your legal side is so damn strong. A small to medium software house doesn't enjoy the same level of legal assurances.
Like I said, your article opens up discussions of a whole other kind. I can make a podcast on it and you'll see we'll make dozens of episode just exploring the true details behind the scenes. Over the top, .env seems a simple enough issue. The more you delve into its dark depths the more you realize.... It's really just a subjective decision by whoever makes it.
I have no hate against megacorporations. I just know for sure by experience, when you start to discuss "what they do and people should do exactly", these megacorporations are almost always years behind in the most unusal of places. And for your google, this .env can be that if you don't think everyone is criticizing you and look at both the sides of this coin.
Seems like all the better reason why this conversation needed to happen. And itβs a deep topic which is why I opened the door. I admit most people havenβt worked at the scale to notice the issues my article addresses.
No no. My dear good Sir, everyone sane, and I mean roughly 70-80% developers, even the juniors included know this issue. They ask about this shenanigan.
I literally had a trainee who asked me this question about two days ago, and why I was so excited to see your post was that I found yin and yang's of this conversation right in a single thread and gave her these articles to read and better reflect on it herself.
Like her and most others (about 6/7), they chose to stick with .env files but acknowledge the exact issues you gentlemen have laid infront of us.
This means either this thing is so well established that no matter how many better solutions you think of, they won't be enough. OR... the correct implementation of the thing is yet to be seen.
Either way, I agree with you my dude. It's not just criticism. I understand your point of reference, and I understand how you revolve around it. Im just saying that... This is a coin. And it has two very different sides with their own identity. Whether one likes it or not.
But like I said, good article. Many points to ponder over in future. This will be in my shower thoughts I promise you :p
Well put, there isn't one lie in your comment! I completely understand, I guess the rapid back-and-forth and constant insults thrown at me has had me on the defensive and for that I apologize.
I'm glad we had a chance to talk and I wish you much success.
Thanks!
You sir. Are a gem. Keep on rocking!
"all criticism is good criticism if one has the appetite for it". Let's close on this. And bid farewell until we talk again in another one of your posts ^^ /
Exactly!
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.
I don't think the debate can be qualified as "stupid." It's a real concern. A major issue is unencrypted secrets in
.env, which happens all the time.Cybercriminals exploit vulnerable instances to get credentials and progress through the different layers. It's a credible scenario.
Encryption does not equal security. Encryption equals obscurity. No matter how you encrypt your data, or where you store it, there must be a master password to decrypt everything. What happens if someone disregards other security measures? A hacker will obtain the master password. This is why passwords should be hashed instead of encrypted (but that is a whole other conversation).
BTW most hacks do not occur through code, they occur through social engineering. (yet another conversion)
What I'm getting at is, .env files are not insecure, it's your instance, server, application, or place of work that is insecure. As a dev, here are some things you should know (study cyber security for more mitigation):
Also, if you are handing your secrets over to a third party, how do you know they won't get hacked? You don't.
I beg to differ. Encryption is a layer of security. Encrypting is not like hiding something somewhere as is, hoping nobody will find it.
Does not mean anything, to me, as it does happen, just subscribe to exploitdb. So you want to take the risk just because another technique seems more popular? It does not look like a solid approach, to me.
Right, you don't. Nobody said it would fix all problems. Still better than unencrypted/hardcoded credentials.
I like how your
Problems With Centralized Config Serversis mainly around it can go down and needs internet. Ufff.Your database can go down, your docker servers can go down. Everything can go down. Should we stop using internet now and go back to DVDs ? Even DVDs can go down.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.