BackendTLSPolicy expands Gateway API transport security

BackendTLSPolicy is a Kubernetes resource that allows the specification of additional Transport Layer Security (TLS) encryption in Gateway API. It gives Gateway API users on Red Hat OpenShift access to the same level of secured traffic as the OpenShift route provides with re-encrypt termination, and is now available in Red Hat OpenShift 4.22. Re-encrypt TLS termination is already used for the OpenShift route that provides access to the web console, and provides encrypted login functionality to customer applications.

Gateway API is the open source, next-generation network ingress solution developed as a project of the Kubernetes networking community to replace its legacy Kubernetes ingress solution. OpenShift began supporting Gateway API as a general availability feature in release 4.19. BackendTLSPolicy is a recent contribution championed by Red Hat in order to provide functionality matching the existing OpenShift route re-encrypt TLS feature. 

How Gateway API features make it into OpenShift

Those of us on the Red Hat OpenShift Network Engineering team get a lot of questions about how open source Gateway API features make it into OpenShift as a router feature. The process is semi-predictable and is dependent on our chosen implementation, Istio via Red Hat OpenShift Service Mesh. 

The first step in the process is to propose and get acceptance of a feature in the Gateway API community. After the feature is promoted to the stable channel and released upstream, Istio must document its conformance with Gateway API. Next, the OpenShift Service Mesh team upgrades to the Istio version containing that feature. Then the Network Engineering team upgrades to the conformant OpenShift Service Mesh version and Gateway API custom resource definitions. Both teams test, maintain, and document the upgrade. Finally, the feature makes it into an OpenShift release. 

Over the past year, advancements in the OpenShift Service Mesh release process and greater Red Hat involvement in the Gateway API open source community have reduced the time to release for new features by weeks. While we’re working on making the process faster still, we contend that it is worth the time invested. We do not accept experimental features because they are not guarded from breaking changes. We are able to provide high-quality features as enterprise-hardened first-class components in an OpenShift release. This is part of what makes us Red Hat OpenShift.

Modern network ingress with OpenShift features

BackendTLSPolicy is the Gateway API resource for specifying the TLS configuration of the connection from the gateway to backend pods. Gateway API did not have backend configuration options prior to the introduction of BackendTLSPolicy, and there were many open source engineering negotiations that preceded it. Red Hat started with a prioritized list of route features in order to provide our customers a smoother transition to Gateway API; re-encrypt was the one we expected to take the longest, so we started it first. Based on customer feedback, we are in the process of hardening other features to promote them from the experimental to stable channel.

Understanding BackendTLSPolicy

There are several termination points of the TLS encryption path from client to gateway to backend pod. Passthrough termination happens between the client and backend pod without being checked at the gateway. Edge termination happens between client and gateway only. Backend termination (configured using BackendTLSPolicy) happens between the gateway and backend pod. Re-encrypt happens when edge and backend termination are configured together for the same traffic, providing end-to-end encryption while observing gateway routing configuration. 

BackendTLSPolicy targets a service and offers TLS validation concepts that are designed to be flexible. You can use hostname as server name indication (SNI) header and/or for authentication certificate matching. You can use subjectAltNames (SANs) for multiple certificates matching and specify SANs as hostnames or uniform resource identifiers (URIs). You can use caCertificateRefs for specific TLS certificate bundles or use wellKnownCertificates for trusted system CA certificates 

The configuration of BackendTLSPolicy is based on the TLS certificate your backend pod offers. In most cases, administrators wish to secure multiple domains or subdomains with the same certificate, so they request a certificate with multiple SANs that can be shared by applications. During the initial validation, the gateway could use its caCertificate to verify the served certificate, then proceed to check the certificate offered by the application to make sure at least 1 SAN matched. In rare cases, a single hostname is contained in the certificate so a BackendTLSPolicy hostname can be configured instead of SANs. The use of wellKnownCertificates (default or system certificates) to validate the offered certificate is more likely when the pod offers a self-signed certificate, such as might be used during a development or testing phase.

The introduction of BackendTLSPolicy in OpenShift 4.22 helps ensure that a transition to Gateway API does not sacrifice the security that our customers rely on in their current OpenShift route configurations. As Red Hat continues to champion upstream contributions, we remain dedicated to delivering enterprise-hardened networking capabilities. We encourage you to explore BackendTLSPolicy and see how it can help you streamline and secure the traffic flow for your Gateway API applications.

For more information, check out the Gateway API documentation:

• Configuring TLS in Gateway API
• Discussion of the design of BackendTLSPolicy