feat: support setting multiple TLS certs for different domains on the interceptor proxy #1116
+346
−28
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.
#928 added rudimentary support for interceptor data path TLS. A major limitation is that it allows only a single cert/key pair, meaning that user must have all their domains as SANs in this single cert. In Kubernetes, this is rarely the case. Frequently each
Ingress
has a dedicated cert.This PR adds a new ENV variable
KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS
where users can define a comma-separated list of directories that will be recursively searched for any valid cert/key pairs. Currently, two naming patterns are supportedSecrets
of typetls
The matching between certs and requests is performed during the TLS ClientHello message, where the SNI service name is compared to SANs provided in each cert and the first matching cert will be used for the rest of the TLS handshake.
Checklist
docs/
directory