Seguridad del servicio

En este documento se ofrece una descripción general de la seguridad de los servicios con Cloud Service Mesh. Está pensada para los usuarios de Cloud Service Mesh que quieran añadir autenticación, cifrado y autorización a sus implementaciones. En este documento se da por hecho que conoces la información general de Cloud Service Mesh y las aplicaciones de gRPC sin proxy.

Cloud Service Mesh te permite proteger las comunicaciones entre servicios de tu malla. En la malla, cada servicio tiene una identidad. Las siguientes funciones ayudan a mantener las comunicaciones seguras:

  • Autenticación y cifrado que usan Seguridad de la capa de transporte (TLS) y TLS mutuo (mTLS) tanto para Cloud Service Mesh con Envoy como para Cloud Service Mesh con aplicaciones gRPC sin proxy. Las políticas de TLS de cliente y de servidor controlan si los servicios deben demostrar sus identidades entre sí y usar canales de comunicación cifrados.
  • Autorización, basada en las características del cliente y de la solicitud. Las políticas de autorización controlan si un servicio tiene permiso para acceder a otro servicio y qué acciones se permiten.

Con los certificados y las claves proporcionados por una autoridad de certificación (CA) privada, el Servicio de Autoridades de Certificación de Google te facilita el mantenimiento de la seguridad del servicio. El servicio de CA proporciona certificados de malla de GKE. La función de certificados de malla de GKE y Cloud Service Mesh te permiten desplegar automáticamente estos certificados y que las cargas de trabajo los usen. Modifica tus pods para permitir que las cargas de trabajo reciban y usen credenciales de mTLS. La seguridad de los servicios 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 específicos sustituyen a las grandes aplicaciones monolíticas. 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 problemas de seguridad, por lo que es mejor autenticarlas, cifrarlas y autorizarlas. Estos pasos se basan en el principio de confianza cero, según el cual se considera que todo el tráfico de red está en riesgo, independientemente de si se origina dentro o fuera de la red.

El patrón de diseño de malla de servicios separa cualquier complejidad relacionada con las comunicaciones entre servicios de la lógica empresarial. En su lugar, el plano de datos gestiona esta complejidad. Además de reducir la complejidad de las aplicaciones, el patrón de diseño de malla de servicios permite usar patrones de seguridad que, de otro modo, serían difíciles de implementar y gestionar.

En este modelo, gRPC sin proxy o los sidecars de Envoy autentican y cifran de forma segura las comunicaciones obteniendo información de configuración de Cloud Service Mesh y certificados de un pool de servicios de CA.

Estas funciones de seguridad facilitan el proceso de implementación de Cloud Service Mesh, ya que ofrecen 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 funciones, como descriptores de implementación y etiquetas.
  • Alta disponibilidad de los servicios gestionados de Google, incluidos Cloud Service Mesh y los grupos de autoridades de certificación privadas gestionadas por el servicio de AC.
  • Seguridad vinculada a Gestión de Identidades y Accesos (IAM) de Google: autorización de servicios basada en cuentas de servicio de Google autorizadas.
  • Interoperabilidad perfecta con tus 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.

Proteger las comunicaciones entre servicios

Cloud Service Mesh proporciona autorización, así como seguridad de servicio a servicio con cifrado y autenticación que utilizan TLS. Las políticas de TLS de cliente y de servidor permiten que los servicios hagan lo siguiente:

  • Afirmar y validar sus identidades.
  • Cifra las sesiones de comunicación mediante TLS o mTLS.

En una malla de servicios, el plano de datos gestiona este tipo de seguridad para que las aplicaciones no tengan que tomar medidas especiales para estar protegidas.

Las políticas de autorización te permiten denegar o permitir el acceso según las reglas que definas.

Usar TLS para el cifrado

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

Para mitigar este posible problema, puedes usar HTTP, HTTP/2 o gRPC a través de TLS con Cloud Service Mesh. Cuando usas estos protocolos a través de TLS, el tráfico entre el cliente y el servidor se cifra mediante TLS, que se basa en el certificado del servidor. El tráfico ya no está en texto sin formato, lo que reduce la probabilidad de que un atacante pueda interceptar e inspeccionar o manipular su contenido.

Usar TLS para la autenticación

Cuando un servicio llama a otro, plantéate las siguientes preguntas:

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

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

Para mitigar estos problemas, puedes usar HTTP, HTTP/2 y gRPC a través de TLS. En estos intercambios entre un cliente y un servidor, el servidor debe usar un certificado de servidor para demostrar su identidad al cliente. Las solicitudes y las respuestas se cifran mediante TLS.

