Quarkus OIDC CredentialsProvider integration resolves secrets during BuildStep #41223
Comments
|
/cc @pedroigor (oidc), @sberyozkin (oidc) |
|
Adding some more context here, I tried out a local build of quarkus that added the I think this means that in order for the Quarkus OIDC extension to support |
|
I was able to demonstrate how one might workaround this issue by deferring secret access to outside of the build step.I think this deferral is ideal for long-running applications that might have short-lived credentials accessed via a Basically, finding usages of I was able to confirm that a local build of my branch linked above will pass the initialization test of the reproducer repository https://github.com/ryandens/quarkus-oidc-secrets-manager by using the maven local quarkus release @sberyozkin, do you think a change that looks something like this might be one you'd be willing to accept? If not, do you have suggestions for users who want to have a Quarkus |
|
I am going to have a look. I cannot tell whether main...ryandens:quarkus:ryandens/41223/oidc-client-secret is a good solution without trying to figure it out myself. Sure, it might end-up same + tests. Let's see. |
|
Thanks @michalvavrik, @ryandens |
|
Thanks for investigating and fixing this! I definitely agree the solution merged makes a lot more sense than the hack/workaround provided by me. |
Describe the bug
The Quarkus OIDC Extension appears to deviate from norms that I've observed in other extensions that have support for
CredentialsProviders in that it attempts to resolve the secret value from the configuredCredentialsProviderduringSTATIC_INIT.I successfully use the
CredentialsProviderto provide credentials to various Quarkus extensions (such as the data source extension and the Quarkiverse GitHub App Extension). I store secrets for these extensions in AWS Secrets Manager and useCredentialsProvideras a bridge to provide these extensions with values from AWS Secrets Manager. To do this, I leverage the Quarkiverse Amazon Services Secrets Manager Client extension. This provides my application with aSecretsManagerClient.I recently tried to adopt the Quarkus OIDC extension and use the same pattern for safely storing and accessing secrets that this OIDC extension needs at runtime in order to validate users from OIDC providers.
I configured by application with the my desired OIDC provider, client ID, and client secret provider/key.
I then leveraged by previous pattern of using a
CredenentialsProviderto resolve secrets from AWS SecretsManagerHowever, as a result, my application fails to initialize because the
SecretsManagerCredentialsProvideris now required during the Quarkus OIDCOidcBuildStepand fails with the following error:Expected behavior
CredentialsProviderimplementations can leverage beans produced by other Quarkus extensions, especially theSecretsManagerClient, which is a pretty ideal bean to use in aCredentialsProvider.It might be possible to resolve this issue using the
SyntheticBeansRuntimeInitBuildItem, but I think in practice the config validation that happens during this build step should not resolve the value from theCredentialsProviderin the scope of a build step (even a RUNTIME_INIT one). More similar to howgsmetadded support for theCredentialsProviderinterface in the Quarkiverse Quarkus GitHub App Extension.Actual behavior
The application fails to initialize.
How to Reproduce?
./gradlew buildor run dev mode./gradlew quarkusDevOutput of
uname -aorverDarwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020 arm64
Output of
java -versionOpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS)
Quarkus version or git rev
3.11.2
Build tool (ie. output of
mvnw --versionorgradlew --version)Gradle 8.7
Additional information
https://scans.gradle.com/s/5vyysmt4kfphi
If anyone else encounters this issue and is interested in a workaround, you can simply not use the
SecretsManagerClientprovided by the Quarkus Amazon Services extension and write aCredentialsProviderimplementation like this:However, you then lose the ability to easily test these resources with
@QuarkusTestand localstack without having to manually configure theSecretsManagerClientto point to localstackThe text was updated successfully, but these errors were encountered: