Prácticas recomendadas de seguridad de Cloud Service Mesh con las APIs de Istio

En este documento, se describen prácticas recomendadas para establecer y administrar una configuración segura de Cloud Service Mesh que se ejecuta en Google Kubernetes Engine (GKE). En la orientación del documento, se va más allá de la configuración y el aprovisionamiento de Cloud Service Mesh, y se describe cómo puedes usar Cloud Service Mesh con otros productos y funciones de Google Cloud para protegerte de las amenazas de seguridad que las aplicaciones en una malla pueden enfrentar.

El público objetivo de este documento incluye los administradores que gestionan en una malla de servicios de Cloud y a los propietarios de servicios que ejecutan servicios en una la malla de servicios en la nube. Las medidas de seguridad que se describen aquí también son útiles para las organizaciones que necesitan mejorar la seguridad de sus mallas de servicios para cumplir con los requisitos de cumplimiento.

El documento está organizado de la siguiente manera:

Introducción

Cloud Service Mesh proporciona funciones y herramientas que te ayudan a observar, administrar y y servicios seguros de forma unificada. Adopta un enfoque centrado en la aplicación y usa identidades de aplicaciones confiables en lugar de un sistema enfocado en la IP de red. Puedes implementar una malla de servicios de forma transparente sin necesidad de modificar el código de la aplicación existente. Cloud Service Mesh proporciona un control declarativo el comportamiento de red, lo que ayuda a separar el trabajo de los equipos responsables para entregar y lanzar funciones de la aplicación desde las responsabilidades del de Google Cloud que son responsables de la seguridad y las redes.

Cloud Service Mesh se basa en la malla de servicios de Istio de código abierto, la cual habilita configuraciones y topologías más sofisticadas. Según la estructura de tu organización, es posible que uno o más equipos o roles sean responsables instalar y configurar una malla. La malla de servicios de Cloud predeterminada de seguridad se eligen para proteger las aplicaciones, pero en algunos casos, es posible que configuraciones personalizadas o que debas otorgar excepciones excluyendo ciertas que las apps, los puertos o las direcciones IP participen en una malla. Tener controles en la configuración de la malla y las excepciones de seguridad.

Este documento complementa Documentación de las prácticas recomendadas para la seguridad de Istio, que incluye recomendaciones de configuración detalladas para TLS mutua (mTLS), las políticas de autorización, las puertas de enlace y otros parámetros de configuración de seguridad. Tratar estos recomendaciones como base para usar junto con las prácticas recomendadas que se analizan en este documento. En este documento, se describen las prácticas recomendadas adicionales para Cloud Service Mesh y cómo las tecnologías de Google Cloud pueden proteger todas las capas, los componentes y los flujos de información en una malla.

Vectores de ataque y riesgos de seguridad

Vectores de ataque

La seguridad de Cloud Service Mesh sigue el modelo de seguridad de confianza cero, que supone que las amenazas de seguridad se originan dentro y fuera del perímetro de seguridad de una organización. Estos son ejemplos de ataques de seguridad que podrían amenazar las aplicaciones en una malla de servicios:

  • Ataques de robo de datos. Por ejemplo, ataques que espían datos sensibles o credenciales del tráfico de servicio a servicio.
  • Ataques de intermediario. Por ejemplo, un servicio malicioso que se enmascara como un servicio legítimo para obtener o modificar la comunicación entre servicios.
  • Ataques de elevación de privilegios. Por ejemplo, ataques que usan acceso ilícito a privilegios elevados para realizar operaciones en una red.
  • Ataques de denegación del servicio (DoS).
  • Ataques de botnet que intentan comprometer y manipular servicios para iniciar ataques en otros servicios.

Los ataques también se pueden clasificar según los objetivos de los ataques:

  • Ataques de red interna de malla. Ataques dirigidos a la manipulación, el espionaje o la falsificación de identidad de la comunicación interna de servicio a servicio o de servicio a plano de control de la malla.
  • Ataques del plano de control. Ataques cuyo objetivo sea hacer que el plano de control no funcione (como un ataque de DoS) o robar datos sensibles del plano de control.
  • Ataques perimetrales de la malla. Ataques dirigidos a la manipulación, el espionaje o la falsificación de identidad de la comunicación en la entrada o la salida de la malla.
  • Ataques a las operaciones de la malla. Ataques dirigidos a las operaciones de la malla. Los atacantes podrían obtener privilegios elevados para realizar operaciones maliciosas en una malla, como modificar las políticas de seguridad y las imágenes de cargas de trabajo.

