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 don't see a service in a VPC generating a wait time more than a few milliseconds unless there was an issue with the underlying service itself.
Unless you have an application vulnerability, data in application memory is safe, unlike .env. If an attacker gets access to the host machine, then they could just read our the system environment variables for the .env.
Also you gotta remember, environment variables are global to that machine unlike the application runtime.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
If an attacker gets access to the host machine you have bigger problems than passwords in environment variables.
To access secrets from another server you need some authorization and/or authentication. You can use source IP address restrictions and/or username/password but you anyway have to store it on the application server.
You gained nothing because if an attacker has access to the host machine he's able to read the secrets anyways.
The only thing you did was to add additional latency and SPoF and security vulnerability to the whole solution.
It seems to me you don't exactly know how .env files work.
.env files are owned by superuser (root). When the container is starting they are read into environment variables after which privileges are dropped to regular application user that starts your application/application server. There's no way to read .env files from the filesystem after your container has started unless you gain shell access to the container and then root access. But as I said, when this happens you have bigger problems than that...
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.
Think about the log4j vulnerability. The main exploit was reading environment variables. If a config server was used, you wouldn't have had much worry about environment variables getting leaked. An extra layer for extra security.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Log4j has no root access unless your application code is running as root, which in and of itself is pretty stupid idea. Also exposing DB server to public is kind of stupid. If you follow basic security rules you can happily share your DB username and password on twitter.
I guess you also store JWT secrets in config server and SSL certificate private key as well? Let's make your applications unnecessarily slow on per-request basis for no added benefit.
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.
No addded benefit, let's ignore a centralized store for your teams to easily share and update configs, or the benefit of secret rotations, and so forth.
Unnecessarily slow? If adding a config server made your application slow then it's more your fault and your application was most likely already slow to begin with.
I also mention that config servers are usually access through VPCs which throws the arguments of "performance" out the window.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Chances are, you 99.5% already have a CI/CD server.
CI/CD servers generating .env files are already centralized.
CI/CD servers provide centralized, AAA protected access to secrets.
CI/CD servers do not require your applications to query multiple secrets on each request over network.
I see only drawbacks, no advantages over CI/CD.
Less latency, less dependencies, less maintenance, less security = profit.
If you claim VPC connected services are fast then I don't see why people are going crazy over memcached and Redis. Am I missing something?
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.
TBH you probably are. In the cloud world Redis / Elastic Cache / Memcache are used HEAVILY. When I worked at AWS, having a cache in-front of an api that would get get 1m+ times saves 100k in computational power. It's very important, and can use VPC endpoints as the icing on the cake. An yes VPC no network requests.
No drawbacks, when you have thousands of applications deployed across multiple regions, you can change a single config and have all your applications pick them up on restart without having to rebuild.
Automatic secret rotation for more security.
If you only see drawbacks thats fine.
Most developers here aren't / haven't worked at the scale to notice the issues my article addresses.
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 see a service in a VPC generating a wait time more than a few milliseconds unless there was an issue with the underlying service itself.
Unless you have an application vulnerability, data in application memory is safe, unlike
.env. If an attacker gets access to the host machine, then they could just read our the system environment variables for the.env.Also you gotta remember, environment variables are global to that machine unlike the application runtime.
If an attacker gets access to the host machine you have bigger problems than passwords in environment variables.
To access secrets from another server you need some authorization and/or authentication. You can use source IP address restrictions and/or username/password but you anyway have to store it on the application server.
You gained nothing because if an attacker has access to the host machine he's able to read the secrets anyways.
The only thing you did was to add additional latency and SPoF and security vulnerability to the whole solution.
It seems to me you don't exactly know how .env files work.
.env files are owned by superuser (root). When the container is starting they are read into environment variables after which privileges are dropped to regular application user that starts your application/application server. There's no way to read .env files from the filesystem after your container has started unless you gain shell access to the container and then root access. But as I said, when this happens you have bigger problems than that...
Think about the log4j vulnerability. The main exploit was reading environment variables. If a config server was used, you wouldn't have had much worry about environment variables getting leaked. An extra layer for extra security.
Log4j has no root access unless your application code is running as root, which in and of itself is pretty stupid idea. Also exposing DB server to public is kind of stupid. If you follow basic security rules you can happily share your DB username and password on twitter.
I guess you also store JWT secrets in config server and SSL certificate private key as well? Let's make your applications unnecessarily slow on per-request basis for no added benefit.
Not sure of how much you read?
No addded benefit, let's ignore a centralized store for your teams to easily share and update configs, or the benefit of secret rotations, and so forth.
Unnecessarily slow? If adding a config server made your application slow then it's more your fault and your application was most likely already slow to begin with.
I also mention that config servers are usually access through VPCs which throws the arguments of "performance" out the window.
Chances are, you 99.5% already have a CI/CD server.
CI/CD servers generating .env files are already centralized.
CI/CD servers provide centralized, AAA protected access to secrets.
CI/CD servers do not require your applications to query multiple secrets on each request over network.
I see only drawbacks, no advantages over CI/CD.
Less latency, less dependencies, less maintenance, less security = profit.
If you claim VPC connected services are fast then I don't see why people are going crazy over memcached and Redis. Am I missing something?
TBH you probably are. In the cloud world Redis / Elastic Cache / Memcache are used HEAVILY. When I worked at AWS, having a cache in-front of an api that would get get 1m+ times saves 100k in computational power. It's very important, and can use VPC endpoints as the icing on the cake. An yes VPC no network requests.
No drawbacks, when you have thousands of applications deployed across multiple regions, you can change a single config and have all your applications pick them up on restart without having to rebuild.
Automatic secret rotation for more security.
If you only see drawbacks thats fine.
Most developers here aren't / haven't worked at the scale to notice the issues my article addresses.