Proxy HTTP client per cluster configuration with client certificate#386
Merged
alnikola merged 30 commits intoSep 7, 2020
Conversation
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.
HttpMessageInvoker is used by HttpProxy for forwarding requests to destinations. Currently, there is only one global HttpMessageInvoker instance shared among all clusters and destinations. This PR assigns separate instance to each of clusters and adds cluster-specific HttpMessageInvoker's configuration. The configuration also enables setting a client certificate for mutual SSL authentication between proxy and upstream destinations.
Proxy HTTP Client Configuration
Each
Clusterhas a dedicatedHttpMessageInvokerinstance used to proxy request to itsDestinations andHttMessageInvoker's configuration is defined on per cluster level. On YARP startup, allClusters get newHttpMessageInvokerinstances, however if later theClusterconfiguration gets changed a newHttpMessageInvokergets created only whenIProxyHttpClientFactorydetects a difference between an old and a new configuration affecting HTTP client parameters. The defaultProxyHttpClientFactorycreates a newHttpMessageInvokerwhen there changes eithes toProxyHttpClientOptionsor toCluster.Metadata.HTTP client configuration represented by slightly different models in the Abstractions and Configuration layers.
Configuration contract
HTTP client configuration contract consists of
Microsoft.ReverseProxy.Configuration.Contract.ProxyHttpClientOptionsandMicrosoft.ReverseProxy.Configuration.Contract.CertificateConfigOptionstypes defining the following configuration schema.Configuration settings:
AllowInvalidflag indicating whether or not an invalid certificate acceptedConfiguration example
The below example shows 2 samples of HTTP client configurations for
cluster1andcluster2.{ "Clusters": { "cluster1": { "LoadBalancing": { "Mode": "Random" }, "HttpClientOptions": { "SslProtocols": [ "Tls11", "Tls12" ], "MaxConnectionsPerServer": "10", "ValidateRemoteCertificate": "false" }, "Destinations": { "cluster1/destination1": { "Address": "https://localhost:10000/" }, "cluster1/destination2": { "Address": "http://localhost:10010/" } } }, "cluster2": { "HttpClientOptions": { "SslProtocols": [ "Tls12" ], "ClientCertificate": { "Path": "my-client-cert.pem", "KeyPath": "my-client-cert.key", "Password": "1234abc" } }, "Destinations": { "cluster2/destination1": { "Address": "https://localhost:10001/" } } } } }Configuration abstractions
HTTP client configuration abstraction represented by
Microsoft.ReverseProxy.Abstractions.ProxyHttpClientOptionsdefined as follows.Note that instead of defining certificate location as it was in
Configuration.Contract.CertificateConfigOptionsmodel, this abstract type exposes a fully contsructedX509Certificatecertificate. Conversion from the configuration contract to the abstraction model is done by aIProxyConfigProviderwhich loads a client certificate into memory.Fixes #137