-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
CredentialsProvider
s in that it attempts to resolve the secret value from the configuredCredentialsProvider
duringSTATIC_INIT
.I successfully use the
CredentialsProvider
to 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 useCredentialsProvider
as 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
CredenentialsProvider
to resolve secrets from AWS SecretsManagerHowever, as a result, my application fails to initialize because the
SecretsManagerCredentialsProvider
is now required during the Quarkus OIDCOidcBuildStep
and fails with the following error:Expected behavior
CredentialsProvider
implementations 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 theCredentialsProvider
in the scope of a build step (even a RUNTIME_INIT one). More similar to howgsmet
added support for theCredentialsProvider
interface in the Quarkiverse Quarkus GitHub App Extension.Actual behavior
The application fails to initialize.
How to Reproduce?
./gradlew build
or run dev mode./gradlew quarkusDev
Output of
uname -a
orver
Darwin 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 -version
OpenJDK 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 --version
orgradlew --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
SecretsManagerClient
provided by the Quarkus Amazon Services extension and write aCredentialsProvider
implementation like this:However, you then lose the ability to easily test these resources with
@QuarkusTest
and localstack without having to manually configure theSecretsManagerClient
to point to localstackThe text was updated successfully, but these errors were encountered: