Seguridad del servicio

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

Cloud Service Mesh te permite proteger las comunicaciones entre servicios en la malla. 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. Por el momento, la seguridad del servicio de Cloud Service Mesh solo está disponible para 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 sidecars de Envoy o gRPC sin proxy autentican y encriptan comunicaciones mediante la obtención de información de configuración de Cloud Service Mesh y certificados de una Grupo de servicios de CA.

Estas funciones de seguridad facilitan el proceso de implementación de Cloud Service Mesh, ya que proporcionan 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 los grupos de autoridades certificadoras privadas administradas por los servicios de AC.
  • 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 herramientas de redes de las aplicaciones del cliente y el servidor (por ejemplo, mediante la configuración de un proxy de Envoy en el cliente y de otro proxy de Envoy en el servidor), puedes aprovechar los patrones de autenticación avanzados, 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 Cloud Service Mesh en el servicio llamado determina si hay una coincidencia de 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 identidades SPIFFE (Marco de identidades de producción seguras para todos), para un servicio en particular 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 Envoy. que configura Cloud Service Mesh

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 Network Security, que consta de lo siguiente: tres recursos de la API de Google Cloud que te permiten especificar la políticas de seguridad que deben aplicarse al 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 los clientes de Cloud Service Mesh que finalizan una comunicación entrante de otro cliente de Cloud Service Mesh.

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, el 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. Conecta las políticas de TLS del servidor a un extremo recurso de política.

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. Adjuntas políticas de autorización a un recurso de política de extremos.

Una regla de política de autorización tiene los siguientes componentes:

  • from: Especifica la identidad del cliente que permite la regla. La identidad se puede obtener de un certificado de cliente en una conexión TLS mutua o puede ser la identidad ambiental asociada con la VM cliente, como de una cuenta de servicio o una etiqueta segura.
  • to: Especifica las operaciones permitidas por la regla, como las URL que o los métodos HTTP permitidos.
  • when: Te permite definir las restricciones adicionales que deben cumplirse. Puedes usar Common Expression Language (CEL) para definir las restricciones.
  • action: Especifica la acción de la regla. Puede ser ALLOW, DENY o CUSTOM.

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.

Cuando se evalúa una solicitud, una política de autorización realiza cualquiera de las siguientes acciones:

  • ALLOW: Otorga acceso al recurso solicitado si la solicitud coincide con el definidas por el usuario en la política de autorización. La política de autorización bloquea el acceso al recurso solicitado si la solicitud no coincide con ninguna regla definida en la política de autorización. Una solicitud se rechaza si no coincide con una política ALLOW, incluso si otras políticas lo permiten.

  • DENY: Bloquea el acceso al recurso si una solicitud coincide con alguna de las reglas especificadas en una política DENY. La política de autorización otorga acceso al recurso solicitado si la solicitud no coincide con ninguna regla definida en la política de autorización. Se rechaza una solicitud si coincide con una política DENY. incluso si otras políticas lo permiten.

  • CUSTOM (no compatible con Cloud Service Mesh): habilita la integración en sistemas de autorización externos para decisiones de autorización complejas. CUSTOM Las acciones se usan para las políticas que usan extensiones de servicio para tomar decisiones de autorización.

Orden de evaluación de la política de autorización

Cuando se asocian varias políticas de autorización con un solo recurso, se evalúan en el siguiente orden para determinar si se permite o se rechaza una solicitud.

  1. Políticas con acciones CUSTOM: si la política CUSTOM rechaza la la solicitud se rechaza de inmediato. Políticas de DENY o ALLOW no se evalúan, incluso si hay alguna configurada.

  2. Políticas con acciones DENY: si alguna política DENY coincide con la solicitud. se rechaza la solicitud. No se evalúan las políticas ALLOW, incluso si las hay de configuración.

  3. Políticas con acciones ALLOW: Si no hay políticas ALLOW o si alguna política ALLOW coincide con la solicitud, esta se permite. Sin embargo, si si ninguna política ALLOW coincide con la solicitud, esta se rechaza.

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.

Cuotas de AuthorizationPolicy

  • Tienes un límite de 5 políticas de autorización por puerta de enlace.
  • Tienes un límite de 20 recursos de AuthorizationPolicy por proyecto.
  • Una sola autorizaciónPolicy puede apuntar a un máximo de 100 puertas de enlace.

¿Qué sigue?