kubernetes-sigs / kubernetes-sigs/gateway-api
Add per-backend ALPN protocol configuration to BackendTLSPolicy
- Dominant language
- Go
- Stars
- 3k
- Forks
- 789
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 45
Description
**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:
```yaml
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.
Contributor guide
Research direction
Start with the linked Gateway API GEP overview and review the BackendTLSPolicy and EnvoyProxy.spec.backendTLS.alpnProtocols references described in the issue. Compare the global Envoy Gateway behavior with the requested per-backend configuration. Done means the project has agreed on and specified an optional portable ALPN field, including its semantics and example usage.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100