Seguridad de la puerta de enlace

En esta página, se describen diferentes métodos para proteger las puertas de enlace en Google Kubernetes Engine (GKE). También puedes obtener información sobre cómo proteger una puerta de enlace.

Cómo funciona la seguridad de la puerta de enlace

Un objeto de puerta de enlace representa el frontend de un balanceador de cargas. Según tus requisitos de seguridad y cumplimiento, puedes ayudar a proteger el tráfico a través de una puerta de enlace de dos maneras principales:

  • Finalización de TLS: La puerta de enlace finaliza las conexiones TLS del cliente en el frontend de la puerta de enlace con certificados SSL administrados o autoadministrados. De manera opcional, la puerta de enlace puede volver a encriptar el tráfico entre la puerta de enlace y los Pods de backend con una BackendTLSPolicy.
  • Transferencia de TLS: El tráfico de TLS encriptado pasa directamente a través de la puerta de enlace a los Pods de backend sin que el balanceador de cargas finalice o desencripte el tráfico. Usa los recursos TLSRoute para enrutar el tráfico según el nombre de host de la indicación de nombre del servidor (SNI).

En esta página, se describe cómo proteger la ruta del cliente a la puerta de enlace con certificados subidos y administrados a nivel de puerta de enlace, y cómo configurar la transferencia de TLS de extremo a extremo. Para obtener información sobre cómo proteger el tráfico de la puerta de enlace segura al Pod con la finalización de TLS, consulta Protege el tráfico del balanceador de cargas a la aplicación con TLS.

Comparación entre la finalización de TLS y la transferencia de TLS

GKE Gateway admite dos modos de operación de TLS distintos según si TLS se desencripta en el balanceador de cargas o se pasa directamente a las cargas de trabajo de backend: finalización de TLS y transferencia de TLS.

finalización de TLS

Con la finalización de TLS, la puerta de enlace finaliza las conexiones TLS de los clientes en el frontend del balanceador de cargas.

Cuando configuras un objeto de escucha de Gateway con el campo tls.mode establecido en Terminate y el campo protocol establecido en HTTPS, adjuntas certificados TLS directamente a la puerta de enlace con Secrets de Kubernetes, certificados SSL o el Administrador de certificados.

Estas son algunas de las características clave de la finalización de TLS:

  • Inspección de capa 7: Debido a que la puerta de enlace desencripta el tráfico del cliente, puede evaluar los atributos de la solicitud HTTP (como encabezados, rutas de acceso y métodos) y enrutar el tráfico con recursos HTTPRoute.
  • Seguridad perimetral: Permite la integración en las políticas de seguridad de Google Cloud Armor, las reglas de firewall de aplicación web (WAF) y el almacenamiento en caché perimetral de Cloud CDN.
  • Encriptación de backend con BackendTLSPolicy: Si tus cargas de trabajo requieren encriptación de extremo a extremo en tránsito, puedes configurar un recurso BackendTLSPolicy para volver a encriptar el tráfico entre la puerta de enlace y los Pods de backend.

