Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Casos de uso de la seguridad del servicio (heredado)

En este documento, se describen casos de uso comunes de seguridad de Cloud Service Mesh. 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 del servicio, consulta Seguridad de los servicios de Cloud Service Mesh.

Este documento se aplica a las configuraciones que usan las APIs de balanceo de cargas. Este es un documento heredado.

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 la regla de reenvío global, el proxy HTTPS de destino y el mapa de URL. Estos recursos de la API de Compute Engine son necesarios para crear tu malla, pero no es necesario que los actualices a fin de 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 la malla de servicios de Cloud que aplicar la autenticación en el tráfico entrante.
  
  La selección de clientes de la malla de servicios de Cloud se basa en las etiquetas especificadas en la configuración de arranque del cliente de la malla de servicios de Cloud. 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 Cloud Service Mesh. 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 determinan si un cliente de la malla de servicios de Cloud recibe la configuración. Estas reglas se basan en los metadatos xDS a los que proporciona al plano de control, que en este caso, la malla de servicios en la nube.
  
  Puedes agregar etiquetas al cliente de Cloud Service Mesh de la siguiente manera:
  - Puedes especificar estos metadatos de forma manual en el archivo de arranque del cliente de Cloud Service Mesh.
  - 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 especifiquen un puerto que también se encuentra en el TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que se proporciona al cliente de la malla de servicios de Cloud en su 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. Cloud Service Mesh puede configurar tu plano de datos para que requiera tráfico de entrada a usan 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 en Google Cloud, podrías 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:

Asegura la conexión entre el cliente y el balanceador de cargas con en 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 Cloud Service Mesh para que tus clientes de Cloud Service Mesh finalicen HTTPS y le presentan certificados al cliente, que, en este caso, es el balanceador de cargas HTTP(S) global externo.

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 Cloud Service Mesh, configuras varios recursos de la API de Compute Engine. Estos recursos son independientes de los recursos que configuras para el balanceador de cargas. En otras palabras, debes crear dos conjuntos de recursos de API de Compute Engine (regla de reenvío global, proxy de destino, mapa de URL y servicios de backend globales) con distintos esquemas de balanceo de cargas:

Un conjunto de recursos configura el balanceador de cargas, que tiene el esquema de balanceo de cargas INTERNAL_MANAGED.
El otro conjunto de recursos configura Cloud Service Mesh, que tiene el esquema de balanceo de cargas INTERNAL_SELF_MANAGED.

En el paso 3, configura Cloud Service Mesh para que tus clientes de Cloud Service Mesh 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 una política de TLS del servidor: configura terminationTls en transportAuthentication.
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 Cloud Service Mesh.

Debido a que el balanceador de cargas de aplicaciones externo ya está configurado para iniciar las conexiones TLS a los servicios de tu malla, Cloud Service Mesh solo necesita configurar los clientes de la malla de servicios de Cloud para que finalicen 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 cambio, hay un proxy del medio en el perímetro de la malla y enruta el tráfico a los servicios dentro de ella, según en la configuración que recibe de Cloud Service Mesh. 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 Cloud Service Mesh para finalizar HTTPS y presentan certificados de la siguiente manera:

Crea una regla de reenvío global y un proxy HTTPS de destino a fin de representar la ruta para el tráfico de entrada a la malla.
Adjunta el mapa de URL existente para tu malla a este proxy HTTPS de destino. El mapa de URL ya contiene referencias a los diversos servicios de backend globales de la malla, en función de la configuración proporcionada cuando configuraste la malla y mTLS.
Crea una política de TLS para el servidor: configura serverCertificate.
Adjunta el recurso de la política de TLS del servidor a tu proxy HTTPS de destino.

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 proceso anterior cuando configuras la regla de reenvío global, debes proporcionar un dirección IP diferente (en este ejemplo, 10.0.0.2) a la que se proporcionó cuando configura la malla (en este ejemplo, la dirección de malla es 10.0.0.1). Clientes que se comunican a través de un plano de datos xDS configurado en la malla de servicios de Cloud puede 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 Cloud Service Mesh.

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 10.0.0.2 (VIP).
El proyecto de servicios 2 contiene una malla de servicios configurada por Cloud Service Mesh.

El proyecto de servicio 2 puede tener su propia puerta de enlace de entrada o no.
Cloud Service Mesh configura los clientes de Cloud Service Mesh en cada servicio en un proyecto final. 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 de servicios de Cloud Service Mesh solo se admite con en GKE. No puedes implementar la seguridad del servicio con Compute Engine.

¿Qué sigue?

Para configurar la seguridad de los servicios de Cloud Service Mesh con proxies de Envoy, consulta Configura la seguridad de los servicios de Cloud Service Mesh con Envoy (heredado).
Para configurar la seguridad del servicio de Cloud Service Mesh con aplicaciones de gRPC sin proxy, Consulta Configura la seguridad de los servicios de Cloud Service Mesh con gRPC sin proxy (heredado).