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.
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.