Using Spring Cloud Config practically in Production on cloud?

Question

I have been reading about Spring Cloud Config server to help us move to a centralized config server on cloud. Currently, we store both config and passwords in a file to which limited people have view access in Production. I have a few questions about implementing it in actual production with the various backends that it supports:

1. FileSystem : If we use file system as the storage medium for our config on the cloud, we will need a persistent volume for it. In that case, the PV will be different for different envs. When we need to update a PV with a new config in Prod, how can it be done? (I can only think of having a container mount the PV and log into the container via bash and add/update config). Is there a different approach?

2. Git : If we have git as the storage medium and lets say we have different branches for different environments, the developer would be able to view the Prod branch and also passwords in Prod branch. Googling suggested that there is no way to restrict viewing of certain branches in Git. So how is Git helpful here? Also, connection to Git needs password / SSH key which will need to be stored in a PV (then issues with #1 are applicable again)

3. JDBC : If we have a database as the storage medium, the password to connect to the database needs to be specified in the SCCS config file - which again is not secure. We could load it from a file in the filesystem, but that would mean we need PV to store the password (then issues with #1 are applicable again). Also, how are additions/updates to configs done for Production? (If RDBMS is used, we need to connect a client and run SQL Inserts?)

4. Vault : If vault is to be used, it too will need a key / password to be store in PV (and again questions of #1)

Overall, I am not sure how SCCS can be used in an actual Production environment. If someone has implemented SCCS for Production in which their config has passwords, can you please share some insights?

Thanks,

Midhun

Answer 1

Please take a look at this part of the documentation: Encryption and Decryption . This way only the config server can encrypt/decrypt the values that are stored in the externalized configuration files. Use TLS and basic authentication so only the applications can access the decryption endpoint and it's sent securely between client & server.

In case you're running on Kubernetes (because you mentioned PVs), you can use secrets and use the values inside the secret as environment vars in your container. Create a separate namespace for the centralized config server and limit the access to the team that is managing this using RBAC . This also applies for the clients which will need to have credentials in order to access the server if you follow the basic authentication setup. Just add placeholders in the bootstrap.properties file for the URL, username and password for the config server, and you're good to go.

Another thing to consider is having multiple git repositories which both the config server and the respective teams can access. This way team A can't access the config repo of team B.

Hope that helps! :)