Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Currently TLS setup is static for most of Quarkus extensions. This becomes problematic when implementing dynamic short lived certificates. This is most often done when implementing mutual TLS aka mTLS.
Many service meshes provide mTLS support and most of them offer certificate rotation (i.e. they are short lived certificates). For our team's current use case, where we've been implementing zero trust, we are basically only using the service mesh for mTLS.
That is where this idea arises from. Quarkus has a Vault extension and Vault's PKI extension (which Quarkus also supports) is a Certificate Authority designed explicitly for short lived certificates. Wiring Vault's dynamic certificates into Quarkus solves mTLS for us without requiring a service mesh.
Proof-of-Concept
This PR provides the following changes to have a complete PoC for dynamic mTLS.
mutual-tls extension.
Adds a
mutual-tls
extension that addsMutualTLSProvider
andMutualTLSProvderFinder
, very similar to theCredentialsProvider
exposed via thecredentials
extension. Versions ofX509KeyManager
andX509TrustManager
that support dynamic certificates are provided as well.TestMutualTLSProvider
In
test-framework
a test implementation ofMutualTLSProvider
has been added. It creates a "root" and "intermediate" CA and then issues an "identity" cert for each configured/referenced mTLS provider. I've located it ittest-framework
to underscore that this can be used be any pluigin to validate support for dynamic mTLS.This could also be made into a simple server that you can request certs from; very simple and very insecure. This would allow multiple processes to test dynamic mTLS without requiring a real provider like Vault be configured.
VaultMutualTLSProvider
Vault has been moved out of core but a Vault implementation of
MutualTLSProvider
has been created based on the PKI secrets engine. Testing was originally done with this untilTestMutualTLSProvider
was created.Supporting Extensions
For this proof-of-concept support for
MutualTLSProvider
has been hacked intovertx-http
andresteasy-reactive/rest-client
. Given both those extenions are built on Vertx, it shows Vertx based extensions should be relatively easy to add support to. Other extensions should be coverted before a final design is locked.Ideas
Although I set out to solve the problem of dynamic mTLS. You can see that this is really just a TLS configuration provider and requirement that it be installed in such a way that dynamic certificates are supported. The final configuraiton only has the idea of an "identity" certificate chain and then a set of "trusted" CA certificates. This is really no more than a standard TLS configuration has.
Because the TLS configuration is centralized in the "provider" and referenced from extensions, this change might allow TLS configurations to be shared across extensions without repetition; just by creating a "file" based TLS provider.