How to configure custom Infinispan client credentials provider

[ppetrovt]

Is it possible to configure Quarkus Infinispan Client credentials programmatically at runtime? I’m looking for functionality similar to the datasource credentials provider: credentials-provider. Specifically, I want to configure the properties quarkus.infinispan-client.username and quarkus.infinispan-client.password at runtime. A custom configuration source is not sufficient because I cannot inject my secret provider.

[quarkus-bot[bot]]

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

[karesti]

@ppetrovt A this moment, the Infinispan Client extension does not provide additional methods to override or inject configuration at runtime, beyond what is supported by Quarkus configuration. However, I'm more than happy to support any feature related to this issue for this use case. Could you please open an issue and explain your use case ?

[ppetrovt]

@karesti Thanks for the quick response, here is the issue: #50109

[radcortez]

An alternative to the Credential Provider is to use a Secret Handler:
https://quarkus.io/guides/config-secrets

[ppetrovt]

This approach suffers from the same limitation as a custom configuration source: the secret handler is instantiated via META-INF rather than being managed by the CDI container. As a result, it has no access to the DI context, so any injected dependencies (e.g., a Vault or custom secret provider) cannot be used within it.

[radcortez]

Config components should never use CDI, because it can cause circular dependencies (CDI requires configuration to start).

For this reason, we have been doing some work to remove these dependencies (also applied to the Vault source). And while the Vault Source became CDI-free, a recent PR added that dependency again, and I have to recheck it to try to remove it.

Now, a SecretHandler configuration can be read by any valid source, including Vault. Here is an example with AESGCMNoPaddingSecretKeysHandler:

vault kv put secret/myapps/vault-quickstart/config smallrye.config.secret-handler.aes-gcm-nopadding.encryption-key=6ZhuIuspOUpjW_XkJ
DQCSA

curl http://localhost:8080/config/smallrye.config.secret-handler.aes-gcm-nopadding.encryption-key
ConfigValue{name='smallrye.config.secret-handler.aes-gcm-nopadding.encryption-key', value='6ZhuIuspOUpjW_XkJDQCSA', rawValue='6ZhuIuspOUpjW_XkJDQCSA', profile='null', configSourceName='vault', configSourceOrdinal=270, configSourcePosition=4, lineNumber=-1}

ConfigValue{name='my.secret', value='1234', rawValue='${aes-gcm-nopadding::DE0qY5ty3ziqFMyj6KPKt8R_SS10dFwuc62t2ykYaE0n}', profile='null', configSourceName='PropertiesConfigSource[source=file:/Users/radcortez/Code/personal/quarkus-config-playground/target/classes/application.properties]', configSourceOrdinal=250, configSourcePosition=5, lineNumber=12}

In this case, the encryption key is stored in Vault, and the encrypted value in application.properties (it can be in any other source). The handler is capable of decrypting the key and showing its real value.

A SecretHandler may also be initialized via a SecretKeysHandlerFactory, which has access to the ConfigSourceContext to retrieve configuration from the current available sources, including Vault.

Please let me know what is missing, and I'm happy to help with it. While it is still there, our idea is to deprecate CredentialsProvider because it is something on the side of the Config system, and have something that is fully integrated.