Prácticas recomendadas de seguridad de Cloud Service Mesh con 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 aprovisionamiento de Cloud Service Mesh, y se describe cómo puedes usar Cloud Service Mesh con otros productos y funciones de Google Cloudpara protegerte de las amenazas de seguridad que las aplicaciones en una malla pueden enfrentar.

El público objetivo de este documento incluye administradores que controlan políticas en Cloud Service Mesh y propietarios de servicios que ejecutan servicios en Cloud Service Mesh. 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 proteger servicios de manera 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 control declarativo sobre el comportamiento de la red, lo que ayuda a separar el trabajo de los equipos responsables de entregar y lanzar funciones de la aplicación de las responsabilidades de los administradores de la seguridad y las herramientas de 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 la organización, uno o más equipos o roles pueden ser responsables de instalar y configurar una malla. Los parámetros de configuración predeterminados de Cloud Service Mesh se eligen para proteger las aplicaciones, pero, en algunos casos, es posible que necesites configuraciones personalizadas o que otorgues excepciones si excluyes ciertos puertos, apps o direcciones IP de participar en una malla. Es importante tener controles para administrar las configuraciones de malla y las excepciones de seguridad.

Este documento complementa la documentación sobre las prácticas recomendadas de seguridad de Istio, que incluye recomendaciones de configuración detalladas para TLS mutua (mTLS), políticas de autorización, puertas de enlace y otras configuraciones de seguridad. Trata estas recomendaciones como una base que se usa 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. Los siguientes son algunos ejemplos de tipos de ataques de seguridad que podrían afectar a 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 pueden intentar obtener privilegios elevados para realizar operaciones maliciosas en una malla, como modificar sus políticas de seguridad y las imágenes de carga 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 pueden crear excepciones a la política de seguridad para que cierto tráfico (interno o externo) se excluya 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. La configuración incorrecta o insegura de las políticas de malla y el tráfico o las operaciones anormales de la malla no tienen la atención de los administradores de la malla.
  • 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 de Cloud Service Mesh.

postura de seguridad de Cloud Service Mesh

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 Cloud Service Mesh 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.
    • La administración de certificados de la puerta de enlace de Cloud Service Mesh protege y rota las claves privadas y los certificados X.509 que usan las puertas de enlace de entrada y salida de Cloud Service Mesh mediante 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.
    • El panel de seguridad de GKE Enterprise proporciona la supervisión de los parámetros de configuración de las políticas de seguridad y de las políticas de red 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 actualizaciones de seguridad de Cloud Service Mesh para garantizar que los objetos binarios de Cloud Service Mesh que se ejecutan en tu malla estén libres de vulnerabilidades conocidas públicamente.
    • 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. El servicio de AC, que se usa para emitir certificados a cargas de trabajo de malla, admite claves de firma por cliente y respaldadas por HSM administradas por Cloud KMS.
    • La interfaz de red de contenedor (CNI) de Kubernetes evita los ataques de elevación de privilegios mediante la eliminación de la necesidad de un contenedor de inicio de Cloud Service Mesh con privilegios.
  • 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 Google Cloud autorización binaria 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 partes que se comunican para espiar o manipular la comunicación. Cloud Service Mesh se protege contra los ataques de robo de datos y MitM mediante la aplicación de autenticación y encriptación de mTLS para todas las partes comunicativas. El modo permisivo usa mTLS cuando ambas partes la 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 configurar la versión mínima de TLS para las conexiones TLS entre tus cargas de trabajo a fin de cumplir con los requisitos de seguridad y 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, los usuarios pueden tener motivos legítimos para omitir las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de direcciones IP, 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 Administra 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. Las políticas de autorización de Cloud Service Mesh se deben aplicar en función de las identidades autenticadas derivadas de los resultados de autenticación. La autenticación basada en mTLS o en un token web JSON (JWT) se puede usar en conjunto como parte de las políticas de autorización de Cloud Service Mesh.

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

Cuando consideres las políticas de autenticación de Cloud Service Mesh, ten en cuenta 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 un proveedor de JWT, sino que autentica JWT según los extremos configurados del conjunto de claves web JSON (JWKS). 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 los proveedores de identidad (IdP) existentes para implementar un flujo de consentimiento y acceso estándar de OpenID Connect (OIDC) basado en la Web y usa políticas de autorización de Cloud Service Mesh para el control de acceso.

Aplica políticas de autorización

Control de las políticas de autorización de Cloud Service Mesh:

  • 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 según las identidades reales que ejecutan los servicios, las propiedades de la capa de aplicación (capa 7) de tráfico (por ejemplo, los encabezados de solicitudes) y las propiedades de la 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, se debe denegar el acceso a un servicio, a menos que se defina una política de autorización de manera 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 se pueden usar junto con las políticas de red de Kubernetes, que solo operan en la capa de red (capa 3 y capa 4) y controlan el acceso a la red para puertos y direcciones IP en Pods de Kubernetes y espacios de nombres de Kubernetes.

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 desde fuera 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.

Cloud Service Mesh admite la integración con Identity-Aware Proxy (IAP), que genera un RequestContextToken (un token de corta duración interno de la malla que se intercambia desde un token externo) que se usa 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 permiso limitado y la vida útil del token intercambiado reducen en gran medida la posibilidad de un ataque de repetició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 anotaciones, como excludeInboundPorts, excludeOutboundPorts y excludeOutboundIPRanges, a los Pods para excluir tráfico de los controles del sidecar 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 se omiten las políticas de autorización y mTLS de Cloud Service Mesh para un puerto de red mediante anotaciones, no habrá control de acceso para el tráfico en el puerto y es posible que haya espionaje o modificación del tráfico. Además, omitir las políticas de Cloud Service Mesh también afecta a las políticas que no son de seguridad, como las políticas 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 las políticas de red de Kubernetes para limitar la conectividad de los puertos con excepciones de políticas (por ejemplo, limita un puerto con excepciones de políticas para permitir solo el tráfico de otro servicio en el mismo espacio de nombres) o para permitir que el tráfico solo pase por los puertos en los que se aplica 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 evitar el desvío de configuración.

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

Recomendamos que los administradores de malla supervisen lo siguiente:

Los administradores pueden usar estos recursos de observabilidad para verificar que la configuración de seguridad funcione según lo previsto y supervisar cualquier excepción a la aplicación de la política de seguridad. 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, recopilación de métricas, supervisión y alertas, y es completamente administrada.

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. Esto requiere que el usuario cree implementaciones de cargas de trabajo que tengan privilegios para implementar contenedores con funciones NET_ADMIN y NET_RAW. Para evitar el riesgo de ejecutar contenedores con privilegios elevados, los administradores de malla pueden habilitar el complemento de la CNI de Istio en su lugar para configurar el redireccionamiento del tráfico a sidecars.

Protege imágenes de contenedor

Los atacantes pueden lanzar ataques mediante la explotación de imágenes de contenedor vulnerables. 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) Una vez que se descubre una vulnerabilidad en una imagen de contenedor, los administradores de malla pueden corregirla lo antes posible. Google controla automáticamente los parches de CVE que afectan las imágenes de malla.

Usa la federación de identidades para cargas de trabajo 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).

El panel de seguridad de GKE Enterprise muestra las políticas de seguridad 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 control de acceso a servicios) 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 los ataques de red si se transfieren a través de la red para la autenticación en 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.