https://github.com/kedacore/http-add-on/pull/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 supported
XYZ.crt + XYZ.key - this is a convention when using Kubernetes Secrets of type tls
XYZ.pem + XYZ-key.pem
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
[x] Commits are signed with Developer Certificate of Origin (DCO)
https://github.com/kedacore/http-add-on/pull/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
Ingresshas a dedicated cert.This PR adds a new ENV variable
KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHSwhere 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 supportedSecretsof typetlsThe 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