Casos prácticos de seguridad de servicios

En este documento se describen casos prácticos habituales de seguridad de Cloud Service Mesh. Usa esta información para determinar qué modelo de seguridad se adapta mejor a tus necesidades. En este documento también se ofrece una descripción general de lo que debe configurar en cada caso práctico.

Para obtener una descripción general de la seguridad de los servicios, consulta Seguridad de los servicios de Cloud Service Mesh.

Habilitar TLS mutuo para los servicios de la malla

En una malla de servicios, puedes habilitar TLS mutuo (mTLS) para que tanto el cliente como el servidor de una comunicación tengan que demostrar su identidad y cifrar las comunicaciones.

Autenticación TLS mutuo (mTLS) en una malla de servicios (haz clic en la imagen para ampliarla)

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

El patrón anterior se puede conseguir configurando los siguientes recursos de la API Compute Engine. En este diagrama se usan proxies sidecar, pero para configurar una aplicación gRPC sin proxy con mTLS se usan los mismos recursos.

Recursos de la API de Compute Engine para mTLS en una malla (haz clic en la imagen para ampliarla)

Para crear este modelo, siga estos pasos:

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

4. Crea una política de endpoint:

   1. Haga referencia a la política 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 basa en las etiquetas especificadas en la configuración de arranque del cliente de Cloud Service Mesh. Estas etiquetas se pueden proporcionar manualmente o rellenar automáticamente en función de 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 endpoint y en los clientes de Cloud Service Mesh. Puedes elegir las etiquetas que se adapten a tu implementación.

   3. Opcionalmente, defina un TrafficPortSelector que aplique las políticas solo cuando se hagan solicitudes entrantes al puerto especificado en la entidad del plano de datos.

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

Recursos de la API de Compute Engine para mTLS en una malla (haz clic en la imagen para ampliarla)

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

Recursos de la API de Compute Engine y flujo de tráfico para mTLS en una malla (haz clic en la imagen para ampliarla)

La política de endpoint hace lo siguiente:

1. Selecciona un conjunto de endpoints mediante un matcher de endpoints y, opcionalmente, puertos en esos endpoints.

   1. El matcher de endpoints te permite especificar reglas que determinan 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 añadir etiquetas al cliente de Cloud Service Mesh de la siguiente manera:

      • Puedes especificar manualmente estos metadatos en el archivo de arranque del cliente de Cloud Service Mesh.

      • También puedes rellenar los metadatos automáticamente cuando uses GKE añadiendo los pares clave-valor a la sección envdemo_server.yaml o demo_client.yaml de los archivos. Estos valores se proporcionan en la guía de configuración de Envoy y en la guía de configuración de gRPC sin proxy.

        Por ejemplo, con Envoy, puedes añadir el prefijo ISTIO_META_ a la clave. Los nombres de las variables de entorno de proxy que empiezan por ISTIO_META_ se incluyen en el bootstrap generado y se envían al servidor xDS.

        - name: ISTIO_META_app
          value: 'review'
        - name: ISTIO_META_version
          value: 'canary'
        

   2. Si especifica un puerto, las políticas a las que se hace referencia en la política de endpoint solo se aplicarán a las solicitudes entrantes que especifiquen el mismo puerto. Si no especificas un puerto, las políticas se aplican a las solicitudes entrantes que especifican un puerto que también está en el campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que se proporciona al cliente de Cloud Service Mesh en su información de arranque.

2. Hace referencia a las políticas de TLS de cliente, TLS de servidor y autorización que configuran los endpoints a los que se resuelven las solicitudes.

Si se configuran modos TLS incompatibles, se pueden interrumpir las comunicaciones. Por ejemplo, si se define OPEN en el servicio backend global o se deja vacío el campo de la política de TLS del cliente y se define MTLS como valor de la política de TLS del servidor en la política del endpoint, se producirán errores en los intentos de comunicación. Esto se debe a que los endpoints configurados para aceptar solo mTLS rechazan los intentos de establecer canales de comunicación no autenticados.

Ten en cuenta la diferencia entre una política de TLS de cliente y una política de TLS de servidor asociadas a un servicio de backend global y a una política de endpoint, respectivamente:

• La política de TLS del cliente se aplica al servicio de backend global. Indica al proxy de Envoy o al cliente sin proxy qué modo TLS, identidad y método de validación del peer debe usar al dirigirse al servicio.
• La política TLS del servidor está asociada a la política del endpoint. Indica al servidor qué modo TLS, identidad y método de validación de pares debe usar para las conexiones entrantes.

Habilitar TLS en una pasarela de entrada

Después de configurar mTLS para las comunicaciones en la malla, puede que quieras proteger el tráfico que entra en tu malla, conocido como tráfico de entrada. Cloud Service Mesh puede configurar tu plano de datos para que el tráfico de entrada use canales de comunicación cifrados con TLS.

Para conseguirlo, elige una de las siguientes opciones de arquitectura:

• Los servicios de la malla terminan TLS para el tráfico procedente de un balanceador de carga. En este modelo, cada servicio de la malla se configura como un backend en la configuración del balanceador de carga, concretamente en el mapa de URLs del balanceador de carga.
• Una pasarela de entrada finaliza el protocolo TLS del tráfico de un balanceador de carga antes de reenviar el tráfico a los servicios de la malla. En este modelo, un servicio dedicado en la malla, la puerta de enlace de entrada, se configura como backend en la configuración del balanceador de carga, concretamente en el mapa de URLs del balanceador de carga.

Ambas opciones se explican en esta sección.

Los servicios de la malla terminan TLS para el tráfico de un balanceador de carga

Si quieres que tus servicios estén disponibles para clientes que no se encuentren enGoogle Cloud, puedes usar un balanceador de carga de aplicación externo. Los clientes envían tráfico a la dirección IP virtual Anycast global del balanceador de carga, que reenvía ese tráfico a los servicios de tu malla. Esto significa que hay dos conexiones cuando un cliente externo necesita acceder a un servicio de la malla.

TLS a un servicio de la malla (haz clic en la imagen para ampliarla)

Se aplica el mismo patrón cuando usas un balanceador de carga de aplicación interno. El tráfico de los clientes internos llega primero al balanceador de carga, que 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 carga mediante un balanceador de carga de aplicación externo.
2. Configura el balanceador de carga para que use los protocolos HTTPS o HTTP/2 cuando intente establecer una conexión con los servicios de la malla.
3. Configura Cloud Service Mesh para que tus clientes de Cloud Service Mesh terminen la conexión HTTPS y presenten certificados al cliente, que en este caso es el balanceador de carga.

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

Cuando configuras la seguridad de Cloud Service Mesh, configuras varios recursos de la API Compute Engine. Estos recursos son independientes de los que configures para el balanceador de carga. Crea un conjunto de recursos de la API Compute Engine (regla de reenvío global, proxy de destino, mapa de URLs y servicios de backend globales) para el balanceador de carga y configura Cloud Service Mesh con las APIs de enrutamiento de servicios. Además, en el recurso de servicio de backend, el balanceador de carga tiene el esquema de balanceo de carga INTERNAL_MANAGED y Cloud Service Mesh tiene el esquema de balanceo de carga INTERNAL_SELF_MANAGED.

En el paso 3, configura Cloud Service Mesh para que tus clientes de Cloud Service Mesh terminen HTTPS y presenten certificados a los clientes.

Recursos de la API de Compute Engine para TLS a servicio en malla (haz clic en la imagen para ampliarla)

En este modelo, debes hacer lo siguiente:

1. Crea un serverTlsPolicy: configura serverCertificate en el recurso serverTlsPolicy.
2. Crea una política de endpoint:
   1. Haga referencia a la política 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 al tráfico entrante.
   3. También puedes definir un TrafficPortSelector que aplique las políticas solo cuando se hagan solicitudes entrantes al puerto especificado en el cliente de Cloud Service Mesh.

Como el balanceador de carga de aplicaciones externo ya está configurado para iniciar conexiones TLS a los servicios de tu malla, Cloud Service Mesh solo tiene que configurar tus clientes de Cloud Service Mesh para que finalicen las conexiones TLS.

