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

En este documento se describen las prácticas recomendadas para establecer y gestionar una configuración segura de Cloud Service Mesh en Google Kubernetes Engine (GKE). La guía va más allá de los ajustes que se usan para configurar y aprovisionar Cloud Service Mesh, y describe cómo puedes usar Cloud Service Mesh con otros productos y funciones para protegerte frente a las amenazas de seguridad a las que se pueden enfrentar las aplicaciones de una malla. Google Cloud

Este documento está dirigido a los administradores que gestionan políticas en una malla de servicios de Cloud y a los propietarios de servicios que ejecutan servicios en una malla de servicios de Cloud. 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 los requisitos.

El documento se organiza de la siguiente manera:

Introducción

Cloud Service Mesh ofrece funciones y herramientas que te ayudan a observar, gestionar y proteger servicios de forma unificada. Adopta un enfoque centrado en las aplicaciones y usa identidades de aplicaciones de confianza en lugar de un enfoque centrado en la IP de la red. Puede implementar una malla de servicios de forma transparente sin necesidad de modificar el código de aplicación. Cloud Service Mesh proporciona un control declarativo sobre el comportamiento de la red, lo que ayuda a separar el trabajo de los equipos responsables de ofrecer y lanzar funciones de aplicaciones de las responsabilidades de los administradores encargados de la seguridad y la red.

Cloud Service Mesh se basa en la malla de servicios Istio de código abierto, que permite configuraciones y topologías sofisticadas. En función de la estructura de tu organización, uno o varios equipos o roles pueden ser responsables de instalar y configurar una malla. Los ajustes predeterminados de Cloud Service Mesh se eligen para proteger las aplicaciones, pero, en algunos casos, es posible que necesites configuraciones personalizadas o que tengas que conceder excepciones excluyendo determinadas aplicaciones, puertos o direcciones IP de participar en una malla. Es importante contar con controles para gestionar las configuraciones de la malla y las excepciones de seguridad.

Este documento complementa la documentación de prácticas recomendadas de seguridad de Istio, que incluye recomendaciones de configuración detalladas para TLS mutuo (mTLS), políticas de autorización, gateways y otras configuraciones de seguridad. Considera estas recomendaciones como una base que debes usar junto con las prácticas recomendadas que se describen en este documento. En este documento se describen otras prácticas recomendadas 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 de 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 asume que las amenazas de seguridad proceden tanto del interior como del exterior del perímetro de seguridad de una organización. Estos son algunos ejemplos de tipos de ataques de seguridad que pueden amenazar las aplicaciones de una malla de servicios:

  • Ataques de filtración externa 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 hace pasar por un servicio legítimo para obtener o modificar la comunicación entre servicios.
  • Ataques de apropiación de privilegios. Por ejemplo, ataques que usan el acceso ilícito a privilegios elevados para llevar a cabo operaciones en una red.
  • Ataques de denegación de servicio (DoS).
  • Ataques de botnets que intentan poner en peligro y manipular servicios para lanzar ataques contra otros servicios.

Los ataques también se pueden clasificar en función de los objetivos:

  • Protege la red interna frente a ataques. Ataques dirigidos a manipular, espiar o suplantar la comunicación interna entre servicios o entre servicios y el plano de control de la malla.
  • Ataques al plano de control. Ataques dirigidos a provocar un fallo en el plano de control (como un ataque DoS) o a extraer datos sensibles del plano de control.
  • Ataques de borde de malla. Ataques dirigidos a manipular, espiar o suplantar la comunicación en la entrada o salida de la malla.
  • Ataques de operaciones de malla. Ataques dirigidos a las operaciones de la malla. Los atacantes pueden intentar obtener privilegios elevados para llevar a cabo operaciones maliciosas en una malla, como modificar sus políticas de seguridad e 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 posibles riesgos de seguridad:

  • Protección de seguridad incompleta. No se ha configurado una malla de servicios con políticas de autenticación y autorización para proteger su seguridad. Por ejemplo, no se han definido políticas de autenticación ni de autorización para los servicios de una malla.
  • Excepciones de la política de seguridad. Para adaptarse a sus casos prácticos específicos, los usuarios pueden crear excepciones de políticas de seguridad para que determinado tráfico (interno o externo) se excluya de las políticas de seguridad de Cloud Service Mesh. Para gestionar estos casos de forma segura, consulta Gestionar de forma segura las excepciones a las políticas en este documento.
  • No se actualizan las imágenes. Es posible que se descubran vulnerabilidades en las imágenes usadas en una malla. Debe 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 (no se dispone de experiencia ni recursos). El software de la malla y las configuraciones de las políticas necesitan un mantenimiento periódico para aprovechar los mecanismos de protección de seguridad más recientes.
  • Falta de visibilidad. Las configuraciones incorrectas o no seguras de las políticas de malla y el tráfico o las operaciones de malla anómalos no se comunican a los administradores de la malla.
  • Desviación de la configuración. La configuración de las políticas de una malla se desvía de la fuente de información veraz.