Riesgos de seguridad

Además de los ataques de seguridad, una malla también se enfrenta a otros riesgos de seguridad. En la siguiente lista, se describen algunos riesgos de seguridad posibles:

  • Protección de seguridad incompleta. Una malla de servicios no se configuró con políticas de autenticación y autorización para proteger su seguridad. Por ejemplo, no se definieron políticas de autenticación o autorización para los servicios en una malla.
  • Excepciones de la política de seguridad. Para adaptarse a sus casos de uso específicos, los usuarios podrían crear excepciones a la política de seguridad para cierto tráfico (interno o externa) de las políticas de seguridad de Cloud Service Mesh. Para manejar estos casos de forma segura, consulta Cómo manejar las excepciones a las políticas de forma segura en este documento.
  • No actualizar imágenes. Es posible que se detecten vulnerabilidades en las imágenes que se usan en una malla. Debes mantener actualizados el componente de malla y las imágenes de carga de trabajo con las correcciones de vulnerabilidades más recientes.
  • Falta de mantenimiento (sin experiencia ni recursos). El software de la malla y la configuración de políticas necesitan un mantenimiento regular para aprovechar los mecanismos de protección de seguridad más recientes.
  • Falta de visibilidad. Configuración incorrecta o configuraciones inseguras de la malla y las operaciones o el tráfico anormal de la malla no se redireccionan atención de los administradores de mallas.
  • Desvío de configuración. La configuración de políticas en una malla se desvía de la fuente de información.

Medidas para proteger una malla de servicios

En esta sección, se presenta un manual operativo para proteger las mallas de servicios.

Arquitectura de seguridad

La seguridad de una malla de servicios depende de la seguridad de los componentes en diferentes capas del sistema de malla y sus aplicaciones. La intención de alto nivel de la postura de seguridad de Cloud Service Mesh propuesta es proteger una malla de servicios mediante la integración de varios mecanismos de seguridad en diferentes capas, los que en conjunto logran la seguridad general del sistema bajo el modelo de seguridad de confianza cero. En el siguiente diagrama, se muestra la postura de seguridad propuesta en Cloud Service Mesh.

de seguridad de la malla de servicios de Cloud

