Gateway security

This page describes different methods for securing Gateways in Google Kubernetes Engine (GKE). You can also learn how to Secure a Gateway.

How Gateway security works

A Gateway represents the frontend of a load balancer. There are two paths that you can secure with authentication and encryption for Gateways:

  • Client to Gateway: traffic originated at the client and terminated at the Gateway.
  • Gateway to Pod: traffic originated at the Gateway and terminated at the backend Pods.

The following diagram shows both paths to authenticate and encrypt Gateways:

This page describes how to secure the client to Gateway path using certificates uploaded and managed at the Gateway level. To learn how to secure Gateway to Pod traffic, see Secure load balancer to application traffic using TLS.

Benefits

You can secure an application in many different ways using the Gateway API, which provides flexibility to different roles interacting with the Gateway.

Who owns domain and TLS configuration?

The Gateway API model introduces two roles that use or deploy Gateways:

  • Platform admin: the cluster operator is the administrator for entire clusters. They manage policies, network access, and application permissions.
  • Application developer: the application developer defines their application and Service configuration.

The following diagram shows the fields in the Gateway and HTTPRoute resources that influence TLS and domain ownership for two applications, store-v1 and store-v2.

In the diagram, the cluster operator controls:

  • Which domains application developers can use for their apps in each namespace.
  • The specific certificates that terminate different domains.
  • Certificates provided by the Gateway owner.
  • Whether HTTPRoute owners can specify their own hostnames for certificate generation.

Application developers control the hostname that generates a certificate, if the Gateway definition permits it.

This separation of operational tasks enables application developers to deploy and manage their own HTTPRoute for more distributed control and lets platform administrators deploy and manage Gateways for centralized control of TLS.

Gateway certificate management

You can secure Gateways using any following methods:

If you use Kubernetes Secrets or SslCertificate resources from the Compute Engine API, you can attach at most 15 certificates to a single Gateway.

Certificate Manager lets you attach up to 10,000,000 certificates per load balancer, if you request a quota increase.

To learn more about Google Cloud SSL certificates, see SSL certificates overview.

Kubernetes Secrets

The Gateway API spec supports Kubernetes Secrets for storing and attaching certificates to Gateways. You can associate one or more Kubernetes Secrets with a Gateway using the field Gateway.spec.tls.certificateRef.

Gateway resources secured through Kubernetes Secrets have the following requirements:

  • You must be set the Gateway listener port and protocol to 443 and HTTPS.
  • You must set the listener.tls.mode field to Terminate.
  • You must reference the TLS credentials in the listeners.tls block.

Gateway resources secured using Kubernetes Secrets have the following limitations:

  • Only HTTPS listeners terminate traffic using the specified Secrets, although you can specify multiple listeners with a mix of HTTP and HTTPS.
  • If you have multiple listeners using HTTPS on the same Gateway, each listener must have a unique hostname.
  • You can only omit a single hostname or assign * for each port and protocol pair.
  • You can only assign one default certificate for each Gateway.

To learn how to secure a Gateway using a Kubernetes Secret, see Secure a Gateway using a Kubernetes Secret.

SSL certificates

SSL certificates store and deliver certificates to load balancers.

An SSL certificate can be either self-managed or Google-managed.

To learn more about the differences between these two types of certificates, see SSL certificates overview.

The scope and location of the SSL certificate must match the scope and location of the Gateway that is using it.

For example, a global SSL certificate cannot be used by a regional Gateway.

The following table lists the scope and location requirements of SSL certificates for each GatewayClass:

GatewayClass SSL certificate scope SSL certificate location
gke-l7-global-external-managed Global SSL certificate Global
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Regional SSL certificate Must be the same region as the Gateway
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
Google-managed SSL Certificates are not compatible with regional Gateways.

To learn how to secure a Gateway using an SSL certificate, see Secure a Gateway using an SSL certificate.

Certificate Manager

Certificate Manager is a centralized location to manage your TLS certificates.

When you secure a Gateway using Certificate Manager, you can do the following:

  • Reference a CertificateMap directly from a Gateway that you created in Certificate Manager.
  • Manage your own certificates.
  • Improve certificate propagation times.
  • Use Cloud Monitoring for expired certificates and certificate propagation.

Certificate Manager supports both self-managed and Google-managed SSL certificates.

To learn how to secure a Gateway using Certificate Manager, see Secure a Gateway using Certificate Manager.

GatewayClass TLS support

The following table describes the TLS termination methods that GKE supports for each GatewayClass:

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
Client to Gateway TLS Supported Supported
Gateway to backend TLS Supported Supported
Google Cloud certificate resource Global SSL certificate
CertificateMap		 Regional SSL certificate
Self-managed certificates with Kubernetes Secrets Supported Supported
Self-managed Compute Engine SSL certificates Supported Supported
Google-managed Compute Engine SSL certificates Supported Not supported
Self-managed SSL certificates with Certificate Manager Supported Supported
Google-managed SSL certificates with Certificate Manager Supported Supported

What's next