Medidas para proteger una malla de servicios

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

Arquitectura de seguridad

La seguridad de una malla de servicios depende de la seguridad de los componentes de las diferentes capas del sistema de malla y sus aplicaciones. El objetivo general 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, que, en conjunto, logran la seguridad general del sistema en el modelo de seguridad de confianza cero. En el siguiente diagrama se muestra la postura de seguridad propuesta para Cloud Service Mesh.

Postura de seguridad de Cloud Service Mesh

Cloud Service Mesh ofrece seguridad en varias capas, entre las que se incluyen las siguientes:

  • Seguridad de los extremos 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 de 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 con la infraestructura de Google para autenticar las llamadas externas de navegadores web a los servicios que ejecutan aplicaciones web.
    • La gestión de certificados de la puerta de enlace de Cloud Service Mesh protege y rota las claves privadas y los certificados X.509 que utilizan las puertas de enlace de entrada y salida de Cloud Service Mesh mediante el servicio de autoridad de certificación.
    • VPC y Controles de Servicio de VPC protegen el perímetro de la malla mediante controles de acceso a la red privada.
  • Seguridad del clúster
    • La autenticación TLS mutua (mTLS) de Cloud Service Mesh cifra y autentica el tráfico entre cargas de trabajo.
    • La autoridad de certificación de Cloud Service Mesh aprovisiona y gestiona de forma segura los certificados que usan las cargas de trabajo.
    • La autorización de Cloud Service Mesh aplica el control de acceso a los servicios de la malla en función de sus identidades y otros atributos.
    • El panel de control de seguridad de GKE Enterprise permite monitorizar las configuraciones de las políticas de seguridad y las políticas de red de Kubernetes de las cargas de trabajo.
    • Control de acceso de pods basado en políticas de red de Kubernetes que se aplica en función de las direcciones IP, las etiquetas de los pods, los espacios de nombres y más.
  • Seguridad de las cargas de trabajo
    • Mantente al día de las versiones de seguridad de Cloud Service Mesh para asegurarte de que los archivos binarios de Cloud Service Mesh que se ejecutan en tu malla no tengan vulnerabilidades conocidas públicamente.
    • Workload Identity Federation 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 los datos o las credenciales sensibles mediante 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 gestionadas por Cloud KMS.
    • La interfaz de red de contenedores (CNI) de Kubernetes evita los ataques de escalada de privilegios al eliminar la necesidad de un contenedor de inicialización 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 de los operadores para mitigar los ataques procedentes de operadores maliciosos o de suplantación de identidad.
    • Policy Controller de GKE Enterprise valida y audita las configuraciones de políticas en la malla para evitar errores de configuración.
    • Google Cloud Autorización binaria garantiza que las imágenes de carga de trabajo de la malla sean las autorizadas por los administradores.
    • Registros de auditoría de Cloud audita las operaciones de la 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 de los clústeres.

Habilitar TLS mutuo estricto

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 ataques de intermediario y de filtración externa de datos aplicando la autenticación y el cifrado con mTLS a todas las partes que se comunican. El modo permisivo usa mTLS cuando ambas partes lo admiten, pero permite conexiones sin mTLS. Por el contrario, mTLS estricto requiere que el tráfico se cifre y 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, de modo que se cumplan tus requisitos de seguridad y cumplimiento.

Para obtener más información, consulta Cloud Service Mesh mediante ejemplo: mTLS | Aplicar mTLS en toda la malla.

Habilitar controles de acceso

Recomendamos que se apliquen las políticas de seguridad de Cloud Service Mesh (como las políticas de autenticación y autorización) a todo el tráfico que entre y salga de la malla, a menos que haya motivos de peso 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 saltarse las políticas de seguridad de la malla de servicios de Cloud en algunos puertos y rangos de direcciones IP. Por ejemplo, para establecer conexiones nativas con servicios que no gestiona la malla de servicios de Cloud. Para proteger Cloud Service Mesh con estos casos prácticos, consulta Gestionar de forma segura las excepciones de las políticas de Cloud Service Mesh.

El control de acceso a los servicios es fundamental para evitar el acceso no autorizado a los servicios. La aplicación de mTLS cifra y autentica una solicitud, pero una malla sigue necesitando políticas de autorización de Cloud Service Mesh para aplicar el control de acceso a los servicios. Por ejemplo, puede rechazar una solicitud no autorizada procedente de un cliente autenticado.