Autenticación TLS mutuo

Cuando Cloud Service Mesh configura la red de aplicaciones tanto para el cliente como para el servidor (por ejemplo, configurando un proxy de Envoy en el cliente y otro en el servidor), puedes aprovechar patrones de autenticación avanzados, como la autenticación mutua.

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

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

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

Autorizar llamadas de servicio

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

Autorización en una malla de servicios.
Autorización en una malla de servicios con Envoy (haz clic en la imagen para ampliarla)

Restringir el acceso mediante autorización

Una práctica recomendada en una malla de servicios es seguir el principio de mínimos accesos. Para cumplir este principio, restringe el acceso al servicio únicamente a las llamadas que dependan de él. Cuando una persona que llama intenta acceder a un servicio para el que no tiene autorización, el intento se rechaza.

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 denegar
  • Una lista de reglas

Cuando se envía una solicitud o una llamada a procedimiento remoto, el cliente de Cloud Service Mesh del servicio llamado determina si hay una coincidencia de reglas. Si se encuentra una coincidencia, se permite o se deniega la solicitud o la llamada a procedimiento remoto. Puede definir una regla para que coincida con atributos como los siguientes:

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

Nomenclatura segura

Como mecanismo de seguridad adicional, puedes configurar nombres seguros con Cloud Service Mesh. Esto te permite definir una lista de nombres permitidos o identidades SPIFFE (Secure Production Identity Framework for Everyone) para un servicio concreto al que un cliente intenta conectarse. Durante el intercambio de TLS, el backend del servicio devuelve un certificado X.509 al cliente. A continuación, el cliente inspecciona el certificado para confirmar que el certificado X.509 coincide con uno de los nombres o identidades SPIFFE. Para obtener más información sobre las identidades de SPIFFE, consulta Secure Production Identity Framework for Everyone.

Proteger el tráfico en una pasarela

Para configurar tus pasarelas, puedes usar Cloud Service Mesh. Una pasarela es un proxy de Envoy independiente que suele actuar como uno de los siguientes elementos:

  • Una pasarela de entrada que gestiona el tráfico que entra en una malla o en otro dominio
  • Una puerta de enlace de salida que gestiona el tráfico que sale de una malla u otro dominio.
  • Un proxy inverso o un proxy intermedio que distribuye el tráfico entrante entre uno o varios servicios

Los clientes que quieran enviar tráfico a la malla o fuera de ella lo envían a la pasarela. A continuación, la pasarela gestiona las solicitudes según las reglas que hayas configurado con Cloud Service Mesh. Por ejemplo, puedes obligar a que el tráfico que entra en tu malla (a través de la pasarela de entrada) se cifre mediante TLS.

Componentes de seguridad

La seguridad de los servicios de Cloud Service Mesh admite políticas de TLS de cliente, políticas de TLS de servidor y políticas de autorización. Estas políticas se crean para que Cloud Service Mesh pueda configurar tu plano de datos y habilitar las funciones de seguridad. Para crear o actualizar estas políticas, no es necesario que hagas cambios en tus aplicaciones.

Cifrado y modos de autenticación admitidos

Cuando un servicio llama a otro, el primer paso para establecer comunicaciones seguras es que cada servicio demuestre su identidad al otro. El grado en el que un servicio debe demostrar su identidad se basa en el modo TLS que configures.

Puedes configurar los siguientes niveles de seguridad:

  • Sin cifrar/sin autenticar
  • TLS
  • TLS mutuo (mTLS)
  • Permisivo: mTLS o sin cifrar/sin autenticar, en función de cómo inicie la conexión el cliente

Certificados y autoridades de certificación

Los certificados y una autoridad de certificación (CA) de confianza proporcionan la base para la confianza en un sistema distribuido, como una malla de servicios. Mediante certificados, los servicios pueden demostrar su identidad y verificar las identidades que se les presentan de las siguientes formas:

  • Un servicio que quiera demostrar su identidad a otro servicio presenta su certificado al otro servicio. Una CA en la que confían ambos servicios firma criptográficamente y emite este certificado.
  • El servicio que recibe este certificado puede verificar que el certificado procede de una CA en la que confía.

Cloud Service Mesh no es una autoridad de certificación. Para habilitar las comunicaciones seguras, debes configurar un mecanismo que haga lo siguiente:

  • Proporciona identidades y certificados
  • Pone los certificados a disposición de los clientes de Cloud Service Mesh, como los proxies de Envoy, que Cloud Service Mesh configura.

