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. Existen dos rutas que puedes proteger con la autenticación y la encriptación para puertas de enlace:
- De cliente a puerta de enlace: tráfico que se origina en el cliente y finaliza en la puerta de enlace.
- De puerta de enlace al Pod: tráfico que se origina en la puerta de enlace y finaliza en los Pods del backend.
En el siguiente diagrama, se muestran ambas rutas para autenticar y encriptar puertas de enlace:
En esta página se describe cómo proteger la ruta del cliente a la puerta de enlace mediante certificados subidos y administrados a nivel de puerta de enlace. Si deseas obtener información para proteger el tráfico de la puerta de enlace al Pod, consulta Protege el tráfico del balanceador de cargas a la aplicación mediante TLS.
Beneficios
Puedes proteger una aplicación de muchas maneras diferentes mediante 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 el Service.
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
portyprotocoldel objeto de escucha de Gateway como443yHTTPS. - Debes configurar el campo
listener.tls.modecomoTerminate. - 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.
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-rilb |
||
gke-l7-rilb-mc |
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
CertificateMapdirectamente 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-managedgke-l7-global-external-managed-mcgke-l7-gxlbgke-l7-gxlb-mc
|
gke-l7-regional-external-managedgke-l7-regional-external-managed-mcgke-l7-rilbgke-l7-rilb-mc
|
|---|---|---|
| TLS de cliente a puerta de enlace | Admitido | Admitido |
| TLS de puerta de enlace a backend | Admitido | Admitido |
| Recurso de certificado de Google Cloud | Certificado SSL global CertificateMap |
Certificado SSL regional |
| Certificados autoadministrados con Secrets de Kubernetes | Admitido | Admitido |
| Certificados SSL de Compute Engine autoadministrados | Admitido | Admitido |
| Certificados SSL de Compute Engine administrados por Google | Admitido | No admitido |
| Certificados SSL autoadministrados con el Administrador de certificados | Admitido | Admitido |
| Certificados SSL administrados por Google con el Administrador de certificados | Admitido | Admitido |
¿Qué sigue?
- Obtén más información sobre cómo proteger una puerta de enlace.