La pasarela de entrada finaliza la conexión TLS del tráfico procedente de un balanceador de carga antes de reenviar el tráfico a los servicios de la malla.

Si solo quieres exponer una pasarela de entrada a tu balanceador de carga, puedes usar el patrón de implementación de pasarela de entrada. En este patrón, el balanceador de carga no se dirige directamente a los servicios de tu malla. En su lugar, un proxy intermedio se sitúa en el límite de tu malla y dirige el tráfico a los servicios 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 hayas implementado en instancias de máquina virtual de un grupo de instancias gestionado de Compute Engine.

TLS a una pasarela de entrada con mTLS en una malla (haz clic para ampliar)

Desde el punto de vista de la seguridad, puedes configurar la puerta de enlace de entrada para que finalice TLS y, a continuación, configurar opcionalmente las conexiones de tu malla para que estén protegidas por mTLS. Esto incluye las conexiones entre la puerta de enlace de entrada y los servicios de la malla, así como las conexiones entre los servicios de la malla.

Desde el punto de vista de la configuración, debes hacer lo siguiente:

1. Configura tu malla de servicios y habilita mTLS para las comunicaciones dentro de la malla (como se ha explicado anteriormente).
2. Configura el balanceador de carga para que dirija el tráfico a la puerta de enlace de entrada e inicie las conexiones mediante el protocolo HTTPS (como se ha explicado anteriormente).
3. Crea un conjunto de recursos de la API de Compute Engine que representen la puerta de enlace de entrada y su política de TLS de servidor.

En el tercer paso, configura Cloud Service Mesh para que finalice HTTPS y presente los certificados de la siguiente manera:

1. Crea un recurso Mesh para representar la malla.

2. Crea un recurso Route que apunte a los servicios de backend globales correctos y adjunta el recurso Route al recurso Mesh.

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

4. Crea un recurso Gateway para representar la pasarela de entrada gestionada de Cloud Service Mesh.

5. Asocia el recurso de política TLS de servidor al recurso Gateway.

El patrón de pasarela de entrada es especialmente útil en organizaciones grandes que usan VPC compartida. En este caso, un equipo solo podría permitir el acceso a sus servicios a través de una pasarela de entrada. En el diagrama anterior, cuando configuras la regla de reenvío global del balanceador de carga, proporcionas una dirección IP diferente (en este ejemplo, 10.0.0.2) de la que proporcionas al configurar 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 xDS configurada con Cloud Service Mesh pueden usar esta dirección para acceder a la puerta de enlace de entrada.

Por ejemplo, supongamos lo siguiente:

• Dos proyectos de servicio (1 y 2), ambos asociados a la misma red de VPC compartida.

• El proyecto de servicio 1 contiene una malla de servicios configurada por Cloud Service Mesh.

  El proyecto de servicio 1 ha configurado una malla y una pasarela de entrada. Se puede acceder a esta puerta de enlace de entrada en la dirección o VIP 10.0.0.2.

• El proyecto de servicio 2 contiene una malla de servicios configurada por Cloud Service Mesh.

  El proyecto de servicio 2 puede tener o no su propia pasarela de entrada.

• 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 del proyecto de servicio 1 mediante la 10.0.0.2 VIP. De esta forma, los propietarios del proyecto de servicio 1 pueden configurar el enrutamiento, la seguridad y otras políticas específicas del tráfico que entra en la malla. De hecho, los propietarios del proyecto de servicio 1 pueden decirles a otros que los clientes de su malla pueden acceder a mis servicios en 10.0.0.2.

Limitaciones

La seguridad de los servicios de Cloud Service Mesh solo se admite en GKE. No puedes implementar la seguridad de los servicios con Compute Engine.

Siguientes pasos

• Para configurar la seguridad de los servicios de Cloud Service Mesh con proxies de Envoy, consulta Configurar la seguridad de los servicios de Cloud Service Mesh con Envoy.
• Para configurar la seguridad de los servicios de Cloud Service Mesh con aplicaciones gRPC sin proxy, consulta el artículo Configurar la seguridad de los servicios de Cloud Service Mesh con gRPC sin proxy.