Seguridad del servicio (heredada)

En este documento, se proporciona una descripción general de la seguridad del servicio con Cloud Service Mesh las APIs de balanceo de cargas. Está dirigido a los usuarios de Cloud Service Mesh que deseen agregar autenticación, encriptación y autorización a sus implementaciones. Esta documento, se da por sentado que estás familiarizado Malla de servicios en la nube con Envoy y con aplicaciones de gRPC sin proxy.

Este documento se aplica a las configuraciones que usan las APIs de balanceo de cargas. Si usas las APIs de enrutamiento de servicios, consulta Seguridad del servicio. Este es un documento heredado.

Cloud Service Mesh te permite proteger las comunicaciones de servicio a servicio en tu de la red de VPC. En la malla, cada servicio tiene una identidad. Las siguientes funciones ayudan a establecer comunicaciones seguras:

  • La autenticación y encriptación que usan la seguridad de la capa de transporte (TLS) y la TLS mutua (mTLS) para Cloud Service Mesh con Envoy y Cloud Service Mesh con aplicaciones de gRPC sin proxy Las políticas de TLS del cliente y las políticas de TLS del servidor controlan si los servicios necesitan demostrar sus identidades entre sí y usar canales de comunicación encriptados.
  • La autorización, en función de las características del cliente y la solicitud. Las políticas de autorización controlan si un servicio tiene permiso para acceder a otro servicio y qué acciones se permiten.

El uso de certificados y claves proporcionados por una autoridad certificadora (CA) privada, Certificate Authority Service de Google, facilita la tarea de mantener la seguridad del servicio. El servicio de CA proporciona certificados de malla de GKE. Los certificados de la malla de GKE y Cloud Service Mesh te permite implementarlos automáticamente certificados de Google y hacer que las cargas de trabajo los usen. Modificas tus Pods para permitir que las cargas de trabajo reciban y usen credenciales de mTLS. Servicio de la malla de servicios de Cloud La seguridad está disponible solo para las cargas de trabajo basadas en GKE.

En las arquitecturas modernas basadas en microservicios, los servicios más pequeños y especializados reemplazan a las aplicaciones monolíticas grandes. Las llamadas de servicio se comunican entre sí a través de la red. Estas llamadas, que eran llamadas en proceso en aplicaciones monolíticas, presentan desafíos de seguridad, por lo que es mejor autenticarlas, encriptarlas y autorizarlas. Estos pasos admiten el principio de confianza cero, en el que se supone que todo el tráfico de red está en riesgo, sin importar si el tráfico se origina dentro o fuera de la red.

El patrón de diseño de la malla de servicios separa cualquier complejidad relacionada con las comunicaciones entre servicios de la lógica empresarial. En cambio, el plano de datos controla esta complejidad. Además de reducir la complejidad de la aplicación, el patrón de diseño de malla de servicios habilita patrones de seguridad que, de otro modo, serían difíciles de implementar y administrar.

En este modelo, los archivos adicionales de gRPC o Envoy sin proxy autentican y encriptan las comunicaciones de forma segura mediante la información de configuración de Cloud Service Mesh y los certificados de un grupo de servicios de AC.

Estas funciones de seguridad facilitan el proceso de implementación de la malla de servicios de Cloud proporcionando lo siguiente:

  • Aprovisionamiento automático de claves y certificados para todos los servicios de tu malla
  • Rotación automática de claves y certificados para proporcionar seguridad adicional
  • Integración con Google Kubernetes Engine (GKE) para usar todas sus capacidades, como las etiquetas y los descriptores de implementación
  • Alta disponibilidad de los servicios administrados de Google, incluidos Cloud Service Mesh y Grupos de autoridades certificadoras privadas administradas por CA Service.
  • Seguridad vinculada a Google Identity and Access Management (IAM): autorización del servicio basada en cuentas de servicio de Google autorizadas
  • Interoperabilidad sin interrupciones con las cargas de trabajo basadas en Envoy y sin proxy. Por ejemplo, un servicio puede estar detrás de un proxy de Envoy, pero el cliente usa la seguridad de la malla de servicios sin proxy de gRPC. Por el contrario, un servicio puede estar detrás de la seguridad de la malla de servicios sin proxy de gRPC, pero el cliente usa un proxy de Envoy.

Comunicaciones de servicio a servicio seguras

