Feature Request: Support user-defined :authority header for h2c gRPC ExtensionService connections #7116
Description
What this PR does / why we need it
This pull request adds first-class support for setting a user-defined :authority header when an ExtensionService communicates with its upstream over clear-text HTTP/2 (h2c).
Until now, Envoy’s gRPC client fell back to the internally generated cluster_name when the header was not explicitly configured. Because those names are not valid hostnames, upstream services that rely on virtual-host–based routing could not match the request. For TLS (h2) connections the problem could be worked around by setting spec.validation.subjectNames[0], but no equivalent existed for h2c.
See issue #6167 for background.
Design overview
| CRD | Field | Type | Default | Description |
|---|---|---|---|---|
ExtensionService |
spec.authority |
string |
empty | Overrides the :authority header for h2c connections. Ignored for h2. Must be a valid DNS host label or FQDN. |
- If
spec.authorityis non-empty andprotocol: h2c, Contour injects the value into the generated CDS/LDS as:authority. - If the field is omitted, the current fallback to
cluster_nameremains unchanged, preserving backwards compatibility.
Usage example
apiVersion: projectcontour.io/v1alpha1
kind: ExtensionService
metadata:
name: authz-grpc
spec:
protocol: h2c
authority: authz.example.com # NEW
services:
- name: authz
port: 50051Backwards compatibility
- No behavioural change for existing manifests; the new field is optional.
- In the unlikely event an operator relied on
cluster_namebeing sent, they can leavespec.authorityunset.