Cloud Service Mesh proporciona seguridad en varias capas, incluidas las siguientes:

  • Seguridad perimetral de la malla
    • La seguridad de entrada de Cloud Service Mesh proporciona control de acceso para el tráfico externo y protege el acceso externo a las APIs expuestas por los servicios en la malla.
    • La seguridad de salida de la malla de servicios de Cloud regula el tráfico saliente de las cargas de trabajo internas.
    • La autenticación de usuarios de Cloud Service Mesh se integra en la infraestructura de Google para autenticar las llamadas externas de los navegadores web a los servicios que ejecutan aplicaciones web.
    • Administración de certificados de puerta de enlace de Cloud Service Mesh protege y rota las claves privadas y los certificados X.509 utilizados por Puertas de enlace de entrada y salida de la malla de servicios de Cloud con Certificate Authority Service
    • La VPC y los Controles del servicio de VPC protegen el perímetro de la malla a través de los controles de acceso a la red privada.
  • Seguridad del clúster
    • La TLS mutua (mTLS) de Cloud Service Mesh aplica la encriptación y la autenticación del tráfico de carga de trabajo a carga de trabajo.
    • La autoridad certificadora de Cloud Service Mesh aprovisiona y administra de forma segura los certificados que usan las cargas de trabajo.
    • La autorización de Cloud Service Mesh aplica el control de acceso para los servicios de malla según sus identidades y otros atributos.
    • Panel de seguridad de GKE Enterprise proporciona supervisión de la configuración de las políticas de seguridad y NetworkPolicy de Kubernetes para las cargas de trabajo.
    • Control de acceso a los Pods aplicado por la política de red de Kubernetes según las direcciones IP, las etiquetas de Pod, los espacios de nombres y otros.
  • Seguridad de las cargas de trabajo
    • Mantente al día con las versiones de seguridad de Cloud Service Mesh para garantizar que Los objetos binarios de la malla de servicios de Cloud que se ejecutan en tu malla no tienen archivos vulnerabilidades.
    • La federación de identidades para cargas de trabajo para GKE permite que las cargas de trabajo obtengan credenciales para llamar de forma segura a los servicios de Google.
    • Cloud Key Management Service (Cloud KMS) protege datos o credenciales sensibles a través de módulos de seguridad de hardware (HSM). Por ejemplo, las cargas de trabajo pueden usar Cloud KMS para almacenar credenciales u otros datos sensibles. CA Service, que es se usa para emitir certificados para cargas de trabajo en malla, admite Las claves de firma respaldadas por HSM administradas por Cloud KMS
    • La interfaz de red del contenedor de Kubernetes (CNI) evita ataques de elevación de privilegios eliminando la necesidad de una cuenta Contenedor de init de Cloud Service Mesh.
  • Seguridad del operador
    • El control de acceso basado en roles (RBAC) de Kubernetes restringe el acceso a los recursos de Kubernetes y limita los permisos del operador para mitigar los ataques que se originan en los operadores maliciosos o en el robo de identidad de operadores.
    • Policy Controller de GKE Enterprise valida y audita las configuraciones de políticas en la malla para evitar configuraciones incorrectas.
    • La autorización binaria de Google Cloud garantiza que las imágenes de carga de trabajo en la malla sean las que autorizan los administradores.
    • Los Registros de auditoría de Cloud auditan las operaciones de malla.

En el siguiente diagrama, se muestran los flujos de comunicación y configuración con las soluciones de seguridad integradas en Cloud Service Mesh.

flujo de tráfico de seguridad

Seguridad del clúster

En esta sección, se describen las prácticas recomendadas relacionadas con la seguridad del clúster.

Habilita TLS mutua estricta

Un ataque de intermediario (MitM) intenta insertar una entidad maliciosa entre dos en las que intervienen para que las personas escuchen o manipulen la comunicación. La malla de servicios de Cloud se defiende de los ataques MitM y de robo de datos a través de la aplicación Autenticación y encriptación de mTLS para todas las partes que se comunican. El modo permisivo usa mTLS cuando ambos extremos admiten pero permite conexiones sin mTLS. Por el contrario, la mTLS estricta requiere que el tráfico se encripte y se autentique con mTLS, y no permite el tráfico de texto sin formato.

Cloud Service Mesh te permite configura la versión mínima de TLS que las conexiones TLS entre tus cargas de trabajo cumplan con tus los requisitos de cumplimiento.

Para obtener más información, consulta Anthos Service Mesh mediante un ejemplo: mTLS | Aplicación de mTLS en toda la malla.

Habilita los controles de acceso

Recomendamos que las políticas de seguridad de Cloud Service Mesh (como las de autenticación y autorización) se apliquen a todo el tráfico dentro y fuera de la malla, a menos que haya justificaciones sólidas para excluir un servicio o un Pod de las políticas de seguridad de Cloud Service Mesh. En algunos casos, es posible que los usuarios tengan razones legítimas para omitir Políticas de seguridad de la malla de servicios de Cloud para algunos puertos y direcciones IP de red, por ejemplo, para establecer conexiones nativas con servicios que no administra Cloud Service Mesh. Para proteger Cloud Service Mesh con esos casos de uso, consulta Cómo manejar de forma segura las excepciones de políticas de Cloud Service Mesh.

El control de acceso del servicio es fundamental para evitar el acceso no autorizado a los servicios. La aplicación de mTLS encripta y autentica una solicitud, pero una malla aún necesita políticas de autorización de Cloud Service Mesh para aplicar el control de acceso a los servicios, por ejemplo, rechazando una solicitud no autorizada que proviene de un cliente autenticado.

