Entrevista de Backend: ¿Cómo utilizarías BackendTLSPolicy de Gateway API?

Planteamiento y contexto

Un Gateway de clúster acepta HTTPS externo y reenvía solicitudes a un Service interno que solo acepta TLS. Explica cómo usar BackendTLSPolicy de Gateway API para configurar TLS upstream, validar certificados y nombres de host, y gestionar políticas inválidas, referencias entre namespaces y reversiones (rollback).

Qué está evaluando el entrevistador

• Distinguir la terminación de TLS del cliente del origen de TLS de Gateway al backend.
• Comprender que la directiva se asocia a un Service mediante una referencia de destino y reporta su estado a través de la implementación.
• Explicar CAs, nombres de servidor, certificados de cliente y el riesgo de omitir la verificación.
• Considerar la autorización entre namespaces, la compatibilidad, la observabilidad, la reversión y la migración gradual.

Preguntas de aclaración para hacer

1. ¿El TLS termina en el Gateway y se reinicia, o pasa de extremo a extremo? ¿Qué nombre de servicio está en el SAN del certificado del backend?
2. ¿Qué namespace es propietario de la CA, el certificado de cliente y la clave privada, y se requiere un ReferenceGrant u otra autorización?
3. ¿La implementación de Gateway admite la versión actual de BackendTLSPolicy y el tipo de Route de destino?
4. ¿Cómo se observará, aislará y revertirá el tráfico durante la rotación de certificados, una directiva inválida o una interrupción del TLS del backend?

Una respuesta de 30 segundos

Separaría los dos tramos de TLS: la terminación del cliente al Gateway y el TLS upstream del Gateway al Service. BackendTLSPolicy se asocia al Service y declara el material de validación más la identidad opcional del cliente; la implementación debe reportar si la directiva es válida. Antes del despliegue verificaría la CA, el nombre del servidor, el puerto, la autorización entre namespaces y el soporte de la implementación, sin omitir nunca las comprobaciones de certificados. Haría un despliegue canary en un backend, monitorearía el estado de la directiva, los errores de handshake y la expiración, y prepararía una reversión reversible.

Análisis detallado paso a paso

1. Definir el límite de TLS

La guía de TLS de Gateway API ubica la configuración de TLS upstream en una BackendTLSPolicy asociada a un Service. Después de la terminación de TLS del cliente, el Gateway actúa como un cliente TLS hacia el backend; el certificado del backend debe validarse contra el material de confianza configurado y su nombre de servidor debe coincidir con la identidad del certificado. El certificado del listener externo no es la configuración de validación del backend.

2. Diseñar la asociación y el material de validación

La referencia de destino de la directiva apunta a un Service. La validación puede utilizar referencias a certificados de CA o la opción de CA conocida definida por la especificación. Si el backend requiere mutual TLS, configura un certificado y clave de cliente y restringe el acceso al Secret. Este ejemplo simplificado es para discutir las relaciones entre campos; verifica la versión de la API y los campos admitidos para la implementación:

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
  name: payments-upstream-tls
spec:
  targetRefs:
    - group: ""
      kind: Service
      name: payments
  validation:
    hostname: payments.internal.example
    wellKnownCACertificates: System

Antes de la implementación, inspecciona el estado de la directiva, los objetos referenciados y el motivo de invalidez del controlador; la creación del objeto por sí sola no demuestra que la directiva esté activa.

3. Gestionar namespaces y rotación de certificados

Mantén explícito el límite de namespace entre la directiva y el Service de destino. Una referencia entre namespaces requiere el mecanismo de autorización admitido por la implementación; la capacidad del Gateway para alcanzar un Service no otorga permiso para leer su Secret. Rota los certificados con una ventana de superposición o una estrategia de doble CA, observa el éxito del handshake, luego retira el material antiguo y verifica que las conexiones se reconstruyan.

4. Observar, realizar canary y revertir

Haz canary primero en un Service o puerto. Registra el estado de la directiva, los fallos de handshake TLS, las discrepancias de nombres de backend, la expiración y los reintentos de conexión. Cuando una directiva se vuelve inválida, el comportamiento seguro es rechazar una conexión no segura y emitir un evento diagnosticable, no degradar silenciosamente a texto plano. La reversión restaura la última directiva o destino de ruta validado y preserva los registros de certificados y auditoría.

Respuesta modelo

Definiría primero las dos conexiones: el TLS externo termina en el Gateway, que luego se conecta al Service como un cliente TLS. BackendTLSPolicy se asocia a ese Service y declara la CA, el nombre del servidor y el certificado de cliente opcional; el estado del controlador es la señal principal de que la directiva es efectiva. Limitaría el acceso a Secrets y entre namespaces y verificaría el soporte de API y Route de la implementación. Un Service canary probaría los SANs de los certificados, la confianza de la CA, la rotación, los errores de handshake y la reconstrucción de conexiones. Nunca trataría la verificación deshabilitada como una solución. Las directivas inválidas o los fallos de certificado deben bloquear el tráfico inseguro, generar alertas y seguir un plan de reversión.

Errores comunes

• Configurar únicamente el certificado del cliente al Gateway y olvidar el origen del TLS upstream.
• Apuntar targetRef al objeto incorrecto o asumir que todos los controladores admiten la misma versión de la API.
• Confiar en una CA sin validar el nombre de servidor del certificado del backend.
• Ocultar problemas de CA, SAN o rotación omitiendo la verificación o recurriendo a texto plano.
• Permitir lecturas de Secret entre namespaces sin un límite de autorización y auditoría.
• Tratar la creación exitosa del recurso como una prueba, ignorando el estado, las métricas de handshake y los eventos del controlador.

Preguntas de seguimiento y respuestas

¿Cómo se relaciona BackendTLSPolicy con la terminación de TLS del cliente?

La terminación de TLS del cliente protege el tramo desde el navegador o emisor de la llamada hasta el Gateway; BackendTLSPolicy protege el tramo del Gateway al Service. Pueden utilizar diferentes certificados y dominios de confianza, por lo que la identidad y la rotación deben verificarse por separado.

¿Qué pasa si el nombre del certificado del backend no coincide?

Emite el certificado del backend para el nombre de servidor utilizado por el Gateway, o haz que el hostname de la directiva coincida con el SAN del certificado. No deshabilites la verificación de nombres; inspecciona el DNS, SNI, la nomenclatura del Service y la cadena de certificados.

¿Cómo liberas una directiva inválida?

Conecta el estado inválido a una alerta y a una compuerta de lanzamiento (release gate), detén la expansión del canary e inspecciona las referencias, el material de CA, los permisos de Secret y el soporte de la implementación. Continúa solo después de que el estado sea válido y los handshakes sean exitosos; una reversión de emergencia regresa a la última directiva validada.