Personally I don’t want my secrets being stored in a glorified text file.
So you store them at an external company? What if they are down, or have a data breach? (They are a bigger target than most of the websites). I'd like control over my secrets and not be dependent on third parties for such important stuff, and storing them in a .env is perfectly fine with the precautions and correct configuration mentioned by @ravavyr
Also, those services are not free. True, you can self-host HashiCorp Vault, but that costs also money.
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.
True, nothing is full proof. But that's why we choose techniques or companies that gives us the best guarantees.
Also no matter how secure you keep that .env file, you are giving someone FULL view of all secrets whenever its updated.
The services I listed have free tiers. HashiCorp can be self hosted for free forever, Google Cloud has a free tier for 6 secrets, AWS has a generous free tier for storing configs in parameter store.
If you don't want to go with an external company and want full control over your secrets, thats fine. There are free, open-source, or self-hosted alternatives. There's Spring Cloud Config, Github Secrets (if you trust the company enough), or roll your own.
I think the point that @tristan is making rather well is that your recommendation is just increase the surface area of your vulnerable systems.
The mindset that doesn't even trust employees with private information would deem providing that information to a third party (especially a faceless tech company) to be less secure than, keeping it contained within a closed system that is completely under their control.
The arguments you're offering for using a third party to host private information are actually the arguments against using such services. They are the weak points: If a system is compromised, it's almost certainly due to leaky abstractions like this...
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's an increase in surface area, but with the benefits I listed above.
Its not distrusting employees, it's being safe and following a secure practice. I don't know about faceless companies, I mentioned Google, AWS (which is the leading in the market for cloud) and other credible companies which provide a config service. I may be a little bias since I am a Google employee.
And if thats the case, why trust anything? Why host private code on Github or deploy on Digital Ocean? Its for the ease and guarantee.
I also mentioned open source config servers that you can host or deploy yourself.
If a system is compromised, most likely its from using bad practices...
DigitalOcean with firewall configurations is the problem solver. Only SSH works on my IP and only Cloudflare can access the HTTP directly. My name literally says "trust me".
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 could very well say let's use Github/DigitalOcean for secrets and containers, but I work by myself and I have one project that runs about 20 servers (API's, webhooks, crons, etc.) with each having different slightly different .env's. I code in Rust instead of PHP or JS in the backend, so I'm more concerned with supervisor's configuration more than the actual env.
@tristan If you're having serious infrastructure you're already relying on external providers (whether it's AWS, GCP or Azure) so using different service for secrets doesn't make much difference.
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.
So you store them at an external company? What if they are down, or have a data breach? (They are a bigger target than most of the websites). I'd like control over my secrets and not be dependent on third parties for such important stuff, and storing them in a
.envis perfectly fine with the precautions and correct configuration mentioned by @ravavyrAlso, those services are not free. True, you can self-host HashiCorp Vault, but that costs also money.
True, nothing is full proof. But that's why we choose techniques or companies that gives us the best guarantees.
Also no matter how secure you keep that
.envfile, you are giving someone FULL view of all secrets whenever its updated.The services I listed have free tiers. HashiCorp can be self hosted for free forever, Google Cloud has a free tier for 6 secrets, AWS has a generous free tier for storing configs in parameter store.
If you don't want to go with an external company and want full control over your secrets, thats fine. There are free, open-source, or self-hosted alternatives. There's Spring Cloud Config, Github Secrets (if you trust the company enough), or roll your own.
I think the point that @tristan is making rather well is that your recommendation is just increase the surface area of your vulnerable systems.
The mindset that doesn't even trust employees with private information would deem providing that information to a third party (especially a faceless tech company) to be less secure than, keeping it contained within a closed system that is completely under their control.
The arguments you're offering for using a third party to host private information are actually the arguments against using such services. They are the weak points: If a system is compromised, it's almost certainly due to leaky abstractions like this...
It's an increase in surface area, but with the benefits I listed above.
Its not distrusting employees, it's being safe and following a secure practice. I don't know about faceless companies, I mentioned Google, AWS (which is the leading in the market for cloud) and other credible companies which provide a config service. I may be a little bias since I am a Google employee.
And if thats the case, why trust anything? Why host private code on Github or deploy on Digital Ocean? Its for the ease and guarantee.
I also mentioned open source config servers that you can host or deploy yourself.
If a system is compromised, most likely its from using bad practices...
DigitalOcean with firewall configurations is the problem solver. Only SSH works on my IP and only Cloudflare can access the HTTP directly. My name literally says "trust me".
What happens if your service expands and you have to share common secrets across different teams?
Do you just copy and past the file or use a centralized config?
I could very well say let's use Github/DigitalOcean for secrets and containers, but I work by myself and I have one project that runs about 20 servers (API's, webhooks, crons, etc.) with each having different slightly different .env's. I code in Rust instead of PHP or JS in the backend, so I'm more concerned with supervisor's configuration more than the actual env.
@tristan If you're having serious infrastructure you're already relying on external providers (whether it's AWS, GCP or Azure) so using different service for secrets doesn't make much difference.