Cloud Service Mesh proporciona autorización y seguridad de servicio a servicio con encriptación y autenticación que usan TLS. Las políticas de TLS del cliente y las políticas de TLS del servidor permiten que los servicios hagan lo siguiente:

  • Confirmar y validar sus identidades
  • Encriptar las sesiones de comunicación mediante TLS o mTLS

En una malla de servicios, el plano de datos controla este tipo de seguridad para que las aplicaciones no necesiten realizar aprovisionamientos especiales para ser seguras.

Las políticas de autorización te permiten rechazar o permitir el acceso de acuerdo con las reglas que defines.

Usa TLS para la encriptación

Cuando un servicio llama a otro servicio mediante el protocolo HTTP, HTTP/2 o gRPC, el tráfico que pasa por la red se encuentra en texto sin formato. Este tráfico puede estar sujeto a ataques de intermediarios, en los que un atacante intercepta el tráfico y manipula o inspecciona su contenido.

Para mitigar este posible problema, puedes usar HTTP, HTTP/2 o gRPC mediante TLS con Cloud Service Mesh. Cuando usas estos protocolos en TLS, el tráfico entre el cliente y el servidor se encripta mediante TLS basada en el certificado del servidor. El tráfico ya no es texto sin formato, lo que reduce la probabilidad de que un atacante lo intercepte y manipule o inspeccione su contenido.

Usa TLS para la autenticación

Cuando un servicio llama a otro, ten en cuenta las siguientes preguntas:

  • ¿Cómo sabe un cliente que recibe una respuesta del servidor correcto en lugar de una respuesta de un impostor? Por ejemplo, en una interacción típica de solicitud y respuesta basada en HTTP, el cliente no verifica la identidad del servidor.

  • ¿Qué sucede si un atacante intercepta ese tráfico? Por ejemplo, el tráfico HTTP no está encriptado, por lo que cualquier persona que lo reciba puede inspeccionar su contenido. Esto se conoce como un ataque de un intermediario.

Para mitigar estos problemas, puedes usar HTTP, HTTP/2 y gRPC en TLS. En estos intercambios entre un cliente y un servidor, el servidor debe usar un certificado de servidor para demostrar su identidad al cliente. Luego, las solicitudes y las respuestas se encriptan mediante TLS.

Autenticación mutua de TLS

Cuando Cloud Service Mesh configura las redes de aplicaciones para el cliente y de servidor, por ejemplo, configurando un proxy de Envoy del lado del cliente y otro proxy de Envoy en el servidor, puedes aprovechar las funciones los patrones de autenticación, como la autenticación mutua.

En un intercambio típico de HTTP en TLS, que no se basa en la autenticación mutua, el servidor tiene un certificado que usa para encriptar las comunicaciones entre el cliente y el servidor. El cliente puede verificar la identidad del servidor mediante la comprobación de la firma que el servidor envía durante el protocolo de enlace de TLS. Sin embargo, el servidor no verifica la identidad del cliente.

Cuando la autenticación mutua esté habilitada, el cliente también tendrá un certificado. El cliente verifica la identidad del servidor, como se describe en el párrafo anterior, y el servidor también puede verificar la identidad del cliente. Los certificados del cliente y del servidor se usan para encriptar el canal de comunicación. Esto también permite que el servidor autorice a los clientes en función de la identidad verificada del cliente.

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

Autoriza llamadas de servicio

Puedes optar por permitir o denegar el acceso a los servicios mediante el uso de políticas de autorización. Con Cloud Service Mesh puedes definir reglas de permiso y denegación para autorizar el acceso según los parámetros de la solicitud. Puedes basar estas reglas en los parámetros de las capas 3 y 7, incluido el ID de cliente, que deriva del client-cert en una conexión mTLS, una dirección IP de origen, una coincidencia de host, una coincidencia de método y una coincidencia de encabezado. En el siguiente diagrama, se muestra la autorización con los proxies de Envoy. El proceso es similar al de los clientes de gRPC.

Autorización en una malla de servicios
Autorización en una malla de servicios mediante Envoy (haz clic para ampliar)

Restringe el acceso mediante autorización

Una práctica recomendada dentro de una malla de servicios es cumplir con el principio de privilegio mínimo. Puedes cumplir con este principio si restringes el acceso a un servicio solo a los emisores que dependen del servicio. Cuando el emisor intenta acceder a un servicio para el cual no está autorizado, se rechazará el intento.

