Ability to apply provider to 'quarkus.oidc.credentials.secret' configuration key

[rw-RobertJesionek]

The framework provides the ability to apply credentials-provider to 'quarkus.datasource' configuration key. It works great if developer decides to store sensitive data in the key vault.

It would be great if the Open ID Connect extension supported similar feature, that could be leveraged if developer prefers to store oidc's credential secret in the vault, too.

[quarkus-bot]

/cc @pedroigor, @sberyozkin

[sberyozkin]

I wonder if a property initialization like this one can work:

my.secret=secret_from_vault
quarkus.oidc.credential.secret=${my.secret}

@vsevel Hi Vincent, I recall we were talking awhile back about something similar ? Also CC @radcortez

[vsevel]

it is more:

quarkus.vault.secret-config-kv-path=path/in/vault
...
quarkus.oidc.credential.secret=${my.secret}

with path/in/vault containing key my.secret
the only thing that is not supported is the Credentials Povider approach. this means that you can not use a store that is not accessible through the MP config source approach. but the vault being also a config source, you can definitely fetch the password from the vault as you have shown.

but yes it works. there is nothing specific here. is this what you mean?

[sberyozkin]

@vsevel thanks Vincent; I see, yes, in this specific case getting my.secret as you have shown should be sufficient as the issue is about fetching it from Vault.
@robertjesionek can you please try something similar to what @vsevel typed above ?
thanks

[rw-RobertJesionek]

That does not work for me. I do not use a built-in vault extension. I am interacting with Azure Key Vault through their dedicated Java SDK: https://docs.microsoft.com/en-us/azure/key-vault/secrets/quick-create-java

[vsevel]

there are 2 solutions:

1. implement the credentials provider pattern for the azure key vault (as a quarkus extension, or an app specific module) and support it in the oidc extension
2. implement an azure key vault config source

[sberyozkin]

@robertjesionek I see; I'm pretty sure I've seen a blog post somewhere showing how the Azure key Vault values can be exposed as MP configuration properties, using a custom ConfigSource. CC @radcortez Hi Roberto - do you recall seeing it ?

[sberyozkin]

@robertjesionek see https://github.com/Azure/azure-microprofile/tree/master/microprofile-config-keyvault

[sberyozkin]

Hi @robertjesionek @vsevel Sure, I'll keep this issue open even if ConfigSource is confirmed to work as I agree going forward it would be useful for quarkus-oidc users to have CredentialsProvider checked; I can't prioritize on it now though so hopefully the ConfigSource approach will do well in the short/medium term

[radcortez]

@robertjesionek I see; I'm pretty sure I've seen a blog post somewhere showing how the Azure key Vault values can be exposed as MP configuration properties, using a custom ConfigSource. CC @radcortez Hi Roberto - do you recall seeing it ?

I guess you find it? :)

[sberyozkin]

Sorry @radcortez I meant to react with a smiley but chose a confused one by mistake :-), re-reacted with thumb up :-)

[rw-RobertJesionek]

FYI https://github.com/Azure/azure-microprofile/tree/master/microprofile-config-keyvault does not work.
But found a 1 liner workaround:

System.setProperty("quarkus.oidc.credentials.secret", secretClient.getSecret("secretKey"));