En esta página se describen diferentes métodos para proteger las pasarelas en Google Kubernetes Engine (GKE). También puedes consultar cómo proteger una pasarela.
Cómo funciona la seguridad de la pasarela
Una pasarela representa el frontend de un balanceador de carga. Hay dos rutas que puedes proteger con autenticación y cifrado para las pasarelas:
- Cliente a pasarela: el tráfico se origina en el cliente y finaliza en la pasarela.
- Puerta de enlace a pod: el tráfico se ha originado en la puerta de enlace y ha finalizado en los pods de backend.
En el siguiente diagrama se muestran las dos formas de autenticar y cifrar las pasarelas:
En esta página se describe cómo proteger la ruta del cliente a la puerta de enlace mediante certificados subidos y gestionados a nivel de puerta de enlace. Para saber cómo proteger el tráfico de Gateway a Pod, consulta Proteger el tráfico del balanceador de carga a la aplicación mediante TLS.
Ventajas
Puedes proteger una aplicación de muchas formas diferentes con la API Gateway, que ofrece flexibilidad a los diferentes roles que interactúan con la puerta de enlace.
¿Quién es el propietario de la configuración de dominio y TLS?
El modelo de API Gateway introduce dos roles que usan o despliegan pasarelas:
- Administrador de la plataforma: el operador del clúster es el administrador de todos los clústeres. Gestionan las políticas, el acceso a la red y los permisos de las aplicaciones.
- Desarrollador de la aplicación: el desarrollador de la aplicación define la configuración de la aplicación y del servicio.
En el siguiente diagrama se muestran los campos de los recursos Gateway y HTTPRoute que influyen en la propiedad de TLS y de dominio de dos aplicaciones, store-v1 y store-v2.
En el diagrama, el operador de 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 en diferentes dominios.
- Certificados proporcionados por el propietario de la pasarela.
- 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 Gateway lo permite.
Esta separación de las tareas operativas permite a los desarrolladores de aplicaciones desplegar y gestionar su propia HTTPRoute para tener un control más distribuido, y a los administradores de la plataforma desplegar y gestionar Gateways para tener un control centralizado de TLS.
Gestión de certificados de pasarela
Puedes proteger las pasarelas con cualquiera de los siguientes métodos:
Si usas secretos de Kubernetes o recursos SslCertificate de la API Compute Engine, puedes adjuntar un máximo de 15 certificados a una sola puerta de enlace.
Certificate Manager te permite adjuntar hasta 10.000.000 de certificados por balanceador de carga si solicitas un aumento de cuota.
Para obtener más información sobre los certificados SSL, consulta el artículo Información general sobre los certificados SSL. Trusted Cloud
Secretos de Kubernetes
La
especificación de la API Gateway
admite
Secretos de Kubernetes
para almacenar y adjuntar certificados a las pasarelas. Puedes asociar uno o varios secretos de Kubernetes a una pasarela mediante el campo Gateway.spec.tls.certificateRef.
Los recursos de Gateway protegidos mediante secretos de Kubernetes deben cumplir los siguientes requisitos:
- Debes definir los valores
portyprotocoldel receptor de la pasarela como443yHTTPS. - Debe asignar el valor
Terminateal campolistener.tls.mode. - Debes hacer referencia a las credenciales TLS en el bloque
listeners.tls.
Los recursos de Gateway protegidos con secretos de Kubernetes tienen las siguientes limitaciones:
- Solo los listeners HTTPS anulan el tráfico mediante los secretos especificados, aunque puedes especificar varios listeners con una combinación de HTTP y HTTPS.
- Si tienes varios listeners que usan HTTPS en la misma pasarela, cada listener debe tener un nombre de host único.
- Solo puedes omitir un nombre de host o asignar
*a cada par de puerto y protocolo. - Solo puedes asignar un certificado predeterminado a cada pasarela.
Para saber cómo proteger una pasarela con un secreto de Kubernetes, consulta Proteger una pasarela con un secreto de Kubernetes.
Certificados SSL
Los certificados SSL almacenan y entregan certificados a los balanceadores de carga. Un certificado SSL puede ser autogestionado o gestionado por Google.
- Los certificados SSL autogestionados son certificados que obtienes, aprovisionas y renuevas tú mismo.
- Los certificados SSL gestionados por Google son certificados que Google Trusted Cloud by S3NS obtiene, gestiona y renueva automáticamente.
Para obtener más información sobre las diferencias entre estos dos tipos de certificados, consulta el artículo Descripción general de los certificados SSL.
El ámbito y la ubicación del certificado SSL deben coincidir con el ámbito y la ubicación de la pasarela que lo utiliza. Por ejemplo, un certificado SSL global no puede utilizarlo una pasarela regional.
En la siguiente tabla se indican los requisitos de ámbito y ubicación de los certificados SSL para cada GatewayClass:
| GatewayClass | Ámbito del certificado 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 de la pasarela |
gke-l7-regional-external-managed-mc |
||
gke-l7-cross-regional-internal-managed-mc |
||
gke-l7-rilb |
||
gke-l7-rilb-mc |
Los certificados SSL gestionados por Google no son compatibles con las pasarelas regionales. Para proteger las pasarelas regionales, usa Certificate Manager.
Para saber cómo proteger una pasarela con un certificado SSL, consulta el artículo Proteger una pasarela con un certificado SSL.
Certificate Manager
Gestor de certificados es una ubicación centralizada para gestionar tus certificados TLS.
Cuando proteges una pasarela con Certificate Manager, puedes hacer lo siguiente:
- Hacer referencia a un
CertificateMapdirectamente desde una pasarela que haya creado en Gestor de certificados. - Gestionar tus propios certificados.
- Mejorar los tiempos de propagación de los certificados.
- Usa Cloud Monitoring para los certificados caducados y la propagación de certificados.
Certificate Manager admite certificados SSL autogestionados y gestionados por Google. Para saber cómo proteger una pasarela con Certificate Manager, consulta el artículo Proteger una pasarela con Certificate Manager.
Compatibilidad con TLS de GatewayClass
En la siguiente tabla se describen los métodos de finalización de TLS que admite GKE 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
|
gke-l7-cross-regional-internal-managed-mc
|
|---|---|---|---|
| TLS de cliente a pasarela | Se admite | Se admite | |
| TLS de la pasarela al backend | Se admite | Se admite | |
| Recurso de certificadoTrusted Cloud | Certificado SSL globalCertificateMap |
Certificado SSL regional | |
| Certificados autogestionados con secretos de Kubernetes | Se admite | Se admite | No compatible |
| Certificados SSL de Compute Engine autogestionados | Se admite | Se admite | No compatible |
| Certificados SSL de Compute Engine gestionados por Google | Se admite | No compatible | No compatible |
| Certificados SSL autogestionados con Gestor de certificados | Se admite | Se admite | Se admite |
| Certificados SSL gestionados por Google con Gestor de certificados | Se admite | Se admite | Se admite |
Siguientes pasos
- Consulta cómo proteger una pasarela.