Then where do you store the configs and passwords/encryption keys of your config server? Using a config server just means you store your application database passwords (and other things) in another database, then you still need to store THAT database's password somewhere, and eventually you will need to store SOME passwords and/or encryption keys in either plain text or environment variables.
I think your entire post is basically the same as saying "when you have to manage many complex systems, don't store their production configs and passwords in files, store and manage them in another database system", which is quite valid for the ease of config versioning, sharing and access control (albeit the same goal can be achieved with file-based solutions too), however in the end you have to store some configs and passwords outside of a database system anyway.
Also if data security is really important and you want to serve sensitive data like passwords via remote APIs, maybe you should just code some simple bespoke config management solution instead of using those enormous "config server" things. I'd say with several hundred lines of code and a handful of dependencies, you should be able to have most of those particular config versioning, sharing and access control capabilities you need, and you have full control of the code that manages your extremely sensitive data, instead of trusting those config server's thousands of lines of code and hundreds of dependencies that you have no grasp of, where a bug in the code or a vulnerability in some dependency may just compromise your "secret URL" completely.
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.
Sure, build your own solution if you don't want to trust a third-party. If your config url was exposed it wouldn't matter. Most config servers are connected through VPCs which prevent internet access and can only be accessed by your servers.
Well, remote APIs are inherently less secure than local access, and using config server just means you move your sensitive data from local files to a remote database. Of course it can be less prone to human errors and much easier to use, but in the end I doubt either approach (remote database vs. local file) can be said decisively safer, it really depends on the specific situation and implementation.
I do agree if you are managing many complex production systems you should not manage configs with individual files, unless you have some good file-based config management solution in place.
But then in the end the configs and passwords for this remote database/config server thing still needs to be stored in some environment variables and/or .env files (or rc files, or whatever local config files you want to name them) anyway.
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.
When using a VPC you are essentially using local access. Yes you are moving sentive data behind permissions and access retrictions. I do however believe that .env should be used for local / development oriented enviornments like I mentioned in the article.
I guess we can agree to meet in the middle.
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.
Then where do you store the configs and passwords/encryption keys of your config server? Using a config server just means you store your application database passwords (and other things) in another database, then you still need to store THAT database's password somewhere, and eventually you will need to store SOME passwords and/or encryption keys in either plain text or environment variables.
I think your entire post is basically the same as saying "when you have to manage many complex systems, don't store their production configs and passwords in files, store and manage them in another database system", which is quite valid for the ease of config versioning, sharing and access control (albeit the same goal can be achieved with file-based solutions too), however in the end you have to store some configs and passwords outside of a database system anyway.
Also if data security is really important and you want to serve sensitive data like passwords via remote APIs, maybe you should just code some simple bespoke config management solution instead of using those enormous "config server" things. I'd say with several hundred lines of code and a handful of dependencies, you should be able to have most of those particular config versioning, sharing and access control capabilities you need, and you have full control of the code that manages your extremely sensitive data, instead of trusting those config server's thousands of lines of code and hundreds of dependencies that you have no grasp of, where a bug in the code or a vulnerability in some dependency may just compromise your "secret URL" completely.
Sure, build your own solution if you don't want to trust a third-party. If your config url was exposed it wouldn't matter. Most config servers are connected through VPCs which prevent internet access and can only be accessed by your servers.
Well, remote APIs are inherently less secure than local access, and using config server just means you move your sensitive data from local files to a remote database. Of course it can be less prone to human errors and much easier to use, but in the end I doubt either approach (remote database vs. local file) can be said decisively safer, it really depends on the specific situation and implementation.
I do agree if you are managing many complex production systems you should not manage configs with individual files, unless you have some good file-based config management solution in place.
But then in the end the configs and passwords for this remote database/config server thing still needs to be stored in some environment variables and/or .env files (or rc files, or whatever local config files you want to name them) anyway.
When using a VPC you are essentially using local access. Yes you are moving sentive data behind permissions and access retrictions. I do however believe that .env should be used for local / development oriented enviornments like I mentioned in the article.
I guess we can agree to meet in the middle.