Casos de uso de la seguridad del servicio

En este documento, se describen casos prácticos de seguridad comunes de Traffic Director. Usa esta información para ayudarte a determinar qué modelo de seguridad se adapta mejor a tus necesidades. En este documento, también se proporciona una descripción general de alto nivel de lo que necesitas configurar para cada caso de uso.

Para obtener una descripción general de la seguridad de los servicios, consulta Seguridad de los servicios de Traffic Director.

Habilita la TLS mutua para los servicios en la malla

En una malla de servicios, puedes habilitar la TLS mutua (mTLS) para que tanto el cliente como el servidor en una comunicación deban demostrar sus identidades y encriptar las comunicaciones.

Autenticación mutua de TLS (mTLS) en una malla de servicios (haz clic para ampliar)

En la siguiente sección, se omite el análisis de los recursos Mesh, Gateway y Route. Estos recursos de API son necesarios para crear la malla y enrutar el tráfico, pero no necesitas actualizarlos para habilitar mTLS.

El patrón anterior se puede lograr mediante la configuración de los siguientes recursos de la API de Compute Engine. En este diagrama, se usan proxies de sidecar. Sin embargo, en la configuración de una aplicación de gRPC sin proxy con mTLS, se usan los mismos recursos.

Recursos de la API de Compute Engine para mTLS dentro de una malla (haz clic para ampliar)

Para crear esta configuración, haz lo siguiente:

Crea una política de seguridad de la capa de transporte (TLS) para el cliente.
Crea una política de TLS para el servidor.
Actualiza el campo securitySettings de tus servicios de backend globales existentes para hacer referencia a la nueva política de TLS del cliente.
Crea una política para el extremo:
1. Haz referencia a la política de TLS del servidor en el campo server_tls_policy.
2. Define un EndpointMatcher para seleccionar los clientes de Traffic Director que deban aplicar la autenticación en el tráfico entrante.
  
  La selección de clientes de Traffic Director se realiza en función de las etiquetas especificadas en la configuración de arranque del cliente de Traffic Director. Estas etiquetas se pueden proporcionar de forma manual o se propagan automáticamente en función las etiquetas proporcionadas a tus implementaciones de Google Kubernetes Engine (GKE).
  
  En el diagrama anterior, las etiquetas "mesh-service":"true" se configuran en la política de extremo y en los clientes de Traffic Director. Puedes elegir las etiquetas que se adapten a tu implementación.
3. De forma opcional, define un TrafficPortSelector que aplique las políticas solo cuando se realicen solicitudes entrantes al puerto especificado en la entidad del plano de datos.

En el siguiente diagrama, se muestran los recursos de Compute Engine que configuras para mTLS, sin importar si usas Envoy o una aplicación de gRPC sin proxy.

En el siguiente diagrama, se muestra el flujo de tráfico y se enumeran los recursos de la API de Compute Engine que configuras para habilitar mTLS. El proxy de sidecar local que se encuentra junto con el Pod de GKE del servicio B es el extremo de la comunicación.

Recursos y flujo de tráfico de la API de Compute Engine para mTLS dentro de una malla (haz clic para ampliar)

La política del extremo hace lo siguiente:

Selecciona un conjunto de extremos mediante un comparador de extremos y, de forma opcional, los puertos de esos extremos.
1. El comparador de extremos te permite especificar reglas que determinen si un cliente de Traffic Director recibirá la configuración. Estas reglas se basan en los metadatos de xDS que la entidad del plano de datos proporciona al plano de control, en este caso, Traffic Director.
  
  Puedes agregar etiquetas al cliente de Traffic Director de la siguiente manera:
  - Puedes especificar estos metadatos de forma manual en el archivo de arranque del cliente de Traffic Director.
  - Como alternativa, los metadatos se pueden propagar de forma automática cuando usas GKE. Para ello, agrega los pares clave-valor en la sección env de los archivos demo_server.yaml o demo_client.yaml. Estos valores se proporcionan en la guía de configuración de Envoy y la guía de configuración de gRPC sin proxy.
    
    Por ejemplo, solo con Envoy, puedes prefijar la clave con el prefijo ISTIO_META_. Los nombres de las variables de entorno del proxy que comienzan con ISTIO_META_ se incluyen en el arranque generado y se envían al servidor de xDS.
```
- name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'
```
2. Si especificas un puerto, las políticas a las que se hace referencia en la política del extremo solo se aplicarán en las solicitudes entrantes en las que se especifique el mismo puerto. Si no especificas un puerto, las políticas se aplican en las solicitudes entrantes que especifican un puerto que también se encuentra en el campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que se proporciona al cliente de Traffic Director en la información de arranque.
Hace referencia a la TLS del cliente, la TLS del servidor y las políticas de autorización que configuran los extremos en los que se resuelven las solicitudes.

