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.
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.
nearly everyone has experience working with large-scale enterprise systems.
As large as Google's? Lol. Im Jk. Nice burn tho.
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!
Funny enough, internally all secrets / configs must be stored in enterprise stores like HashiCorp Vault or Google KMS.
Who is committing an .env file to public repos?
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.
If the server updates and renames an environment variable that the app is not expecting, the app may crash on the next restart
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 the server goes offline, the app will not be able to start.
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.
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.
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 production configs 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.
Someone has to edit and see all secrets. No Matter How Trusted This Person It, It Breaks So Many Guidlines which is why Google uses config servers.
No secret rotation
No access restrictions or permissions
No audit logs, if a secret gets leak you don't know the entry point.
Probably passing secrets through email / slack
Manual file editing leads to human errors. Oops someone forgot to update one of out .env files now productions down.
—-
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 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.
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.
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.
Commit history?
Wasn't the point of a .env was that it goes in the .gitignore?
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.
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.
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 must side with Gregory here on this one. We at Intel also have to separate secrets and everything. dotenv doesn't seem a suitable candidate AT ALL. I removed all dotenv use from the React projects. wj-config allows me insertion of K8s secrets or config files while maintaining the separation between data source and consumption.
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 dotenv is loading some file and shadowing them.
Yes I agree, dotenv is some weird file configuration pretending to be env configuration. That would be pretty good example of how not to use .env file.
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.
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.
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.
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.
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.
I know the difference between local and production. If you read my article, I say myself .env variables 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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 .env files 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.
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.
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).
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.
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 :)
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.
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.
Thank you so much for that 💗🤠
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 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.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 see a little polemic unfolding, lol :)
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.
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.
Thank you for the points. I couldn't agree anymore.
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.
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.
good
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.