Las políticas de autorización de Cloud Service Mesh proporcionan una manera flexible de configurar los controles de acceso para defender los servicios contra el acceso no autorizado. Malla de servicios en la nube las políticas de autorización deben aplicarse en función de las identidades autenticadas derivadas de los resultados de la autenticación; Basadas en mTLS o JSON web token (JWT) la autenticación puede usarse en conjunto como parte de la malla de servicios de forma predeterminada.

Aplica las políticas de autenticación de Cloud Service Mesh

Cuando consideres las políticas de autenticación de Cloud Service Mesh, los siguientes puntos.

Token web JSON (JWT)

Además de la autenticación mTLS, los administradores de malla pueden exigir que un servicio autentique y autorice solicitudes basadas en JWT. Cloud Service Mesh no actúa como proveedor de JWT, sino que los autentica según el de conjuntos de claves web JSON (JWKS) configurados. La autenticación de JWT se puede aplicar a las puertas de enlace de entrada para el tráfico externo o a los servicios internos para el tráfico en la malla. La autenticación de JWT se puede combinar con la autenticación de mTLS cuando un JWT se usa como una credencial para representar al emisor final y el servicio solicitado requiere una prueba de que se lo llama en nombre del emisor final. La aplicación de la autenticación de JWT protege contra ataques que acceden a un servicio sin credenciales válidas y en nombre de un usuario final real.

Autenticación de usuarios de Cloud Service Mesh

La autenticación de usuarios de Cloud Service Mesh es una solución integrada para la autenticación de usuarios finales basada en el navegador y el control de acceso a tus cargas de trabajo. Integra una malla de servicios en las Proveedores (IdP) para implementar un acceso estándar basado en la Web de OpenID Connect (OIDC) y consentimiento, y usa la autorización de Cloud Service Mesh políticas para el control de acceso.

Aplica políticas de autorización

Las políticas de autorización de Cloud Service Mesh controlan lo siguiente:

  • Quién o qué tiene permiso para acceder a un servicio
  • A qué recursos se puede acceder
  • Qué operaciones se pueden realizar en los recursos permitidos

Las políticas de autorización son una forma versátil de configurar el control de acceso basado en las identidades reales que ejecutan los servicios como capa de aplicación (capa 7) propiedades del tráfico (por ejemplo, encabezados de solicitud) y capa de red (capa 3) y capa 4), como rangos de IP y puertos.

Recomendamos que las políticas de autorización de Cloud Service Mesh se apliquen en función de las identidades autenticadas derivadas de los resultados de autenticación para defenderse del acceso no autorizado a los servicios o datos.

De forma predeterminada, rechaza el acceso a un servicio, a menos que se aplique una política de autorización se define de forma explícita para permitir el acceso al servicio. Consulta las prácticas recomendadas de las políticas de autorización para ver ejemplos de políticas de autorización que rechazan las solicitudes de acceso.

El objetivo de las políticas de autorización es restringir la confianza tanto como sea posible. Por ejemplo, el acceso a un servicio se puede definir según las rutas de URL individuales que expone un servicio, de modo que solo el servicio A pueda acceder a la ruta /admin del servicio B.

Las políticas de autorización pueden usarse junto con Políticas de red de Kubernetes, que solo operan en la capa de red (capa 3 y 4) y controlan Acceso a la red para direcciones IP y puertos en Pods de Kubernetes y los espacios de nombres.

Aplica el intercambio de tokens para acceder a los servicios de la malla

Para protegerte de los ataques de repetición de tokens, que roban tokens y vuelven a usarlos para acceder a los servicios de la malla, asegúrate de que un token de una solicitud desde fuera de la malla se intercambie por un token interno de la malla de corta duración en el perímetro de la malla.

Una solicitud desde fuera de la malla para acceder a un servicio de malla debe incluir un token, como JWT o cookie, para que el servicio de malla lo autentique y autorice. Un token proveniente del exterior de la malla puede ser de larga duración. Para defenderse de los ataques de repetición de tokens, intercambia un token de fuera de la malla por un token de corta duración interno de la malla con un permiso limitado en la entrada de la malla. El servicio de malla autentica un token interno de la malla y autoriza la solicitud de acceso según el token interno de la malla.

