Red Hat’s BackendTLSPolicy Turns Gateway API Migration Into a TLS Parity Test

Every time a platform team swaps a proprietary ingress layer for a vendor-neutral standard, the swap gets judged less on the features everyone expected and more on the one security control that almost got left behind. For OpenShift shops eyeing a move from the classic Route API to the community-driven Gateway API, that control has been backend TLS validation: the check that lets a gateway confirm a backend pod’s certificate is legitimate before forwarding traffic to it, rather than just encrypting the wire and hoping the other end is who it claims to be.

In a July 3 Red Hat blog post, Candace Holman of the OpenShift Network Engineering team announced that BackendTLSPolicy, a Gateway API resource for configuring exactly that check, is now available in Red Hat OpenShift 4.22. The claim is narrow but concrete: Gateway API users get the same level of secured backend traffic that OpenShift’s Route object has long provided through re-encrypt termination, the same mode already protecting login traffic to the OpenShift web console.

Four places TLS can terminate, and the one Gateway API was missing

OpenShift Routes have always given administrators a choice of where a TLS session ends. Passthrough termination lets encrypted traffic flow straight from client to backend pod without the router inspecting it. Edge termination stops the encryption at the router and sends plain HTTP onward. Re-encrypt termination does both: it terminates at the router and immediately re-encrypts a fresh TLS session to the backend, so nothing on the wire is ever unencrypted end to end. That last mode is what protects the web console.

Downstream and upstream are configured separately

Gateway API draws the same line but with different vocabulary. The upstream Gateway API TLS configuration guide splits the path into a downstream connection (client to Gateway) and an upstream connection (Gateway to backend), and says explicitly that “TLS configuration of downstream and upstream connections is managed independently.” Downstream behavior comes from a Listener’s TLS mode, Terminate or Passthrough. Until recently, upstream had no equivalent object at all: a Gateway could terminate and inspect client traffic, but it had no standard way to validate the certificate a backend pod presented on the other side. BackendTLSPolicy is that missing upstream object, and the guide notes that combining it with a Terminate listener is “what is commonly known as a connection that is terminated and then re-encrypted at the Gateway”: the Gateway API version of what OpenShift Routes already called re-encrypt.

What the policy actually configures

The official BackendTLSPolicy reference describes a small, deliberately constrained spec. A targetRefs field points the policy at one or more Services. A validation block then does the actual security work: a hostname field sets the SNI value the Gateway presents when it connects to the backend and must match the certificate served by the backend pod, and an optional list of up to five subjectAltNames (still an Experimental-channel addition even though the rest of the resource is Standard) lets operators check the certificate’s identity separately from the SNI used to route the connection. For trust, the policy accepts either caCertificateRefs, pointing at specific PEM certificate bundles, or wellKnownCACertificates, which tells the Gateway to trust the system CA store; the spec is explicit that exactly one of those two, never both, may be set.

A namespace boundary that isn’t optional

A BackendTLSPolicy has to live in the same namespace as the Service it targets, and cross-namespace certificate references are disallowed outright. That’s a narrower trust model than some teams may be used to under Routes, where certificate configuration lived wherever an administrator put it. It’s a reasonable default: sharing backend trust decisions across a namespace boundary is exactly the kind of implicit escalation a security-conscious migration should be trying to remove, not preserve for convenience.

It also isn’t limited to one route type

BackendTLSPolicy is what the spec calls a union feature: it applies to any route type that forwards traffic to a backend, which today means HTTPRoute, GRPCRoute, and TLSRoute in Terminate mode. Maturity here is layered, not uniform. TLSRoute itself only reached the Standard Channel in Gateway API v1.5, and its Terminate mode (the one BackendTLSPolicy actually needs) is still listed at the Extended support level rather than Standard. Even inside BackendTLSPolicy’s own spec, which reached Standard Channel in v1.4, the subjectAltNames field used for certificate-identity matching is still an Experimental-channel addition rather than Standard. A single “GA” resource can mix Standard guarantees, Experimental fields, and Extended-support route types depending on exactly which part of it a team relies on: the kind of detail a changelog entry won’t tell you and a conformance test will.

The real news is the hardening pipeline, not the policy

Holman’s post spends more time explaining how Gateway API features reach OpenShift than explaining the feature itself, and that process is the more useful story for anyone planning a migration. Red Hat’s account runs: a feature is proposed and accepted in the Gateway API community, promoted to the Standard Channel and released upstream, then Istio (the implementation behind Red Hat OpenShift Service Mesh) documents its own conformance with that feature. Only then does the Service Mesh team upgrade to the conformant Istio version, the Network Engineering team upgrades to that Service Mesh version and the matching Gateway API CRDs, both teams test and document the result, and the feature finally ships in an OpenShift release. Red Hat says it explicitly declines to ship experimental upstream features because they aren’t guarded against breaking changes, and that improvements to this pipeline over the past year have cut the time-to-release “by weeks.”

Run the dates and that pipeline has real teeth: BackendTLSPolicy has been Standard Channel and GA in upstream Gateway API since v1.4.0, yet it’s only landing in OpenShift now, in 4.22. That gap between “safe to use, according to upstream” and “certified and shipped by your distribution” is the actual cost of running an enterprise Kubernetes platform instead of tracking upstream releases directly, and it’s worth naming rather than assuming away. Red Hat also disclosed its own prioritization logic: re-encrypt parity was expected to take the longest of the outstanding Route features, so the team started on it first, and it’s now working through the rest of an experimental-to-stable backlog based on customer feedback.

What to check before leaning on this

None of this is a reason to avoid Gateway API, but it does set the terms for a sane migration checklist. Confirm the OpenShift version first: Gateway API itself has been generally available since 4.19, but BackendTLSPolicy specifically requires 4.22, so a cluster sitting on an earlier release has the routing object without the backend-validation half of it. Confirm the implementation next. OpenShift’s Gateway API support runs through Istio via Red Hat OpenShift Service Mesh, so its BackendTLSPolicy conformance follows Red Hat’s certification timeline; a team running a different Gateway API implementation elsewhere shouldn’t assume the same feature lands on the same schedule or at the same maturity level, since the spec itself allows implementations to vary. Finally, test the namespace boundary against existing certificate-sharing habits. Teams that got used to Routes referencing certificates from wherever an administrator placed them will need to relocate or duplicate those references into each Service’s own namespace, and that migration step is easy to miss until a backend connection fails validation in a way a Route never would have.

What to watch next

Red Hat frames this as one item off a prioritized list, not the end of the list. The next signals worth tracking are which of the remaining experimental route features get promoted to stable next, and whether the gap between upstream Gateway API releases and their certified arrival in OpenShift keeps shrinking the way Red Hat says it has over the past year. For any team with a Route-to-Gateway migration on its own roadmap, that cadence, not any single feature announcement, is the number that determines when the migration is actually safe to finish.

Sources

• Red Hat Blog: BackendTLSPolicy expands Gateway API transport security
• Gateway API reference: BackendTLSPolicy
• Gateway API user guide: TLS Configuration
• Featured image source: optical patch fiber cable on Wikimedia Commons

Image credit: Optical patch fiber cable photograph by Geek3, licensed CC BY-SA 4.0 via Wikimedia Commons; cropped, resized, and converted to WebP for sxz.io.