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 de los servicios, 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.

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.

Para crear esta configuración, haz lo siguiente:

1. Crea una política de seguridad de la capa de transporte (TLS) para el cliente.
2. Crea una política de TLS para el servidor.
3. Actualiza el campo securitySettings de tus servicios de backend globales existentes para hacer referencia a la nueva política de TLS del cliente.

4. 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 Cloud Service Mesh que deben aplicar la autenticación en el tráfico entrante.

      La selección de clientes de Cloud Service Mesh se realiza en función de las etiquetas especificadas en la configuración de arranque del cliente de Cloud Service Mesh. 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.

La política del extremo hace lo siguiente:

1. 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 Cloud Service Mesh recibe 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, Cloud Service Mesh.

      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 especifican un puerto que también se encuentra en el campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que se proporciona al cliente de Cloud Service Mesh en la información de arranque.

2. 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 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 los 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.

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:

1. Protege la conexión entre el cliente y el balanceador de cargas mediante un balanceador de cargas de aplicaciones externo.
2. 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.
3. Configura Cloud Service Mesh para que tus clientes de Cloud Service Mesh 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 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.

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

1. Crea una política de TLS del servidor: configura terminationTls en transportAuthentication.
2. 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 conexiones de TLS con servicios en la malla, Cloud Service Mesh solo necesita configurar los clientes de Cloud Service Mesh para finalizar las conexiones de 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 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.

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:

1. Configura la malla de servicios y habilita mTLS para las comunicaciones dentro de la malla (como se explicó antes).
2. 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).
3. 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 que finalice HTTPS y presente certificados de la siguiente manera:

1. 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.

2. 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.

3. Crea una política de TLS para el servidor: configura serverCertificate.

4. 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 diagrama anterior, cuando configuras la regla de reenvío global, 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 por Cloud Service Mesh 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 servicios 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 servicio 2 contiene una malla de servicios que configura 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 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 Cloud Service Mesh solo es compatible con GKE. No puedes implementar la seguridad del servicio con Compute Engine.

¿Qué sigue?

• Para configurar la seguridad del servicio de Cloud Service Mesh con proxies de Envoy, consulta Configura la seguridad del servicio 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 del servicio de Cloud Service Mesh con gRPC sin proxy (heredado).