What would you like to be added:
Add an optional field to BackendTLSPolicy that allows configuring the ALPN protocols offered by the Gateway when it originates TLS connections to a selected backend.
For example:
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
name: backend-tls-grpc
spec:
targetRefs:
- group: ""
kind: Service
name: grpc-backend
sectionName: https
validation:
hostname: grpc.example.com
wellKnownCACertificates: System
alpnProtocols:
- h2
Why this is needed:
BackendTLSPolicy currently lets application owners express how a Gateway should originate and validate TLS to a backend, including CA trust, SNI hostname, and SAN validation. It does not provide a portable way to control the ALPN list used by the Gateway as the TLS client for that backend connection.
ALPN is negotiated during the TLS handshake:
- The Gateway, acting as the TLS client, offers an ordered list of protocols.
- The backend, acting as the TLS server, selects one protocol from that list.
Some backends require specific ALPN behavior. Examples:
- gRPC backends require h2.
- legacy HTTPS backends may only support http/1.1.
- some backends behave differently depending on whether both h2 and http/1.1 are offered.
- some environments need different ALPN behavior for different backend Services or Service ports.
Envoy Gateway currently provides this through EnvoyProxy.spec.backendTLS.alpnProtocols, but that setting is global. It is not fine grained enough when different backends require different ALPN values.
What would you like to be added:
Add an optional field to
BackendTLSPolicythat allows configuring the ALPN protocols offered by the Gateway when it originates TLS connections to a selected backend.For example:
Why this is needed:
BackendTLSPolicycurrently lets application owners express how a Gateway should originate and validate TLS to a backend, including CA trust, SNI hostname, and SAN validation. It does not provide a portable way to control the ALPN list used by the Gateway as the TLS client for that backend connection.ALPN is negotiated during the TLS handshake:
Some backends require specific ALPN behavior. Examples:
Envoy Gateway currently provides this through
EnvoyProxy.spec.backendTLS.alpnProtocols, but that setting is global. It is not fine grained enough when different backends require different ALPN values.