Use `Credentials Provider`-like mechanism with Redis clients

[abutic]

Description

It would be nice to be able to use Credentials Provider-like mechanism (or something similar), available with DB data sources, with Redis clients/connections as well. This way, one could retrieve Redis password from some other source and then use it, without setting it in quarkus.redis.hosts configuration property.

Alternative?

Is there any way to configure Redis password programmatically and make a RedisClient used like this

    @Inject
    RedisClient redisClient;

pick it up?

[quarkus-bot[bot]]

/cc @cescoffier, @gsmet, @machi1990

[machi1990]

Description

It would be nice to be able to use Credentials Provider-like mechanism (or something similar), available with DB data sources, with Redis clients/connections as well. This way, one could retrieve Redis password from some other source and then use it, without setting it in quarkus.redis.hosts configuration property.

This is a good enhancement.

Alternative?

Is there any way to configure Redis password programmatically and make a RedisClient used like this

    @Inject
    RedisClient redisClient;

pick it up?

No, at the moment we do not have a programmatic way of configuring the Redis client. Why do you need this, can't the password be supplied per environment?

[abutic]

No, at the moment we do not have a programmatic way of configuring the Redis client. Why do you need this, can't the password be supplied per environment?

We'd like to be able to get and use a password from our sensitive data storage, without having to write it down either to application.properties, system property or environment variable. If you have any advice on how to do this, we'd really appreciate it.

[machi1990]

No, at the moment we do not have a programmatic way of configuring the Redis client. Why do you need this, can't the password be supplied per environment?

We'd like to be able to get and use a password from our sensitive data storage, without having to write it down either to application.properties, system property or environment variable. If you have any advice on how to do this, we'd really appreciate it.

Okay, having a Credentials Provider and store it somewhere like Vault just like datasources will be a useful addition. As a workaround, have you tried to supply the password via ConfigSource?

[gsmet]

I think the easiest way would be to implement it in Quarkus with the credential provider contract we already have. I don't think that would be that hard.

[abutic]

As a workaround, have you tried to supply the password via ConfigSource?

Hm, in order to get the password from a sensitive data storage, we need our custom @ApplicationScoped bean, which I think is not available for injection before ConfigSource methods get called. This could be an issue for us, but your suggestion is definitely worth investigating. Thanks!

[machi1990]

As a workaround, have you tried to supply the password via ConfigSource?

Hm, in order to get the password from a sensitive data storage, we need our custom @ApplicationScoped bean, which I think is not available for injection before ConfigSource methods get called. This could be an issue for us, but your suggestion is definitely worth investigating. Thanks!

Thanks for looking. Well then, I think the CredentialsProvider is a very good is something you really need here. I'll open a PR for this enhancement. Until then, let me know how the ConfigSource option goes.

[SebaLopez94]

Is there any documentation or example about this? Thanks

[machi1990]

Is there any documentation or example about this? Thanks

We do not have an example (we should have one).

To get you going, the host provider may look like

@ApplicationScoped
@Named("hosts-provider")
public class ExampleRedisHostProvider implements RedisHostsProvider {
    @Override
    public Set<URI> getHosts() {
        // do stuff to get the host
        String host = "redis://localhost:6379/3"
        return Collections.singleton(URI.create(host));
    }
}

and in your application.properties

quarkus.redis.hosts-provider-name=hosts-provider

[lm-gunjan]

Does this works if password is getting rotated ?

I am looking to use AWS IAM authentication for ElasticCache Redis cluster. The auth token refreshes every 15 minutes. would getHosts() get called dynamically or just once when the application loads.

[gianfett]

Does this works if password is getting rotated ?

I am looking to use AWS IAM authentication for ElasticCache Redis cluster. The auth token refreshes every 15 minutes. would getHosts() get called dynamically or just once when the application loads.

Anything on this one? In my tests getHosts() gets just called once on startup. As we would like to rotate PW e.g. every 15 minutes we would need a way to provide the Quarkus Redis Client with a new PW like every 15 minutes and/or in case of AUTH failure.

[cescoffier]

No, it doesn't work, authentication only happen once, currently.

There are some work in the sql clients to handle that case. Maybe @tsegismont knows if it can also be applied to the redis client (it's a netclient underneath)

[gianfett]

Thanks for clarification @cescoffier. And if @tsegismont would have more information on this, would be great :) Thanks!

[tsegismont]

@Ladicek do you think it would be possible to implement password rotation with the Redis client? Or would that require upstream changes?

[Ladicek]

That will be possible with Vert.x 5, which contains (or will contain, in fact) https://github.com/vert-x3/vertx-redis-client/pull/475.

[Ladicek]

Also, to be honest, all I would like to support dynamically changing on the Quarkus side is the auth. In Vert.x, one can change almost everything, as @vietj demanded, but I don't actually think that's all gonna work well 😆

[gianfett]

Thanks for getting back on this issue @Ladicek. Is there any estimate on when Vert.x 5 will be released?

[Ladicek]

That's more of a question for @cescoffier, but IIRC, Quarkus should bump to Vert.x 5 late next year.

[gianfett]

Thanks for your feedback @Ladicek

[tsegismont]

Thanks @Ladicek

[cescoffier]

We started thinking about the Vertx 5 integration. Our target is fall 2025. It might be earlier or later depending on the number of hurdles we will have to deal with.

[gianfett]

Thanks @cescoffier for the estimate.