Cloud Service Mesh es compatible con el servicio de CA de Google. Las guías de configuración de Envoy y gRPC sin proxy incluyen instrucciones para configurar esta opción (para obtener más información, consulta la sección Pasos siguientes).

Arquitectura y recursos

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

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

El espacio de nombres de la API Network Services incluye el recurso de política de endpoint, que permite a Cloud Service Mesh proporcionar configuración (TLS de servidor, TLS de cliente y políticas de autorización) a los endpoints. Los endpoints son los clientes de Cloud Service Mesh que terminan una comunicación entrante de otro cliente de Cloud Service Mesh.

Política de TLS de cliente

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

Cuando configures TLS, debes proporcionar un mecanismo mediante el cual el cliente valide el certificado que recibe del servidor durante el intercambio de TLS mediante el campo de la API serverValidationCa. El cliente usa esta información para obtener un certificado de validación que puede usar para validar el certificado del servidor.

Cuando configures mTLS, también debes proporcionar un mecanismo por el que el cliente obtenga su certificado y su clave privada mediante el campo clientCertificate de la API. El cliente usa esta información para presentar un certificado al servidor durante el handshake TLS.

En esta versión, Cloud Service Mesh admite una autoridad de certificación gestionada, Servicio de Autoridades de Certificación. La configuración es sencilla: especifica el nombre del complemento google_cloud_private_spiffe al configurar el proveedor de certificados. De esta forma, tus clientes de xDS cargan certificados y claves desde una ubicación estática. Como requisitos previos, debes configurar los grupos de servicios de AC y habilitar los certificados de malla en tu clúster de GKE.

Política de TLS de servidor

Una política de TLS de servidor (recurso ServerTlsPolicy) te permite especificar el modo TLS del lado del servidor y la información del proveedor de certificados que se aplicará a tu plano de datos. Las políticas TLS de servidor admiten TLS, mTLS y, solo con Envoy, autenticación Open_or_mTLS. Las políticas de TLS de servidor se asocian a un recurso de política de endpoint.

Nombres alternativos de subject

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 handshake TLS con uno de los back-ends 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 continúa. Este mecanismo se describe más arriba en la sección Nombres seguros.

Política de autorización

Una política de autorización (recurso AuthorizationPolicy) especifica cómo autoriza un servidor las solicitudes o las RPCs entrantes. Se puede configurar para permitir o denegar una solicitud o una llamada a procedimiento remoto entrante en función de varios parámetros, como la identidad del cliente que envió la solicitud, el host, los encabezados y otros atributos HTTP. Las políticas de autorización se adjuntan a un recurso de política de endpoint.

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

  • from: especifica la identidad del cliente al que permite la regla. La identidad se puede derivar de un certificado de cliente en una conexión TLS mutua o puede ser la identidad del entorno asociada a la VM del cliente, como la de una cuenta de servicio o una etiqueta segura.
  • to: especifica las operaciones permitidas por la regla, como las URLs a las que se puede acceder o los métodos HTTP permitidos.
  • when: te permite definir restricciones adicionales que se deben cumplir. Puedes usar expresiones del lenguaje de expresión común (CEL) para definir las restricciones.
  • action: especifica la acción de la regla. Puede ser ALLOW, DENY o CUSTOM.

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.

Al evaluar una solicitud, una política de autorización puede llevar a cabo cualquiera de las siguientes acciones:

  • ALLOW: concede acceso al recurso solicitado si la solicitud coincide con las reglas definidas 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. Se deniega una solicitud si no coincide con una política ALLOW, aunque otras políticas lo permitan.

  • 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 concede acceso al recurso solicitado si la solicitud no coincide con ninguna de las reglas definidas en la política de autorización. Se deniega una solicitud si coincide con una política DENY, aunque otras políticas lo permitan.

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

Orden de evaluación de las políticas de autorización

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

  1. Políticas con acciones CUSTOM: si la política CUSTOM deniega la solicitud, esta se rechaza inmediatamente. No se evalúan las políticas DENY ni ALLOW, aunque se hayan configurado.

  2. Políticas con acciones DENY: si alguna política DENY coincide con la solicitud, se deniega. No se evalúan las políticas de ALLOW, aunque se hayan configurado.

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

Limitaciones con las aplicaciones de gRPC sin proxy

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

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

Cuotas de AuthzPolicy

  • Tienes un límite de 5 políticas de autorización por Gateway.
  • Puedes crear un máximo de 20 recursos AuthzPolicy por proyecto.
  • Un solo AuthzPolicy puede apuntar a un máximo de 100 Gateways.

Siguientes pasos