La malla de servicios de Cloud admite integración en Identity-Aware Proxy (IAP). que genera un RequestContextToken (un token interno de malla de corta duración que se intercambian desde un token externo) que se usan en Cloud Service Mesh para la autorización. Con el intercambio de tokens, los atacantes no pueden usar un token robado en la malla para acceder a los servicios. El alcance y la vida útil limitados del token intercambiado reducen en gran medida la posibilidad de un ataque de reinyección de token.

Maneja de forma segura las excepciones de políticas de Cloud Service Mesh

Es posible que tengas casos de uso especiales para tu malla de servicios. Por ejemplo, es posible que debas exponer un determinado puerto de red al tráfico de texto sin formato. Para adaptarse a situaciones de uso específicas, es posible que a veces debas crear excepciones para permitir que cierto tráfico interno o externo se excluya de las políticas de seguridad de Cloud Service Mesh, lo que crea problemas de seguridad.

Es posible que tengas motivos legítimos para omitir las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de IP. Puedes agregar annotations como excludeInboundPorts, excludeOutboundPorts y excludeOutboundIPRanges a los Pods para excluir el tráfico del control Archivo adicional de Envoy. Además de las anotaciones para excluir tráfico, puedes omitir la malla por completo mediante la implementación de una aplicación con la inyección de sidecar inhabilitada, por ejemplo, agregando una etiqueta sidecar.istio.io/inject="false" al Pod de la aplicación.

Omitir las políticas de seguridad de Cloud Service Mesh tiene un impacto negativo en la seguridad general del sistema. Por ejemplo, si la malla de servicios de Cloud políticas de autorización para un puerto de red mediante anotaciones, no hay acceso control del tráfico en el puerto y la escucha o modificación del tráfico que puedas tener en cuenta. Además, la omisión de las políticas de Cloud Service Mesh también afecta que no son de seguridad, como las de red.

Cuando se omite la política de seguridad de Cloud Service Mesh para un puerto o una dirección IP (ya sea de forma intencional o involuntaria), te recomendamos que implementes otras medidas de seguridad para proteger la malla y supervisar las excepciones de seguridad, las posibles brechas de seguridad y el estado general de aplicación de la seguridad. Para proteger tu malla en esas situaciones, puedes hacer lo siguiente:

  • Asegúrate de que el tráfico que omite los sidecars esté encriptado de forma nativa y se autentique para evitar ataques de MitM.
  • Aplica políticas de red de Kubernetes para limitar la conectividad de los puertos con excepciones de políticas, por ejemplo, limitar un puerto con excepciones a la política para permitir solo el tráfico de otro en el mismo espacio de nombres, o para permitir que solo el tráfico pase los puertos que tienen aplicada la política de seguridad de Cloud Service Mesh.

Usa un enfoque de GitOps con Sincronizador de configuración para evitar el desvío de configuración

El desvío de configuración se produce cuando la configuración de las políticas en una malla se desvía de su fuente de información. Puedes usar el Sincronizador de configuración para evita el desvío de configuración.

Aplica la supervisión y el registro de auditoría de Cloud

Recomendamos que los administradores de mallas supervisen lo siguiente:

Los administradores pueden usar estos recursos de observabilidad para verificar que la configuración funciona como se espera y para supervisar cualquier excepción a la seguridad de la aplicación de políticas. Por ejemplo, el acceso que no pasó por los sidecars o que no tenía credenciales válidas, pero llegó a un servicio.

Si bien el software de observabilidad de código abierto (por ejemplo, Prometheus) se puede usar con Cloud Service Mesh, recomendamos usar Google Cloud Observability. Esta solución de observabilidad integrada para Google Cloud proporciona registro, la recopilación de métricas, la supervisión y las alertas, que es completamente administrado.

Seguridad de las cargas de trabajo

La seguridad de las cargas de trabajo protege contra ataques que vulneran los Pods de carga de trabajo y, luego, usa los Pods vulnerados para iniciar ataques contra el clúster (por ejemplo, ataques de botnet).

Restringe los privilegios de los Pods