En el siguiente diagrama, se muestra cómo una puerta de enlace de GKE encripta ambas rutas de tráfico cuando usas la finalización de TLS con la encriptación de backend. Un cliente externo envía una solicitud HTTPS encriptada (https://example.com) a la puerta de enlace en una red de nube privada virtual (VPC), en la que el balanceador de cargas finaliza la conexión TLS. Luego, el balanceador de cargas establece una conexión independiente y encriptada de nuevo para reenviar el tráfico a los Pods de backend Store en el clúster de GKE:

Encriptación de cliente a puerta de enlace y de puerta de enlace a backend con finalización de TLS

Además de la encriptación, puedes proteger la ruta del cliente a la puerta de enlace con políticas de autorización. Las políticas de autorización habilitan una arquitectura de confianza cero, ya que inspeccionan las solicitudes entrantes y aplican el control de acceso según las identidades de los clientes, los encabezados HTTP y las rutas solicitadas antes de que el tráfico se enrute a tus Pods de backend.

Para obtener más información sobre cómo configurar la finalización de TLS y la TLS de backend, consulta Protege una puerta de enlace.

Transferencia de TLS

Con la transferencia de TLS, la puerta de enlace envía el tráfico de TLS encriptado directamente a las cargas de trabajo de backend sin desencriptar la carga útil en el balanceador de cargas.

Cuando configuras un objeto de escucha de Gateway con el campo tls.mode establecido en Passthrough y el campo protocol establecido en TLS, la puerta de enlace no finaliza TLS ni conserva certificados SSL. En su lugar, el balanceador de cargas solo inspecciona el nombre de host de la indicación de nombre del servidor (SNI) sin encriptar en el protocolo de enlace TLS ClientHello y enruta el flujo de TCP encriptado sin procesar a los Pods de backend con recursos TLSRoute.

Estas son algunas de las características clave de la transferencia de TLS:

  • Encriptación de extremo a extremo: El tráfico permanece encriptado durante todo el tránsito desde el cliente hasta los Pods de backend. La aplicación de backend administra los certificados, finaliza TLS y desencripta la carga útil.
  • No se necesita administración de certificados en la puerta de enlace: No adjuntas certificados ni Secrets de Kubernetes al objeto de escucha de la puerta de enlace.
  • Proxy de capa 4: El balanceador de cargas reenvía transmisiones de TCP encriptadas y enruta el tráfico según los metadatos del protocolo de enlace TLS sin encriptar (como el nombre de host de SNI) con recursos de TLSRoute.
  • Compensaciones de seguridad: El traspaso de TLS funciona bien para los requisitos de cumplimiento en los que no puedes compartir claves privadas con la infraestructura de nube o para protocolos basados en TLS que no son HTTP. Sin embargo, impide la inspección del balanceador de cargas de capa 7 y los servicios de seguridad perimetral, como las reglas de WAF de Google Cloud Armor.

En el siguiente diagrama, se muestra cómo Gateway encripta y enruta el tráfico desde el cliente hasta los Pods de backend cuando se usa la transferencia de TLS. Un cliente envía una solicitud de TLS encriptada con el nombre de host de SNI store.example.com a la puerta de enlace, que reenvía el flujo encriptado sin desencriptación directamente a los Pods Store de destino:

Transferencia de TLS encriptada de extremo a extremo desde el cliente hasta los Pods de backend

Para obtener más información sobre cómo implementar una puerta de enlace de transferencia de TLS con TLSRoute, consulta Implementa una puerta de enlace de transferencia de TLS.

Beneficios

Puedes proteger una aplicación de muchas maneras diferentes con la API de Gateway, que proporciona flexibilidad a diferentes roles que interactúan con la puerta de enlace.

¿Quién es el propietario del dominio y la configuración de TLS?

El modelo de la API de Gateway presenta dos roles que usan o implementan puertas de enlace:

  • Administrador de la plataforma: el operador del clúster es el administrador de todos los clústeres. Administran las políticas, el acceso a la red y los permisos de la aplicación.
  • Desarrollador de la aplicación: el desarrollador de la aplicación define la configuración de la aplicación y la configuración del servicio.

En el siguiente diagrama, se muestran los campos de los recursos Gateway y HTTPRouter que influyen en la propiedad del dominio y TLS para dos aplicaciones, store-v1 y store-v2.

En el diagrama, el operador del clúster controla lo siguiente:

  • Qué dominios pueden usar los desarrolladores de aplicaciones para sus aplicaciones en cada espacio de nombres.
  • Los certificados específicos que terminan dominios diferentes.
  • Los certificados proporcionados por el propietario de la puerta de enlace.
  • Si los propietarios de HTTPRoute pueden especificar sus propios nombres de host para la generación de certificados.

Los desarrolladores de aplicaciones controlan el nombre de host que genera un certificado, si la definición de la puerta de enlace lo permite.

Esta separación de tareas operativas permite a los desarrolladores de aplicaciones implementar y administrar su propia HTTPRoute para lograr un control más distribuido y permite a los administradores de plataformas implementar y administrar puertas de enlace para lograr un control centralizado de TLS.

Administración de certificados de puertas de enlace

Puedes proteger las puertas de enlace con cualquiera de los siguientes métodos:

Si usas Secrets de Kubernetes o recursos SslCertificate de la API de Compute Engine, puedes adjuntar como máximo 15 certificados a una sola puerta de enlace.

El Administrador de certificados te permite adjuntar hasta 10,000,000 certificados por balanceador de cargas si solicitas un aumento de la cuota.

Para obtener más información sobre los certificados SSL de Google Cloud , consulta Descripción general de certificados SSL.

Secretos de Kubernetes

La especificación de la API de Gateway admite Secrets de Kubernetes para almacenar y adjuntar certificados a las puertas de enlace. Puedes asociar uno o más Secrets de Kubernetes con una puerta de enlace mediante el campo Gateway.spec.tls.certificateRef.

Los recursos de puerta de enlace protegidos mediante Secrets de Kubernetes tienen los siguientes requisitos:

  • Debes configurar port y protocol del objeto de escucha de Gateway como 443 y HTTPS.
  • Debes configurar el campo listener.tls.mode como Terminate.
  • Debes hacer referencia a las credenciales TLS en el bloque listeners.tls.

Los recursos de puerta de enlace protegidos mediante Secrets de Kubernetes tienen las siguientes limitaciones:

  • Solo los objetos de escucha HTTPS finalizan el tráfico mediante los Secrets especificados, aunque puedes especificar varios objetos de escucha con una combinación de HTTP y HTTPS.
  • Si tienes varios objetos de escucha que usan HTTPS en la misma puerta de enlace, cada objeto de escucha debe tener un nombre de host único.
  • Solo puedes omitir un nombre de host o asignar * para cada puerto y par de protocolo.
  • Solo puedes asignar un certificado predeterminado para cada puerta de enlace.

Para obtener información sobre cómo proteger una puerta de enlace con un Secret de Kubernetes, consulta Protege una puerta de enlace con un Secret de Kubernetes.

Certificados SSL

Los certificados SSL almacenan y entregan certificados a los balanceadores de cargas. Un certificado SSL puede ser autoadministrado o administrado por Google.

  • Los certificados SSL autoadministrados son certificados que obtienes, aprovisionas y renuevas tú mismo.
  • Los certificados SSL administrados por Google son certificados que Google Cloud obtiene, administra y renueva de manera automática.

Para obtener más información sobre las diferencias entre estos dos tipos de certificados, consulta Descripción general de certificados SSL.

El permiso y la ubicación del certificado SSL deben coincidir con el permiso y la ubicación de la puerta de enlace que lo usa. Por ejemplo, una puerta de enlace regional no puede usar un certificado SSL global.

En la siguiente tabla, se enumeran los requisitos de alcance y ubicación de los certificados SSL para cada GatewayClass:

GatewayClass Alcance de los certificados SSL Ubicación del certificado SSL
gke-l7-global-external-managed Certificado SSL global Global
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Certificado SSL regional Debe ser la misma región que la puerta de enlace
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

Los certificados SSL administrados por Google no son compatibles con las puertas de enlace regionales. Para proteger las puertas de enlace regionales, usa el Administrador de certificados.

Para obtener información sobre cómo asegurar una puerta de enlace con un certificado SSL, consulta Protege una puerta de enlace con un certificado SSL.

Administrador de certificados

El Administrador de certificados es una ubicación centralizada para administrar tus certificados TLS.

Cuando proteges una puerta de enlace mediante el Administrador de certificados, puedes hacer lo siguiente:

  • Hacer referencia a un CertificateMap directamente desde una Puerta de enlace que creaste en el Administrador de certificados.
  • Administrar tus propios certificados.
  • Mejorar los tiempos de propagación de certificados.
  • Usar Cloud Monitoring para la propagación de certificados y certificados vencidos.

El Administrador de certificados admite certificados SSL autoadministrados y administrados por Google. Para obtener información sobre cómo proteger una puerta de enlace con el Administrador de certificados, consulta Protege una puerta de enlace con Administrador de certificados.

Compatibilidad con TLS de GatewayClass

En la siguiente tabla, se describen los métodos de finalización de TLS que GKE admite para cada 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 		gke-l7-cross-regional-internal-managed-mc
TLS de cliente a puerta de enlace Admitido Admitido
TLS de puerta de enlace a backend Admitido Admitido
Recurso de certificado deGoogle Cloud Certificado SSL global
CertificateMap		 Certificado SSL regional
Transferencia de TLS (TLSRoute) No admitido Admitido Admitido
Certificados autoadministrados con Secrets de Kubernetes Admitido Admitido No admitido
Certificados SSL de Compute Engine autoadministrados Admitido Admitido No admitido
Certificados SSL de Compute Engine administrados por Google Admitido No admitido No admitido
Certificados SSL autoadministrados con el Administrador de certificados Admitido Admitido Admitido
Certificados SSL administrados por Google con el Administrador de certificados Admitido Admitido Admitido

Autorización y control de acceso

Las puertas de enlace de GKE admiten el control de acceso basado en la identidad con el recurso personalizado GCPAuthzPolicy. Este recurso permite que los administradores de la plataforma definan reglas explícitas de ALLOW o DENY para el tráfico norte-sur.

Además, las puertas de enlace se pueden integrar en Service Extensions con el recurso GCPAuthzExtension. Este recurso permite que la puerta de enlace realice llamadas intercaladas a motores de autorización externos, personalizados o de terceros (como Identity-Aware Proxy) para evaluar las solicitudes en tiempo real.

¿Qué sigue?