What would you like to be added:
I'd like to bundle three related changes together as part of a broader effort to enable Backend mTLS configuration:
Configuration for the client certificate Gateways should use when connecting to Backends
Ability to specify SANs on BackendTLSPolicy
Add TLS options to BackendTLSPolicy to mirror TLS config on Gateways
Of those, 2 may not seem quite as obvious as the rest. The rationale is that SPIFFE is very commonly used as part of mTLS, and is not compatible with our current requirement that the cert served by the backend must match the SNI used to connect to the backend. Adding the option to separately specify SANs would also enable the use of SPIFFE IDs with BackendTLSPolicy.
All of Envoy, HAProxy, and NGINX should be able to support these capabilities, but there will be some nuance in terms of where the configuration lives.
Why this is needed:
One of the core goals for Gateway API is to provide more secure capabilities than Ingress. This feature would finally allow backend mTLS to be configured natively within Kubernetes APIs, and would likely provide opportunities for closer integration between ingress-focused implementations of this API and mesh-focused implementations.
What would you like to be added: I'd like to bundle three related changes together as part of a broader effort to enable Backend mTLS configuration:
Of those, 2 may not seem quite as obvious as the rest. The rationale is that SPIFFE is very commonly used as part of mTLS, and is not compatible with our current requirement that the cert served by the backend must match the SNI used to connect to the backend. Adding the option to separately specify SANs would also enable the use of SPIFFE IDs with BackendTLSPolicy.
All of Envoy, HAProxy, and NGINX should be able to support these capabilities, but there will be some nuance in terms of where the configuration lives.
Why this is needed: One of the core goals for Gateway API is to provide more secure capabilities than Ingress. This feature would finally allow backend mTLS to be configured natively within Kubernetes APIs, and would likely provide opportunities for closer integration between ingress-focused implementations of this API and mesh-focused implementations.