1. Escenario, objetivos y no-objetivos
Un equipo de infraestructura opera un Gateway compartido mientras que los equipos de aplicaciones despliegan servicios en sus propios espacios de nombres. Un servicio de pagos requiere que el Gateway nunca vea texto sin formato, un servicio de administración interna requiere la validación de certificados de cliente en el borde, y los auditores exigen que se registren los cambios de ruta y las fallas de negociación de enlace (handshake). Los equipos deben publicar rutas de manera independiente mientras que los permisos de certificados, backends y listeners se mantienen restringidos.
Establece primero el no-objetivo: los recursos de Gateway API expresan intención. La implementación concreta de TLS, el comportamiento del balanceo de carga y el almacenamiento de certificados siguen siendo propiedades del controlador de GatewayClass. Por lo tanto, el diseño necesita una matriz de capacidades del controlador y comprobaciones de compatibilidad; el comportamiento de una implementación no puede tratarse como una garantía de la API.
2. Descomponer las capacidades de Gateway API 1.5
Gateway API 1.5 promueve TLSRoute, la validación de certificados de cliente en el frontend y las capacidades de TLS en backend relacionadas hacia un soporte estable, y asciende ReferenceGrant a v1. TLSRoute compara un nombre de host del SNI del handshake de TLS y reenvía la conexión a un backend; un listener puede usar Passthrough o Terminate.
En Passthrough, el Gateway transmite bytes cifrados como proxy y el backend posee el certificado y el handshake. En Terminate, TLS finaliza en el Gateway y el TCP descifrado se envía al backend. La propiedad de la clave, la visibilidad de los datos y los puntos de ejecución de políticas difieren, por lo que el rendimiento por sí solo no puede decidir entre ellos.
3. Diseñar recursos y propiedad
El equipo de plataforma crea el Gateway y los listeners; los equipos de aplicaciones crean objetos TLSRoute vinculados a listeners con nombre. Usa parentRefs.sectionName para vincular una ruta a un listener explícito en lugar de permitir que una ruta reclame un Gateway completo. Los nombres de host, puertos, protocolos y referencias de certificados son entradas de política para revisión.
Este par de recursos expresa la intención de passthrough:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: tls-passthrough
protocol: TLS
port: 8443
tls:
mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: payments
namespace: payments
spec:
parentRefs:
- name: shared-edge
namespace: infra
sectionName: tls-passthrough
hostnames: ["pay.example.com"]
rules:
- backendRefs:
- name: payments
port: 8443Las referencias entre espacios de nombres deben pasar el mecanismo de autorización del controlador y estar explícitamente permitidas por ReferenceGrant o una política equivalente. No dependas de la visibilidad predeterminada.
4. Elegir entre Passthrough y Terminate
Passthrough significa que el Gateway no contiene ninguna clave privada y no ve ningún protocolo de aplicación. Se adapta a requisitos estrictos de cifrado de extremo a extremo, TLS mutuo directo en el backend o TCP cifrado. La compensación es que el Gateway no puede enrutar según el contenido HTTP, aplicar un límite uniforme en la capa de aplicación ni validar certificados de cliente en el borde; los backends asumen el trabajo de handshake y rotación de certificados.
Terminate centraliza la gestión de certificados y permite la validación de certificados de cliente en el borde, un enrutamiento uniforme y una observabilidad coherente. La compensación es la visibilidad del texto sin formato en el Gateway. Si el salto hacia el backend debe permanecer cifrado, configura también backend TLS; la exposición de claves privadas y el dominio de fallo del controlador también aumentan.
Un diseño de calidad de entrevista es estratificado: establece por defecto conexiones de pago altamente sensibles en passthrough, mientras que terminas los servicios de administración que necesitan identidad y políticas centralizadas, y luego protege el segundo salto con backend TLS.
5. Frontend mTLS y anclas de confianza
El frontend mTLS valida la conexión del cliente al Gateway. El Gateway compara el certificado del cliente con los paquetes de CA configurados; el modo estricto acepta únicamente un cliente validado. Un fallback inseguro puede permitir que un certificado faltante o no válido llegue al backend, por lo que debe ser una excepción explícita combinada con políticas de red y alertas de auditoría.
Agrupa las anclas de confianza por inquilino o entorno. Distribuye los paquetes de CA a través de referencias controladas de Secret o ConfigMap. Los equipos de aplicaciones no deben recibir referencias a claves privadas de la plataforma. Durante la rotación, publica la nueva CA, observa una ventana de doble confianza, revoca la CA antigua y registra el momento y alcance de la activación.
6. Autorización multi-inquilino y conflictos
Los listeners en un Gateway compartido son un límite de plataforma. Una aplicación solo debe solicitar nombres de host y backends aprobados. El controlador debe rechazar nombres de host superpuestos, parentRefs no autorizados, backends de otros espacios de nombres y puertos o protocolos fuera de la política, exponiendo el motivo en el estado del recurso.
Valida ReferenceGrant, referencias a Secret y capacidades de GatewayClass en la admisión. Revisa los cambios de políticas en Git; en tiempo de ejecución, el controlador debe generar la configuración solo a partir de recursos aprobados. Ante un conflicto de rutas, mantén la última configuración buena conocida y reporta Accepted=False en lugar de permitir que el comportamiento de última escritura gana sobreescriba silenciosamente a otro inquilino.
7. Fallas, actualizaciones y observabilidad
Antes del despliegue, verifica que el controlador admita la versión estable de TLSRoute, el modo TLS seleccionado, la validación de clientes y backend TLS. Las actualizaciones de Gateway API pueden requerir la migración de recursos experimentales al v1 estable; reemplazar únicamente la URL de un YAML no es suficiente.
Monitorea coincidencias de SNI, condiciones de listeners y rutas, vencimiento de certificados, motivos de falla de certificados de cliente, errores de conexión al backend, latencia de propagación de configuración y métricas de handshake y tráfico por inquilino. Mantén consistentes los paquetes de confianza, el estado de las rutas y las comprobaciones de salud del backend durante la conmutación por error. Si el Gateway no está disponible, define una alternativa explícita de DNS o balanceador de carga en lugar de eludirlo con tráfico en texto sin formato.
8. Rúbrica y preguntas de seguimiento
Debe explicar
- Distinguir el enrutamiento SNI de TLSRoute de los límites de clave y texto sin formato de Passthrough y Terminate.
- Diseñar la confianza de CA, rotación, política de fallas y autorización entre espacios de nombres para frontend mTLS.
- Explicar las diferencias de capacidades del controlador, condiciones de recursos, migración en actualizaciones y observabilidad en lugar de solo pegar YAML.
Preguntas de seguimiento
- Si dos espacios de nombres reclaman el mismo SNI, ¿cómo evitas una sobrescritura silenciosa?
- Después de que el Gateway termina TLS, ¿cómo garantizas que el segundo salto mantenga un cifrado conforme a las normativas?
- Durante la rotación de CA del cliente, ¿cómo admites certificados duales limitando al mismo tiempo la vida útil máxima del certificado anterior?
Guía de puntuación
Una respuesta excelente conecta la propiedad de recursos, los límites de cifrado, la autorización y la evidencia en tiempo de ejecución: decide quién posee cada clave, rechaza conflictos con condiciones de estado y demuestra la política con métricas de handshake, certificados y backends.