Add Infinispan secret credential processing

[noelo]

Description
When deploying Infinispan via the Infinispan Operator the user credentials are stored in a yaml format in a secret. Currently there is no easy way by which to consume this secret and populate the quarkus.infinispan-client.auth-username
& quarkus.infinispan-client.auth-password properties.

Implementation ideas
Load the secret at startup and parse the payload when initialising the infinispan client. Configure the password based on the user name passed in via the quarkus.infinispan-client.auth-username. Skip using the secret if the quarkus.infinispan-client.auth-password property is set.

e.g.
quarkus.infinispan-client.auth-username=developer
quarkus.infinispan-client.credentialsecret=infinispan-auth-secret

Secret processing can be done via the existing Quarkus secret processing e.g.
quarkus.openshift.secret-volumes.infinispan-auth-secret.secret-name=cache-generated-secret

[quarkusbot]

/cc @karesti, @wburns

[karesti]

@ryanemerson any thoughts as well about this?

[karesti]

@noelo I created an issue to see what we can do https://issues.redhat.com/browse/ISPN-13149

[ryanemerson]

Autogenerating the password sounds good to me.

One thing to consider, is that the Infinispan cluster and it's associated secret maybe in a different namespace to the client app, so we would require an additional property to configure the namespace of the cluster.

However, instead of just providing a property for the secret, we should provide a generic way to configure details of the Infinispan CR via properties. That way the client has enough information to process the credentials as well as perform other auto-config, e.g. automatically configured the HotRod url.

We could add the following two properties to support this:

quarkus.infinispan-client.cluster-name=<infinispan cr name>
quarkus.infinispan-client.cluster-namespace=<infinispan cr namespace>

The secret used to store the user credentials can then be obtained by the Client by parsing the Infinispan CR spec.

[karesti]

@ryanemerson which is the status here ?

[ryanemerson]

Instead of creating our own custom credentials integration, we should leverage ServiceBindings here.

It's necessary for the Infinispan Operator to expose the ServiceBinding Secret containing the cluster connection details infinispan/infinispan-operator#1725. As well as for the Infinispan client extension to support configuration via a ServiceBinding (karesti#1).

It will then be possible for the Quarkus service binding extension to automatically generate the ServiceBinding k8s resource as shown here.

[karesti]

I created a PR just now #30268

[karesti]

@ryanemerson does the PR merged close this issue?

[ryanemerson]

I don't think anything else is required on the Quarkus side of things, however infinispan/infinispan-operator#1725 is still needed in the Operator.

[karesti]

Can we close this issue then?