Seguridad del servicio

En este documento, se proporciona una descripción general de la seguridad del servicio con Traffic Director. Está dirigido a los usuarios de Traffic Director 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 Traffic Director con Envoy y con las aplicaciones de gRPC sin proxy.

Traffic Director 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 Traffic Director con Envoy y Traffic Director 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. La función de certificados de la malla de GKE y Traffic Director te permite implementar estos certificados de forma automática 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 Traffic Director está disponible solo 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 archivos adicionales de gRPC o Envoy sin proxy autentican y encriptan las comunicaciones de forma segura mediante la información de configuración de Traffic Director y los certificados de un grupo de servicios de CA.

Estas funciones de seguridad facilitan el proceso de implementación de Traffic Director, 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 Traffic Director y los grupos de autoridades certificadoras privadas administradas por los servicios de CA.
  • 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

Traffic Director proporciona autorización y seguridad entre servicios 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 Traffic Director. 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 Traffic Director 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. Mediante Traffic Director, puedes definir reglas de permiso y denegación para autorizar el acceso en función de 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.

Mediante Traffic Director, 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 Traffic Director 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 la asignación de nombres seguros mediante Traffic Director. 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 Traffic Director. 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 mediante Traffic Director. 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 del servicio de Traffic Director admite políticas de TLS del cliente, políticas de TLS del servidor y políticas de autorización. Crea estas políticas para que Traffic Director pueda configurar el plano de datos y habilitar las funciones de seguridad. 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.

Traffic Director no es una autoridad certificada. Para habilitar comunicaciones seguras, debes configurar un mecanismo que haga lo siguiente:

  • Aprovisione identidades y certificados
  • Permita que los certificados estén disponibles para los clientes de Traffic Director, como los proxies de Envoy, que Traffic Director configura

Traffic Director 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

Traffic Director 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 Traffic Director 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 Traffic Director que finalizan una comunicación entrante de otro cliente de Traffic Director.

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, Traffic Director admite una autoridad certificada administrada, el servicio de CA. 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. Adjunta las políticas de TLS del servidor a un recurso de política de extremos.

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. Las políticas de autorización se adjuntan a un recurso de política de extremo.

Limitaciones

La seguridad del servicio de Traffic Director solo es compatible con 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?