Con Cloud Service Mesh, puedes configurar políticas de autorización que permitan que tu plano de datos permita o deniegue el acceso a los servicios en función de las reglas que definas. Estas políticas constan de dos componentes:

  • Una acción: permitir o rechazar
  • Una lista de reglas

Cuando se envía una solicitud o RPC, el cliente de la malla de servicios de Cloud en la el servicio determina si hay una coincidencia de la regla. Si se encuentra una coincidencia, se permite o se rechaza la solicitud o RPC. Puedes definir una regla para que coincida con atributos como los siguientes:

  • Cuando se usa mTLS, la cuenta de servicio de Kubernetes del servicio de llamadas
  • La dirección IP del servicio que realiza la llamada (o el rango de direcciones)
  • Los puertos del servicio de destino
  • Los atributos HTTP de la solicitud, incluidos los métodos, los nombres de host y los encabezados HTTP definidos por el usuario

nombres seguros

Como mecanismo de seguridad adicional, puedes configurar nombres seguros con la malla de servicios en la nube. Esto te permite definir una lista de nombres permitidos, o SPIFFE (Framework de identidad de producción segura para todos), para un servicio al que un cliente intenta conectarse. Durante el intercambio de TLS, el backend del servicio muestra un certificado X.509 al cliente. Luego, el cliente inspecciona el certificado para confirmar que el certificado X.509 coincida con uno de los nombres o las identidades SPIFFE. A fin de obtener más información sobre las identidades SPIFFE, consulta Marco de identidades de producción seguras para todos.

Protege el tráfico en una puerta de enlace

Para configurar tus puertas de enlace, puedes usar Cloud Service Mesh. Una puerta de enlace es un proxy de Envoy independiente que suele actuar como una de las siguientes opciones:

  • Una puerta de enlace de entrada que controla el tráfico que ingresa a una malla o a otro dominio
  • Una puerta de enlace de salida que controla el tráfico que sale de una malla o de otro dominio
  • Un proxy inverso o proxy intermedio que distribuye el tráfico entrante entre uno o más servicios

Los clientes que deseen enviar tráfico a la malla o fuera de ella envían tráfico a la puerta de enlace. Luego, la puerta de enlace controla las solicitudes en función de las reglas que configuraste con Cloud Service Mesh. Por ejemplo, puedes forzar que el tráfico que ingresa a la malla (a través de la puerta de enlace de entrada) se encripte mediante TLS.

Componentes de seguridad

La seguridad de los servicios de Cloud Service Mesh admite políticas de TLS del cliente y TLS del servidor de código abierto y de autorización. Creas estas políticas para que Cloud Service Mesh puede configurar tu plano de datos y habilitar la seguridad capacidades de integración. Para crear o actualizar estas políticas, no necesitas realizar cambios en tus aplicaciones.

Encriptación y modos de autenticación compatibles

Cuando un servicio llama a otro, el primer paso para establecer comunicaciones seguras es hacer que cada servicio pruebe su identidad ante el otro servicio. El grado en el que un servicio necesita demostrar su identidad se basa en el modo de TLS que configures.

Puedes configurar los siguientes niveles de seguridad:

  • Sin encriptar/sin autenticar
  • TLS
  • Autenticación mutua de TLS (mTLS)
  • Permisivo: mTLS o sin encriptar/sin autenticar, en función de cómo el cliente inicia la conexión

Certificados y autoridades de certificación

Los certificados y una autoridad certificada (CA) de confianza proporcionan la base para la confianza en un sistema distribuido, como una malla de servicios. Mediante los certificados, los servicios pueden probar sus identidades y verificar las identidades que se les presentan de las siguientes maneras:

  • Un servicio que desea demostrar su identidad a otro servicio presenta su certificado al otro servicio. Una CA en la que ambos servicios confían y firma de forma criptográfica este certificado.
  • El servicio que recibe este certificado puede verificar que el certificado provenga de una CA en la que confíe.

Cloud Service Mesh no es una autoridad certificadora. Para habilitar comunicaciones seguras, debes configurar un mecanismo que haga lo siguiente:

  • Aprovisione identidades y certificados
  • Permite que los certificados estén disponibles para los clientes de Cloud Service Mesh, como los proxies de Envoy, que Cloud Service Mesh configura

