-
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
Integrate Vertx HTTP with CredentialsProvider #26380
Integrate Vertx HTTP with CredentialsProvider #26380
Conversation
This comment has been minimized.
This comment has been minimized.
...nsions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/VertxHttpRecorder.java
Show resolved
Hide resolved
Map<String, String> credentials = Map.of(); | ||
if (sslConfig.certificate.credentialsProvider.isPresent()) { | ||
String beanName = sslConfig.certificate.credentialsProviderName.orElse(null); | ||
CredentialsProvider credentialsProvider = CredentialsProviderFinder.find(beanName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this lookup work? Is it using @Identifier
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks for the named beans such as this one, this pattern of checking it is used across various Quarkus extensions. This name does not have to be specified if there is only one bean, that look up code will return the single bean it will find, only needed if several different providers are used.
Once the provider is found, the string (such as custom
used in this PR's test) is passed to the found provider to return the credentials, it is not used here, but in Quarkus File Vault it will identify the keystore where to get the secrets from: https://quarkiverse.github.io/quarkiverse-docs/quarkus-file-vault/dev/index.html#_how_to_use_the_extension, for example:
quarkus.datasource.credentials-provider=quarkus.file.vault.provider.db1
quarkus.file.vault.provider.db1.path=dbpasswords.p12
quarkus.file.vault.provider.db1.secret=storepassword
quarkus.file.vault.provider.db1.alias=quarkus_test
So here Agroal will pass quarkus.file.vault.provider.db1
to the provider which will figure out that db1
is a keystore tag, and use its db1
configuration to get the data, etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cescoffier Sure; @Named
would only come into effect if there are more than one CredentialsProvider
loaded, with a single one it make no difference. Not sure we can change that though as a few such providers use @Named
(the one in quarkus-vault
for example)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cescoffier Sure; @Named
would only come into effect if there are more than one CredentialsProvider
loaded, with a single one it makes no difference. Not sure we can change that though as a few such providers use @Named
(the one in quarkus-vault
(the one based aroiund HashiCorp Vault) and also quarkus-file-vault
, but there could be custom ones too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it is not something that we can do in this PR, right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cescoffier @mkouba As far as this PR is concerned, I can make a credentials-provider-name
property not optional but required if you are concerned about a random provider being picked up, it will ensure that only a provider with a matching Named
value will be picked up.
I think the actual CredentialsProvider
resolution logic update is out of scope for this PR as many extensions depend on it (making the credentials-provider-name
required for all those extensions can be the 1st step forward), changing it willbe a breaking change and will make this PR non-backportable if it will have to be backported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cescoffier I've noticed you've approved, thanks, but your concern about @Named
is noted for sure. As I said, I can enforce at the vertx-http level that credentials-provider-name
is required, however, I'm having a 2nd thought about it now, if CredentialsProvider
resolution logic will indeed get changed in the future then having credentials-provider-name
explicitly required may make it harder to migrate.
Perhaps a reasonable compromise is to recommend in JavaDocs of this property that it should be used, will do it now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pushed a JavaDoc update recommending to use the name property all the time
04c7a4d
to
80c837e
Compare
This comment has been minimized.
This comment has been minimized.
80c837e
to
8f2f633
Compare
Failing Jobs - Building 8f2f633
Full information is available in the Build summary check run. Failures⚙️ Gradle Tests - JDK 11 Windows #- Failing: integration-tests/gradle
📦 integration-tests/gradle✖
⚙️ JVM Tests - JDK 11 Windows #- Failing: extensions/mongodb-client/deployment
! Skipped: extensions/liquibase-mongodb/deployment extensions/panache/mongodb-panache-common/deployment extensions/panache/mongodb-panache-kotlin/deployment and 8 more 📦 extensions/mongodb-client/deployment✖
|
@cescoffier Let me go ahead with the merge then, we can tune a few things for sure as needed. Please open an issue dedicated to changing |
Given we already released 2.13, @rsvoboda and I don't think it's a good idea to backport it to 2.7 given it's a new feature. |
Fixes #26344.
This PR makes it possible to retrieve Vertx HTTP SSL keystore, keystore key and truststore passwords from
CredentialsProvider
.Using
ConfigSource
is possible right now, however some users/customers don't like the idea of providing the secrets viaConfigSource
, so integrating it withCredentialsProvider
provides for aConfigSource
-like solution but viaCrdentialsProvider
.CredentialsProvider
was originally meant to return a (DB) password only, now also can return a user name, but it returns a Map so returning other secrets which, in case of the keystore, can be considered as admin credentails, is also possible.For example, after this PR we can advise the users/customers that they can intergrate
quarkus-vertx-http
with https://github.com/quarkiverse/quarkus-file-vault/.HashiCorp Vault
CredentialsProvider
will need to be expanded a bit to be able to return not only the username and password but more custom properties