Un Pod de Kubernetes puede tener privilegios que afectan a otros Pods en el nodo o el clúster. Es importante aplicar restricciones de seguridad en los Pods de las cargas de trabajo para evitar que un Pod vulnerado pueda iniciar ataques en el clúster.

A fin de aplicar el principio de privilegio mínimo para las cargas de trabajo en un Pod, haz lo siguiente:

  • Los servicios implementados en una malla deben ejecutarse con la menor cantidad de privilegios posible.
  • Puedes configurar Cloud Service Mesh para usar un contenedor init a fin de configurar el redireccionamiento del tráfico de iptables al sidecar. El usuario debe crear de cargas de trabajo que tienen privilegios para implementar contenedores con NET_ADMIN y NET_RAW. Para evitar el riesgo de ejecutar contenedores con privilegios elevados, los administradores de malla pueden habilitar el complemento de CNI de Istio para configurar el redireccionamiento del tráfico a archivos adicionales.

Protege imágenes de contenedor

Los atacantes pueden iniciar ataques mediante la explotación de imágenes vulnerables de contenedores. Los administradores deben aplicar la autorización binaria para verificar la integridad de las imágenes de contenedor y garantizar que solo se implementen imágenes de contenedor confiables en la malla.

Mitiga las vulnerabilidades de la malla

  • Artifact Analysis puede analizar y mostrar vulnerabilidades en las cargas de trabajo de GKE.
  • Manejo de vulnerabilidades y exposiciones comunes (CVE). Después de que una vulnerabilidad de red en una imagen de contenedor, los administradores de malla pueden la vulnerabilidad lo antes posible. Google administra automáticamente la aplicación de parches CVE que afectan a las imágenes de malla.

Usa Workload Identity Federation para GKE para acceder de forma segura a los servicios de Google.

La federación de identidades para cargas de trabajo para GKE es la forma recomendada para que las cargas de trabajo de malla accedan a los servicios de Google de forma segura. La alternativa de almacenar una clave de cuenta de servicio en un Secret de Kubernetes y usar la clave de la cuenta de servicio para acceder a los servicios de Google no es tan segura debido a los riesgos de filtración de credenciales, elevación de privilegios, divulgación de información y no repudio.

Supervisa el estado de la seguridad mediante la telemetría y el panel de seguridad

Una malla de servicios puede tener excepciones de seguridad y posibles brechas. Es fundamental mostrar y supervisar el estado de seguridad de una malla, lo que incluye las políticas de seguridad aplicadas, las excepciones de seguridad y las posibles brechas de seguridad en la malla. Puedes usar el panel de seguridad de GKE Enterprise y la telemetría para mostrar y supervisar el estado de seguridad de la malla.

La telemetría supervisa el estado y el rendimiento de los servicios en una malla, lo que permite a los administradores de malla observar los comportamientos de los servicios (como SLO, tráfico anormal, interrupción del servicio y topología).

En el panel de seguridad de GKE Enterprise, se muestran las políticas que se aplican a una carga de trabajo en una malla de servicios, incluidas las políticas de control de acceso (Políticas de red de Kubernetes, políticas de Autorización binaria y políticas de acceso a servicios (políticas de control) y políticas de autenticación (mTLS).

Seguridad para las credenciales y datos sensibles del usuario

Si almacenas datos sensibles del usuario o credenciales en el almacenamiento persistente del clúster, como los secretos de Kubernetes o directamente en Pods, los datos o las credenciales pueden ser vulnerables a ataques que se originan en Pods o operaciones maliciosas. Los datos también son vulnerables a ataques de red si se transfieren la red para la autenticación de servicios.

  • Si es posible, almacena credenciales y datos sensibles del usuario en el almacenamiento protegido, como Secret Manager y Cloud KMS.
  • Designa espacios de nombres separados para los Pods de Kubernetes que acceden a datos sensibles y define las políticas de Kubernetes a fin de que sean inaccesibles desde otros espacios de nombres. Segmenta los roles que se usan para las operaciones y aplica límites a los espacios de nombres.
  • Aplica el intercambio de tokens para evitar el robo de tokens de larga duración y con muchos privilegios.