Credentials provider for Infinispan clients

[ppetrovt]

Description

As mentioned by @karesti in this discussion, there is currently no way to provide Infinispan credentials programmatically at runtime. We need this functionality to support a custom secret provider, similar to Vault, which relies on dependency injection. I suggest adding support for a credentials provider for Infinispan, similar to the one available for datasources: Quarkus Credentials Provider.

Implementation ideas

@ApplicationScoped
@Unremovable
@Named("custom-credentials-provider")
public class CustomCredentialsProvider implements InfinispanCredentialsProvider {

    @Inject
    ISecretProvider secretProvider;

    @Override
    public Map<String, String> getCredentials(String credentialsProviderName) {
        String username = secretProvider.get("INFINISPAN_USERNAME");
        String password = secretProvider.get("INFINISPAN_PASSWORD");

        return Map.of(
                USER_PROPERTY_NAME, username,
                PASSWORD_PROPERTY_NAME, password);
    }
}

quarkus.infinispan-client.credentials-provider=custom-credentials-provider

[quarkus-bot]

/cc @karesti (infinispan), @wburns (infinispan)

[karesti]

@geoand @cescoffier WDYT ?

[geoand]

It's a good idea IMHO

[gsmet]

Yeah, ideally, we should reuse the common CredentialsProvider interface.

[cescoffier]

Yes, we need to use the Quarkus credential provider. @tsegismont is making it async at the moment.

[tsegismont]

Yes, we need to use the Quarkus credential provider. @tsegismont is making it async at the moment.

#50047

[karesti]

Hey @radcortez maybe your insights should land here too, please

[radcortez]

Sure.

I'm doing some work to support this out of the box in the Config system. We already support SecretKeysHandler, which allows you to provide a way to decode / decrypt configuration values:
https://smallrye.io/smallrye-config/Latest/config/secret-keys/#jasypt

Recently, we merged a new feature to allow us to identify which types in the Config system are considered secrets (Secret<T>):
smallrye/smallrye-config#1232

This would allow us to do some interesting things, like:

• Exclude secrets from config names
• Lock access to secret values
• Report secrets defined in "unsafe" sources
• Report secret values defined as plain strings

The next step is to go over our configuration and start wrapping Secret in the appropriate places, which can also be changed to use other specific types that better represent the secret (instead of a plain String). The current CredentialsProvider can just become a simple Converter, which will integrate seamlessly with our config objects, or use the programmatic API.

Obviously, there are some gaps and still a lot of work to do.

See also: #50107 (reply in thread)

[tsegismont]

Hi @radcortez , CredentialsProvider cannot be come a simple converter because, whenever an extension need to authenticate during the application lifetime, the provider may perform complex tasks like contacting a remote server.

But there could be a simple CredentialsProvider implementation that converts a secret