Dynamic Mutual TLS #22094
Closed
Dynamic Mutual TLS #22094
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
### MutualTLSProvider Adds a `mutual-tls` extension that adds `MutualTLSProvider` and `MutualTLSProvderFinder`, very similar. to the `CredentialsProvider` exposed via `credentials`. Some utilities for `KeyManager` and `TrustManager` are provided as well. ### TestMutualTLSProvider In `test-framework` a test implementation of `MutualTLSProvider` has been added. It creates a "root" and "intermediate" CA and then issues an "identity" cert for each configured/referenced mTLS provider. This could be made into a simple server that you can request certs from; very simple and very insecure. This would allow multiple processes to test mutual TLS 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 until `TestMutualTLSProvider` was created. ### Supporting Extensions For this proof-of-concept support for `MutualTLSProvider` has been hacked into `vertx-http` and `resteasy-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.
quarkus-bot
bot
added
area/dependencies
|
@cescoffier I read your comment over here #22182 (comment) and figured you should have look at this. I think this extensions could exactly that, see the Ideas section above. |
|
@sberyozkin Can you take some time to look at this? |
|
This looks very out of date. What should be do? |
|
If we were to support this I'll recreate the PR |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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-tlsextension that addsMutualTLSProviderandMutualTLSProvderFinder, very similar to theCredentialsProviderexposed via thecredentialsextension. Versions ofX509KeyManagerandX509TrustManagerthat support dynamic certificates are provided as well.TestMutualTLSProvider
In
test-frameworka test implementation ofMutualTLSProviderhas 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-frameworkto 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
MutualTLSProviderhas been created based on the PKI secrets engine. Testing was originally done with this untilTestMutualTLSProviderwas created.Supporting Extensions
For this proof-of-concept support for
MutualTLSProviderhas been hacked intovertx-httpandresteasy-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.