Las políticas de autorización de Cloud Service Mesh ofrecen una forma flexible de configurar controles de acceso para proteger tus servicios frente a accesos no autorizados. Las políticas de autorización de Cloud Service Mesh se aplican en función de las identidades autenticadas derivadas de los resultados de la autenticación. La autenticación basada en mTLS o en tokens web JSON (JWT) se puede usar conjuntamente como parte de las políticas de autorización de Cloud Service Mesh.

Implementar obligatoriamente las políticas de autenticación de Cloud Service Mesh

Cuando tengas en cuenta las políticas de autenticación de Cloud Service Mesh, ten en cuenta los siguientes puntos.

JSON Web Token (JWT)

Además de la autenticación mTLS, los administradores de la malla pueden requerir que un servicio autentique y autorice las solicitudes basadas en JWT. Cloud Service Mesh no actúa como proveedor de JWT, sino que autentica los JWTs en función de los endpoints del conjunto de claves web de JSON (JWKS) configurados. La autenticación JWT se puede aplicar a las pasarelas de entrada para el tráfico externo o a los servicios internos para el tráfico dentro de la malla. La autenticación JWT se puede combinar con la autenticación mTLS cuando se usa un JWT como credencial para representar al llamante final y el servicio solicitado requiere una prueba de que se está llamando en nombre del llamante final. La autenticación con JWT protege contra los 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 navegador y el control de acceso a tus cargas de trabajo. Integra una malla de servicios con proveedores de identidades (IdP) para implementar un flujo de inicio de sesión y consentimiento estándar basado en web de OpenID Connect (OIDC), y usa políticas de autorización de Cloud Service Mesh para el control de acceso.

Aplicar políticas de autorización

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

  • Quién o qué puede 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 en función de las identidades reales con las que se ejecutan los servicios, las propiedades de la capa de aplicación (capa 7) del tráfico (por ejemplo, los encabezados de solicitud) y las propiedades de la capa de red (capas 3 y 4), como los intervalos de IP y los 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 la autenticación para protegerse contra el acceso no autorizado a servicios o datos.

De forma predeterminada, se deniega el acceso a un servicio a menos que se defina explícitamente una política de autorización para permitir el acceso al servicio. Consulta las prácticas recomendadas de la política de autorización para ver ejemplos de políticas de autorización que deniegan solicitudes de acceso.

Las políticas de autorización tienen como objetivo restringir la confianza lo máximo posible. Por ejemplo, el acceso a un servicio se puede definir en función de las rutas de URL individuales expuestas por 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 (capas 3 y 4) y controlan el acceso a la red de las direcciones IP y los puertos de los pods y los espacios de nombres de Kubernetes.

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

Para protegerte frente a los ataques de repetición de tokens, que roban tokens y los reutilizan para acceder a los servicios de la malla, asegúrate de que un token de una solicitud procedente de 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 la malla debe incluir un token, como un JWT o una cookie, para que el servicio de la malla la autentique y autorice. Un token de fuera de la malla puede tener una larga duración. Para protegerte frente a ataques de repetición de tokens, intercambia un token de fuera de la malla por un token interno de la malla de corta duración y con un ámbito limitado en el punto de entrada de la malla. El servicio de malla autentica un token interno de la malla y autoriza la solicitud de acceso en función del token interno de la malla.

