[suggestion] Having a Config server ?

[cmoulliard]

Suggestion/Requirement

As you know Spring Boot projets/customers use intensively a Config server to set up the configurations of the "microservices"(https://spring.io/projects/spring-cloud-config). We don't propose such a config server for the runtime microservices deployed on k8s/ocp but I think that it could help us to better support our strategy and could also offer for the customers an environment they will trust, will use, will help them to manage configs of the microservices against DEV, TEST, PROD, ... environments, to encrypt/decrypt content (https://www.springcloud.io/post/2022-03/spring-cloud-config-server-encryption-and-decryption/#gsc.tab=0), etc.

The reason why I'm thinking about the SCCServer is because it could also help us to simplify the process which has been designed around the Service Binding Operator to push the data (URL and credentials) coming from a claim request (= I want to access mysql/8, I want to access kafka, ....) of a microservice into the SCC instead of having to mount a secret (= base64 string which is not secure at all) to the volume of the pod, to change the RBAC for every new type of service to be access, etc.

The dev/user will have to do 2 things:

• Create a Claim containing the information expressing the backend service they would like to access (= MySQL/8, Postgresql/11, etc)
• Add as new lib the Quarkus or SB or EAP Cloud Config lib + address of the config server
• As soon as the claim has been processed by the platform and if a service exists/match, then the URL to access the backend service is added for that claim within the SCC server
• When the microservice starts locally or as pod/job, then the client cloud lib will fetch from the SCC the URL to access the backend service (= to build a datasource,...) according to the profile: DEV, TEST, PROD

Remark: If we develop a Java Application Service, the process to enrich the microservice (= adding and configuring the SCC server lib) could be done bu the platform :-)

WDYT ?

[iocanel]

Mounting a volume or a secret is the simplest possible approach one can use. It does not require additional containers to run and it's the only part in the service bidning story that is solid.

I don't see how adding an additonal moving part (the config server) simplifies things.

[cmoulliard]

Mounting a volume or a secret is the simplest possible approach one can use. It does not require additional containers to run and it's the only part in the service bidning story that is solid.

This is not so simple as you could imagine as it implies that an application/controller having the proper role, which is also aware about what is the target k8s resource (deployment, knative serving, ...) can mount a secret (= base84 string which is not not at all secure).

[cmoulliard]

I don't see how adding an additonal moving part (the config server) simplifies things.

• That simplifies many things as it not needed anymore to grant RBAC for an operator or controller on the platform to access the target reosurces like also the services from where the secret could be discovered
• We don't have to rely anymore on a k8s resource able to produce a secret as the URL + credentials could be managed independently of the ServiceBinding operator as we just need to have a mechanism able to get the URL of the backing service to access and credential needed for an application to access the backing service using datasource, ...
• Ops engineers can, from one place, manage/view the application consuming the different backing services and potentially can revoke, ...
• Platform engineers can register the services to be accessed/used by the microservices
• etc

[cmoulliard]

We had a discussion with Raffaele Spazzoli yesterday on Assemble google chat. His position is that the way to go should be to use k8s-etcd and configMap/Secret (+ GitOps to deploy on different environments) instead of a SCC server.

While I'm not opposite, such approach will bring some limitations as by example:

1. Using secrets deployed by ArgoCD (or any other tool) is more static vs the dynamic behaviour that we observe as microservice, most often, can request to access a service when they want during the process to create/deploy a workload. What I mean here is that currently the microservices can be deploy and binding be managed separately and later
2. etcd AFAIK is not multitenant and will require that secret/configMap are copied to the different target environments (= clusters).
3. If we adopt the GitOps approach, are we sure that the Ops engineers in charge of the PROD environments will accept to copy secrets from TEST to PROD or will they impose to re-create them on PROD cluster
4. The security around sensitive data as user/pwd to access a backing service is also a point that we should not "underestimate" as a secret is just a base64 string that every user having READ access to a namespace will be able to read
5. For cluster-scoped service, it will be needed to copy the secret to the different namespaces. While this is technically possible, that could generate more admin tasks or the Ops engineers

@iocanel @Sgitario @aureamunoz