La configuración de modos de TLS que no son compatibles puede provocar una interrupción en las comunicaciones. Por ejemplo, si se configura OPEN en el servicio de backend global o se deja vacío el campo de la política de TLS del cliente y se establece MTLS como el valor de la política de TLS del servidor en la política del extremo, provocará que los intentos de comunicación fallen. Esto se debe a que los extremos configurados para aceptar solo intentos de rechazo de mTLS deben establecer canales de comunicación sin autenticar.

Ten en cuenta la distinción entre una política de TLS del cliente y una política de TLS del servidor vinculada a un servicio de backend global y a una política del extremo, respectivamente:

La política de TLS del cliente se aplica al servicio de backend global. Le indica al cliente con o sin proxy de Envoy qué modo de TLS, identidad y enfoque de validación de intercambio de tráfico debe usar cuando se dirige al servicio.
La política de TLS del servidor se adjunta a la política del extremo. Le indica al servidor qué modo de TLS, identidad y método de validación de intercambio de tráfico debe usar para las conexiones entrantes.

Habilita TLS en una puerta de enlace de entrada

Después de configurar mTLS para las comunicaciones en la malla, es posible que desees proteger el tráfico que ingresa a la malla, conocido como tráfico de entrada. Traffic Director puede configurar el plano de datos para que solicite que el tráfico de entrada use canales de comunicación encriptados con TLS.

Para lograr este objetivo, elige una de las siguientes opciones de arquitectura:

Los servicios de la malla finalizan TLS para el tráfico de un balanceador de cargas. En este modelo, cada servicio de la malla se configura como un backend en la configuración del balanceador de cargas, en particular, en el mapa de URL del balanceador de cargas.
Una puerta de enlace de entrada finaliza TLS para el tráfico de un balanceador de cargas antes de reenviar el tráfico a servicios en la malla. En este modelo, un servicio dedicado de la malla, la puerta de enlace de entrada, se configura como un backend en la configuración del balanceador de cargas, en particular, en el mapa de URL del balanceador de cargas.

Ambas opciones se explican en esta sección.

Los servicios de la malla finalizan TLS para el tráfico de un balanceador de cargas

Si deseas que tus servicios estén disponibles para clientes fuera de Google Cloud, puedes usar un balanceador de cargas de aplicaciones externo. Los clientes envían tráfico a la dirección IP virtual (VIP) Anycast global del balanceador de cargas, que reenvía ese tráfico a los servicios en la malla. Esto significa que hay dos conexiones cuando un cliente externo necesita acceder a un servicio en la malla.

TLS a un servicio en la malla (haz clic para ampliar)

El mismo patrón se aplica cuando usas un balanceador de cargas de aplicaciones interno. El tráfico de los clientes internos primero llega al balanceador de cargas, que luego establece una conexión con el backend.

Para proteger ambas conexiones, haz lo siguiente:

Protege la conexión entre el cliente y el balanceador de cargas mediante un balanceador de cargas de aplicaciones externo.
Configura el balanceador de cargas para que use los protocolos HTTPS o HTTP/2 cuando intente establecer una conexión con los servicios en la malla.
Configura Traffic Director para que tus clientes de Traffic Director finalicen HTTPS y presenten certificados al cliente, que en este caso es el balanceador de cargas.

Para obtener más información sobre los pasos 1 y 2, consulta Configura un balanceador de cargas de HTTPS externo multirregional y basado en el contenido.

Cuando configuras la seguridad de Traffic Director, configuras varios recursos de la API de Compute Engine. Estos recursos son independientes de los recursos que configuras para el balanceador de cargas. Debes crear un conjunto de recursos de la API de Compute Engine (regla de reenvío global, proxy de destino, mapa de URL y servicios de backend globales) para el balanceador de cargas y configurar Traffic Director con las APIs de enrutamiento de servicios. Además, en el recurso del servicio de backend, el balanceador de cargas tiene el esquema de balanceo de cargas INTERNAL_MANAGED y Traffic Director tiene el esquema de balanceo de cargas INTERNAL_SELF_MANAGED.

En el paso 3, configura Traffic Director para que tus clientes de Traffic Director finalicen HTTPS y presenten certificados a los clientes.

Recursos de la API de Compute Engine para TLS para el servicio en la malla. — Recursos de la API de Compute Engine para TLS para el servicio en la malla (haz clic para ampliar)

En esta sección, harás lo siguiente:

Crea un serverTlsPolicy: configura serverCertificate en el recurso serverTlsPolicy.
Crea una política para el extremo:
1. Haz referencia a la política de TLS del servidor en el campo authentication.
2. Define un EndpointMatcher para seleccionar las entidades del plano de datos de xDS que deben aplicar la autenticación en el tráfico entrante.
3. De forma opcional, define un TrafficPortSelector que aplique las políticas solo cuando se realicen solicitudes entrantes al puerto especificado en el cliente de Traffic Director.