Cloud Service Mesh admite la integración con Identity-Aware Proxy (IAP), que genera un RequestContextToken (un token interno de la malla de corta duración 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 ámbito y el tiempo de vida limitados del token intercambiado reducen considerablemente la probabilidad de que se produzca un ataque de repetición de tokens.

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

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

Puede que tengas motivos legítimos para omitir las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de IP. Puedes añadir anotaciones, como excludeInboundPorts, excludeOutboundPorts y excludeOutboundIPRanges, a los pods para evitar que el tráfico se gestione mediante el sidecar de Envoy. Además de las anotaciones para excluir tráfico, puedes omitir la malla por completo desplegando una aplicación con la inyección de sidecar inhabilitada. Por ejemplo, puedes añadir una etiqueta sidecar.istio.io/inject="false" al pod de la aplicación.

Saltarse 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 mTLS y de autorización de Cloud Service Mesh en un puerto de red mediante anotaciones, no habrá control de acceso para el tráfico del puerto y se podría interceptar o modificar el tráfico. Además, si se omiten las políticas de Cloud Service Mesh, también se verán afectadas las políticas que no son de seguridad, como las políticas de red.

Si se elude la política de seguridad de Cloud Service Mesh en un puerto o una dirección IP (ya sea de forma intencionada o no), te recomendamos que implementes otras medidas de seguridad para proteger la malla y monitorizar las excepciones de seguridad, las posibles vulnerabilidades y el estado general de la aplicación de la seguridad. Para proteger tu malla en estas situaciones, puedes hacer lo siguiente:

  • Asegúrese de que el tráfico que elude los sidecars esté cifrado y autenticado de forma nativa para evitar ataques MitM.
  • Aplica 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 que solo permita el tráfico de otro servicio del mismo espacio de nombres o para que solo permita que el tráfico pase por los puertos que tienen aplicada la política de seguridad de Cloud Service Mesh.

Usar un enfoque de GitOps con Config Sync para evitar la deriva de la configuración

La deriva de configuración se produce cuando la configuración de las políticas de una malla se desvía de su fuente de información veraz. Puedes usar Config Sync para evitar la deriva de la configuración.

Aplicar Cloud Audit Logs y la monitorización

Recomendamos que los administradores de la malla monitoricen lo siguiente:

Los administradores pueden usar estos recursos de observabilidad para verificar que la configuración de seguridad funciona correctamente y para monitorizar las excepciones a la aplicación de la política de seguridad. Por ejemplo, el acceso que no se ha realizado a través de sidecars o el acceso que no tenía credenciales válidas, pero ha llegado a un servicio.

Aunque el software de observabilidad de código abierto (por ejemplo, Prometheus) se puede usar con Cloud Service Mesh, te recomendamos que utilices Google Cloud Observability. Esta solución de observabilidad integrada para Google Cloud proporciona registro, recogida de métricas, monitorización y alertas, y está totalmente gestionada.

Seguridad de las cargas de trabajo

La seguridad de las cargas de trabajo protege contra los ataques que ponen en peligro los pods de las cargas de trabajo y, a continuación, usan los pods vulnerados para lanzar ataques contra el clúster (por ejemplo, ataques de botnets).

Restringir los privilegios de Pod

Un pod de Kubernetes puede tener privilegios que afecten a otros pods del nodo o del clúster. Es importante aplicar restricciones de seguridad en los pods de las cargas de trabajo para evitar que un pod vulnerado lance ataques contra el clúster.

Para aplicar el principio de mínimos accesos a las cargas de trabajo de un pod, haz lo siguiente:

  • Los servicios implementados en una malla deben ejecutarse con los mínimos privilegios posibles.
  • Puedes configurar Cloud Service Mesh para que use un contenedor init para configurar la redirección del tráfico de iptables al sidecar. Para ello, el usuario debe crear implementaciones de cargas de trabajo que tengan privilegios para implementar contenedores con las funciones NET_ADMIN y NET_RAW. Para evitar el riesgo de ejecutar contenedores con privilegios elevados, los administradores de la malla pueden habilitar el plugin CNI de Istio para configurar la redirección del tráfico a los sidecars.

Proteger imágenes de contenedor

Los atacantes pueden lanzar ataques aprovechando imágenes de contenedor vulnerables. Los administradores deben aplicar la autorización binaria para verificar la integridad de las imágenes de contenedor y asegurarse de que solo se desplieguen imágenes de contenedor de confianza en la malla.

Mitigar las vulnerabilidades de la malla

  • Artifact Analysis puede analizar y mostrar vulnerabilidades en cargas de trabajo de GKE.
  • Gestión de vulnerabilidades y exposiciones comunes (CVE). Cuando se descubre una vulnerabilidad en una imagen de contenedor, los administradores de la malla pueden corregirla lo antes posible. Google se encarga automáticamente de aplicar parches a las CVEs que afectan a las imágenes de la malla.

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

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

Monitorizar el estado de seguridad a través del panel de control de seguridad y la telemetría

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

La telemetría monitoriza el estado y el rendimiento de los servicios de una malla, lo que permite a los administradores de la malla observar el comportamiento de los servicios (como los SLOs, el tráfico anómalo, las interrupciones del servicio o la topología).

El panel de control de seguridad de GKE Enterprise muestra las políticas de seguridad aplicadas 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 las políticas de autenticación (mTLS).

Seguridad de los datos y las credenciales de usuario sensibles

Si almacenas datos de usuario o credenciales sensibles en el almacenamiento persistente del clúster, como secretos de Kubernetes o directamente en pods, los datos o las credenciales pueden ser vulnerables a ataques procedentes de pods u operaciones maliciosas. Los datos también son vulnerables a los ataques de red si se transfieren a través de la red para autenticar servicios.

  • Si es posible, almacena los datos y las credenciales de usuario sensibles en un almacenamiento protegido, como Secret Manager y Cloud KMS.
  • Designa espacios de nombres independientes para los pods de Kubernetes que accedan a datos sensibles y define políticas de Kubernetes para que no se pueda acceder a ellos desde otros espacios de nombres. Segmenta los roles que se usan en las operaciones y aplica límites de espacio de nombres.
  • Implementa el intercambio de tokens para evitar la filtración de tokens de larga duración y con privilegios elevados.