La malla de servicios de Cloud es compatible con el servicio de CA de Google. En las guías de configuración de Envoy y gRPC sin proxy, se incluyen instrucciones para configurar esto (si deseas obtener más detalles, consulta Próximos pasos).

Arquitectura y recursos

Cloud Service Mesh incluye el espacio de nombres de la API de seguridad de red, que consta de tres recursos de la API de Google Cloud que te permiten especificar las políticas de seguridad que se deben aplicar a tu plano de datos.

Dos recursos de la API de Google Cloud admiten la autenticación en la malla: las políticas de TLS del cliente y las políticas de TLS del servidor. Un tercer recurso, la política de autorización, admite la autorización.

El espacio de nombres de la API de servicios de red incluye el recurso de la política del extremo, que permite que Cloud Service Mesh proporcione la configuración (TLS del servidor, TLS del cliente y políticas de autorización) a los extremos. Los extremos son la malla de servicios clientes que finalizan una comunicación entrante desde otra malla de servicios de Cloud cliente.

Para habilitar el servicio de seguridad, usa el proxy HTTPS de destino o el proxy de gRPC de destino en la implementación. No puedes usar el proxy HTTP de destino ni el proxy TCP de destino.

Política de TLS del cliente

Una política de TLS del cliente te permite especificar el modo de la TLS del cliente y la información del proveedor del certificado que se aplicará a tu plano de datos. Las políticas de TLS del cliente admiten la autenticación de TLS y mTLS. Las políticas de TLS del cliente se deben adjuntar a un recurso del servicio de backend global.

Cuando configuras TLS, debes proporcionar un mecanismo mediante el cual el cliente valide el certificado que recibe del servidor durante el intercambio de TLS a través del uso del campo de la API serverValidationCa. El cliente usa esta información a fin de obtener un certificado de validación que pueda usar para validar el certificado del servidor.

Cuando configuras mTLS, también debes proporcionar un mecanismo mediante el cual el cliente obtenga su certificado y su clave privada a través del uso del campo de la API clientCertificate. El cliente usa esta información para presentar un certificado al servidor durante el protocolo de enlace de TLS.

En esta versión, Cloud Service Mesh admite una autoridad certificadora administrada, Servicio de AC. La configuración es sencilla: debes especificar el nombre del complemento google_cloud_private_spiffe cuando configures el proveedor del certificado. Esto hace que los clientes de xDS carguen certificados y claves desde una ubicación estática. Como requisitos previos, debes configurar los grupos de servicios de CA y habilitar los certificados de malla en tu clúster de GKE.

Política de TLS del servidor

Una política de TLS del servidor (recurso ServerTlsPolicy) te permite especificar el modo de la TLS del servidor y la información del proveedor de certificados que se aplicará en el plano de datos. Las políticas de TLS del servidor son compatibles con TLS, mTLS y, solo con Envoy, la autenticación Open_or_mTLS. Las políticas de TLS del servidor se pueden adjuntar al recurso del proxy HTTPS de destino o a un recurso de la política del extremo.

Nombres alternativos de asunto

Cuando configuras el campo securitySettings de un servicio de backend global, puedes proporcionar una lista de nombres alternativos de asunto en el campo subjectAltNames. Cuando un cliente inicia un protocolo de enlace de TLS con uno de los backends del servicio, el servidor presenta su certificado X.509. El cliente inspecciona el campo subjectAltName del certificado. Si el campo contiene uno de los valores especificados, la comunicación continuará. Este mecanismo ya se describió en Asignación de nombres seguros.

Política de autorización

Una política de autorización (recurso AuthorizationPolicy) especifica cómo un servidor autoriza solicitudes entrantes o RPC. Se puede configurar para permitir o denegar una solicitud entrante o RPC en función de varios parámetros, como la identidad del cliente que envió la solicitud, el host, los encabezados y otros atributos HTTP. Se puede adjuntar una política de autorización al recurso de proxy HTTPS de destino o a un recurso de la política del extremo.

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.

Limitaciones con aplicaciones de gRPC sin proxy

La seguridad de los servicios de gRPC sin proxy tiene las siguientes limitaciones:

  • Esta versión se limita a Java, Python, C++ y Go.

¿Qué sigue?