Debido a que el balanceador de cargas de aplicaciones externo ya está configurado para iniciar conexiones TLS a los servicios en tu malla, Traffic Director solo necesita configurar tus clientes de Traffic Director para finalizar las conexiones TLS.

Una puerta de enlace de entrada finaliza TLS para el tráfico de un balanceador de cargas antes de reenviar el tráfico a servicios en la malla

Si solo deseas exponer una puerta de enlace de entrada a tu balanceador de cargas, puedes usar el patrón de implementación de la puerta de enlace de entrada. En este patrón, el balanceador de cargas no se dirige directamente a los servicios en la malla. En su lugar, un proxy intermedio se encuentra en el perímetro de la malla y enruta el tráfico a los servicios dentro de la malla, en función de la configuración que recibe de Traffic Director. El proxy intermedio puede ser un proxy de Envoy que implementaste en instancias de máquinas virtuales (VM) en un grupo de instancias administrado de Compute Engine.

TLS a una puerta de enlace de entrada con mTLS dentro de una malla (haz clic para ampliar)

Desde la perspectiva de la seguridad, configura la puerta de enlace de entrada para que finalice TLS y, de manera opcional, configura las conexiones dentro de la malla a fin de que estén protegidas por mTLS. Estos incluyen conexiones entre la puerta de enlace de entrada y los servicios en tu malla, y las conexiones entre los servicios en tu malla.

Desde una perspectiva de configuración, debes hacer lo siguiente:

Configura la malla de servicios y habilita mTLS para las comunicaciones dentro de la malla (como se explicó antes).
Configura el balanceador de cargas para enrutar el tráfico a la puerta de enlace de entrada y, luego, iniciar conexiones mediante el protocolo HTTPS (como se explicó antes).
Crea un conjunto de recursos de la API de Compute Engine que representen a la puerta de enlace de entrada y su política de TLS del servidor.

En el tercer paso, configura Traffic Director para que finalice HTTPS y presente certificados de la siguiente manera:

Crea un recurso Mesh para representar la malla.
Crea un recurso Route que apunte a los servicios de backend globales correctos y adjunta el recurso Route al recurso Mesh.
Crea una política de TLS para el servidor: configura serverCertificate.
Crea un recurso Gateway para representar la puerta de enlace de entrada administrada por Traffic Director.
Adjunta el recurso de política de TLS del servidor al recurso Gateway.

El patrón de la puerta de enlace de entrada es muy útil en especial en organizaciones grandes que usan VPC compartida. En esta configuración, es posible que un equipo solo permita el acceso a sus servicios a través de una puerta de enlace de entrada. En el diagrama anterior, cuando configuras la regla de reenvío global para el balanceador de cargas, proporcionas una dirección IP diferente (en este ejemplo, 10.0.0.2) a la que se proporciona cuando configuras la malla (en este ejemplo, la dirección de la malla es 10.0.0.1). Los clientes que se comunican a través de una entidad de plano de datos de xDS configurada con Traffic Director pueden usar esta dirección para acceder a la puerta de enlace de entrada.

A modo de ejemplo, supongamos el siguiente objeto :

Dos proyectos de servicio (1 y 2), ambos conectados a la misma red de VPC compartida.
El proyecto de servicio 1 contiene una malla de servicio que configura Traffic Director.

El proyecto de servicio 1 configuró una malla y una puerta de enlace de entrada. Se puede acceder a esta puerta de enlace de entrada en la dirección/VIP 10.0.0.2.
El proyecto de servicio 2 contiene una malla de servicio que configura Traffic Director.

El proyecto de servicio 2 puede tener su propia puerta de enlace de entrada o no.
Traffic Director configura los clientes de Traffic Director en cada proyecto de servicio. Los clientes se inician para usar la misma red.

Con esta configuración, los clientes de la malla del proyecto de servicio 2 pueden comunicarse con la puerta de enlace de entrada en el proyecto de servicio 1 mediante la VIP 10.0.0.2. Esto permite que los propietarios del proyecto de servicio 1 configuren el enrutamiento, la seguridad y otras políticas específicas del tráfico que ingresa a la malla. De hecho, los propietarios del proyecto de servicio 1 pueden indicarle a otros que los clientes de tu malla pueden acceder a mis servicios en 10.0.0.2.

Limitaciones

La seguridad del servicio de Traffic Director solo es compatible con GKE. No puedes implementar la seguridad del servicio con Compute Engine.

¿Qué sigue?

Para configurar la seguridad del servicio de Traffic Director con proxies de Envoy, consulta Configura la seguridad del servicio de Traffic Director con Envoy.
Si deseas configurar la seguridad del servicio de Traffic Director con aplicaciones de gRPC sin proxy, consulta Configura la seguridad del servicio de Traffic Director con gRPC sin proxy.