Gateway API 1.4: New Features
https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/
Ready to rock your Kubernetes networking? The Kubernetes SIG Network community presented the General Availability (GA) release of Gateway API (v1.4.0)! Released on October 6, 2025, version 1.4.0 reinforces the path for modern, expressive, and extensible service networking in Kubernetes.
Gateway API v1.4.0 brings three new features to the Standard channel
(Gateway API's GA release channel):
BackendTLSPolicy for TLS between gateways and backends
supportedFeatures in GatewayClass status
Named rules for Routes
and introduces three new experimental features:
Mesh resource for service mesh configuration
Default gateways to ease configuration burden
externalAuth filter for HTTPRoute
Graduations to Standard Channel
Backend TLS policy
Leads: Candace Holman, Norwin Schnyder, Katarzyna Łach
GEP-1897: BackendTLSPolicy
BackendTLSPolicy is a new Gateway API type for specifying the TLS configuration
of the connection from the Gateway to backend pod(s).
. Prior to the introduction of BackendTLSPolicy, there was no API specification
that allowed encrypted traffic on the hop from Gateway to backend.
The BackendTLSPolicy validation configuration requires a hostname. This hostname
serves two purposes. It is used as the SNI header when connecting to the backend and
for authentication, the certificate presented by the backend must match this hostname,
unless subjectAltNames is explicitly specified.
If subjectAltNames (SANs) are specified, the hostname is only used for SNI, and authentication is performed against the SANs instead. If you still need to authenticate against the hostname value in this case, you MUST add it to the subjectAltNames list.
BackendTLSPolicy validation configuration also requires either caCertificateRefs or wellKnownCACertificates.
caCertificateRefs refer to one or more (up to 8) PEM-encoded TLS certificate bundles. If there are no specific certificates to use,
then depending on your implementation, you may use wellKnownCACertificates,
set to "System" to tell the Gateway to use an implementation-specific set of trusted CA Certificates.
In this example, the BackendTLSPolicy is configured to use certificates defined in the auth-cert ConfigMap
to connect with a TLS-encrypted upstream connection where pods backing the auth service are expected to serve a
valid certificate for auth.example.com. It uses subjectAltNames with a Hostname type, but you may also use a URI type.
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
name: tls-upstream-auth
spec:
targetRefs:
- kind: Service
name: auth
group: ""
sectionName: "https"
validation:
caCertificateRefs:
- group: "" # core API group
kind: ConfigMap
name: auth-cert
subjectAltNames:
- type: "Hostname"
hostname: "auth.example.com"
In this example, the BackendTLSPolicy is configured to use system certificates to connect with a TLS-encrypted backend connection where Pods backing the dev Service are expected to serve a valid certificate for dev.example.com.
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
name: tls-upstream-dev
spec:
targetRefs:
- kind: Service
name: dev
group: ""
sectionName: "btls"
validation:
wellKnownCACertificates: "System"
hostname: dev.example.com
More information on the configuration of TLS in Gateway API can be found in Gateway API - TLS Configuration.
Status information about the features that an implementation supports
Leads: Lior Lieberman, Beka Modebadze
GEP-2162: Supported features in GatewayClass Status
GatewayClass status has a new field, supportedFeatures.
This addition allows implementations to declare the set of features they support. This provides a clear way for users and tools to understand the capabilities of a given GatewayClass.
This feature's name for conformance tests (and GatewayClass status reporting) is SupportedFeatures.
Implementations must populate the supportedFeatures field in the .status of the GatewayClass before the GatewayClass
is accepted, or in the same operation.
Here’s an example of a supportedFeatures published under GatewayClass' .status:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
...
status:
conditions:
- lastTransitionTime: "2022-11-16T10:33:06Z"
message: Handled by Foo controller
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
supportedFeatures:
- HTTPRoute
- HTTPRouteHostRewrite
- HTTPRoutePortRedirect
- HTTPRouteQueryParamMatching
Graduation of SupportedFeatures to Standard, helped improve the conformance testing process for Gateway API.
The conformance test suite will now automatically run tests based on the features populated in the GatewayClass' status.
This creates a strong, verifiable link between an implementation's declared capabilities and the test results,
making it easier for implementers to run the correct conformance tests and for users to trust the conformance reports.
This means when the SupportedFeatures field is populated in the GatewayClass status there will be no need for additional
conformance tests flags like –suported-features, or –exempt or –all-features.
It's important to note that Mesh features are an exception to this and can be tested for conformance by using
Conformance Profiles, or by manually providing any combination of features related flags until the dedicated resource
graduates from the experimental channel.
Named rules for Routes
GEP-995: Adding a new name field to all xRouteRule types (HTTPRouteRule, GRPCRouteRule, etc.)
Leads: Guilherme Cassolato
This enhancement enables route rules to be explicitly identified and referenced across the Gateway API ecosystem.
Some of the key use cases include:
Status: Allowing status conditions to reference specific rules directly by name.
Observability: Making it easier to identify individual rules in logs, traces, and metrics.
Policies: Enabling policies (GEP-713) to target specific route rules via the sectionName field in their targetRef[s].
Tooling: Simplifying filtering and referencing of route rules in tools such as gwctl, kubectl, and general-purpose utilities like jq and yq.
Internal configuration mapping: Facilitating the generation of internal configurations that reference route rules by name within gateway and mesh implementations.
This follows the same well-established pattern already adopted for Gateway listeners, Service ports, Pods (and containers),
and many other Kubernetes resources.
While the new name field is optional (so existing resources remain valid), its use is strongly encouraged.
Implementations are not expected to assign a default value, but they may enforce constraints such as immutability.
Finally, keep in mind that the name format is validated,
and other fields (such as sectionName)
may impose additional, indirect constraints.
Experimental channel changes
Enabling external Auth for HTTPRoute
Giving Gateway API the ability to enforce authentication and maybe authorization as well at the Gateway or HTTPRoute level has been a highly requested feature for a long time. (See the GEP-1494 issue for some background.)
This Gateway API release adds an Experimental filter in HTTPRoute that tells the Gateway API implementation to call out to an external service to authenticate (and, optionally, authorize) requests.
This filter is based on the Envoy ext_authz API, and allows talking to an Auth service that uses either gRPC or HTTP for its protocol.
Both methods allow the configuration of what headers to forward to the Auth service, with the HTTP protocol allowing some extra information like a prefix path.
A HTTP example might look like this (noting that this example requires the Experimental channel to be installed and an implementation that supports External Auth to actually understand the config):
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: require-auth
namespace: default
spec:
parentRefs:
- name: your-gateway-here
rules:
- matches:
- path:
type: Prefix
value: /admin
filters:
- type: ExternalAuth
externalAuth:
protocol: HTTP
backendRef:
name: auth-service
http:
# These headers are always sent for the HTTP protocol,
# but are included here for illustrative purposes
allowedHeaders:
- Host
- Method
- Path
- Content-Length
- Authorization
backendRefs:
- name: admin-backend
port: 8080
This allows the backend Auth service to use the supplied headers to make a determination about the authentication for the request.
When a request is allowed, the external Auth service will respond with a 200 HTTP response code, and optionally extra headers to be included in the request that is forwarded to the backend. When the request is denied, the Auth service will respond with a 403 HTTP response.
Since the Authorization header is used in many authentication methods, this method can be used to do Basic, Oauth, JWT, and other common authentication and authorization methods.
Mesh resource
Lead(s): Flynn
GEP-3949: Mesh-wide configuration and supported features
Gateway API v1.4.0 introduces a new experimental Mesh resource, which provides a way to configure mesh-wide settings and discover the features supported by a given mesh implementation. This resource is analogous to the Gateway resource and will initially be mainly used for conformance testing, with plans to extend its use to off-cluster Gateways in the future.
The Mesh resource is cluster-scoped and, as an experimental feature, is named XMesh and resides in the gateway.networking.x-k8s.io API group. A key field is controllerName, which specifies the mesh implementation responsible for the resource. The resource's status stanza indicates whether the mesh implementation has accepted it and lists the features the mesh supports.
One of the goals of this GEP is to avoid making it more difficult for users to adopt a mesh. To simplify adoption, mesh implementations are expect
