Prácticas recomendadas de seguridad de Cloud Service Mesh

En este documento, se describen las prácticas recomendadas para establecer y administrar una configuración segura de Cloud Service Mesh que se ejecute en Google Kubernetes Engine (GKE). La guía del documento va más allá de la configuración que se usa para instalar y configurar 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 pueden enfrentar las aplicaciones en una malla.

El público objetivo de este documento incluye administradores que gestionan políticas en Cloud Service Mesh y usuarios que ejecutan servicios en Cloud Service Mesh. Las medidas de seguridad descritas aquí también son útiles para las organizaciones que necesitan mejorar la seguridad de sus mallas de servicios a fin de cumplir con los requisitos normativos.

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 los servicios 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 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 responsables de la seguridad y las herramientas de redes.

Cloud Service Mesh se basa en la malla de servicios de Istio de código abierto, lo que permite configuraciones y topologías 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. La configuración predeterminada de Cloud Service Mesh se elige para proteger las aplicaciones, pero, en algunos casos, es posible que necesites configuraciones personalizadas o para otorgar excepciones a fin de excluir ciertas apps, puertos o direcciones IP para que no participen en una malla. Es importante tener controles para administrar las configuraciones de malla y las excepciones de seguridad.

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 pueden 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 la sección Maneja las excepciones a las políticas de forma segura.
  • 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 propuesta de Cloud Service Mesh es proteger una malla de servicios a través de la integración de varios mecanismos de seguridad en diferentes capas, lo que logra de forma conjunta la seguridad general del sistema bajo el modelo de seguridad de confianza cero. En el siguiente diagrama, se muestra la postura de seguridad propuesta por Cloud Service Mesh.

de seguridad de Cloud Service Mesh

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

  • 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 que exponen 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 desde navegadores web a los servicios que ejecutan aplicaciones web.
    • La administración de certificados de 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.
    • Cloud Armor puede defenderse de ataques de denegación de servicio distribuido (DSD) externos y de capa 7. Actúa como un firewall de aplicación web (WAF) para proteger la malla contra ataques de red. Por ejemplo, ataques de inyección y ejecución de código remoto.
    • 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 autenticación del tráfico de carga de trabajo a carga de trabajo.
    • La AC administrada, como la autoridad certificadora de Cloud Service Mesh y Certificate Authority Service, 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 a los servicios de la malla según sus identidades y otros atributos.
    • El panel de seguridad de GKE Enterprise proporciona supervisión de la configuración de las políticas de seguridad y las políticas de red de Kubernetes para las cargas de trabajo.
    • La política de red de Kubernetes aplica el control de acceso a los Pods según las direcciones IP, las etiquetas de Pod, los espacios de nombres y otros.
    • La seguridad del plano de control protege contra los ataques en el plano de control. Esta protección evita que los atacantes modifiquen, exploten o filtren datos de configuración de servicios y mallas.
  • Seguridad de las cargas de trabajo
    • Mantente al día con las versiones de seguridad de Cloud Service Mesh para asegurarte de que los objetos binarios de Cloud Service Mesh que se ejecutan en ella no tengan vulnerabilidades conocidas de forma pública.
    • Workload Identity permite que las cargas de trabajo obtengan credenciales para llamar de manera 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 CA, 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 CNI (Container Network Interface) de Kubernetes previene los ataques de elevación de privilegios, ya que elimina 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.
    • El controlador de políticas de GKE Enterprise valida y audita la configuración 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.
    • Google Cloud Audit Logging audita 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 del diagrama de seguridad

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 es la defensa contra los ataques de robo de datos y de MitM, ya que aplica la autenticación y encriptación de mTLS para todas las partes comunicaciones. 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 Cloud Service Mesh por ejemplo: mTLS | Aplica mTLS en toda la malla.

Habilita los controles de acceso

Las políticas de seguridad de Cloud Service Mesh (como las políticas de autenticación y autorización) deben aplicarse a todo el tráfico que entra y sale 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 para algunos puertos y rangos de IP. Por ejemplo, para establecer conexiones nativas con servicios no administrados por Cloud Service Mesh. Para proteger Cloud Service Mesh en esos casos de uso, consulta Controla de forma segura las excepciones de la política 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 la 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, rechazar una solicitud no autorizada proveniente de un cliente autenticado.

Las políticas de autorización de Cloud Service Mesh proporcionan una forma flexible de configurar los controles de acceso para proteger los servicios contra el acceso no autorizado. Las políticas de autorización de Cloud Service Mesh deben aplicarse según las identidades autenticadas que derivan de los resultados de la autenticación. Las autenticaciones basadas en mTLS o JSON Web Token (JWT) se deben 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

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 los 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 del usuario final basada en el navegador y el control de acceso a tus cargas de trabajo. Integra una malla de servicios con los proveedores de identidad (IdP) existentes para implementar un flujo de acceso y consentimiento de OpenID Connect (OIDC) estándar basado en la Web y usa las políticas de autorización de Cloud Service Mesh 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 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.

Las políticas de autorización de Cloud Service Mesh se deben aplicar según 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 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.

Las políticas de autorización deben restringir la confianza tanto como sea posible. Por ejemplo, el acceso a un servicio se puede definir según las rutas de URL individuales expuestas por un servicio, de modo que solo un servicio A pueda acceder a la ruta /admin de un 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

A fin de protegerse de los ataques de repetición de tokens que roban tokens y vuelven a usarlos para acceder a los servicios de la malla, se debe intercambiar un token de una solicitud desde fuera de la malla por un token de corta duración interno de la malla 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, a fin de que el servicio de malla lo autentique y autorice. Un token desde fuera de la malla puede ser de larga duración. A fin de protegerse de los ataques de repetición de tokens, se debe intercambiar 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 interno de la malla de corta duración intercambiado por 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.

Controla de forma segura las excepciones a la política de Cloud Service Mesh

Puedes tener 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 a fin de 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 para algunos puertos y rangos de IP. Puedes agregar anotaciones (como excludeInboundPorts, excludeOutboundPorts y excludeOutboundIPRanges) a los Pods para evitar que el archivo adicional de Envoy controle el tráfico. 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, puedes agregar 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 la mTLS de Cloud Service Mesh para un puerto de red a través de anotaciones, no habrá control de acceso para el tráfico en el puerto y es posible que sea posible espiar o modificar el 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 de red.

Cuando se omite la política de seguridad de Cloud Service Mesh para un puerto o una IP (de forma intencional o no), debe haber otras medidas de seguridad implementadas a fin de proteger la malla y supervisar las excepciones de seguridad, los posibles vacíos de seguridad y el estado de aplicación de la seguridad general. 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, limitar un puerto con excepciones de políticas a fin de permitir solo el tráfico de otro servicio en el mismo espacio de nombres) o para permitir que solo el tráfico pase a través de los puertos con la política de seguridad de Cloud Service Mesh aplicada.
  • Aplica el controlador de políticas empresariales de GKE para validar de forma automática las políticas de Cloud Service Mesh. Por ejemplo, aplica que los sidecars de Cloud Service Mesh siempre se inserten en las cargas de trabajo.

Aplica políticas de red de Kubernetes

La malla de servicios de Cloud se basa en la plataforma subyacente (por ejemplo, Kubernetes). Por lo tanto, la seguridad de Cloud Service Mesh depende de la seguridad de la plataforma subyacente. Por ejemplo, sin control sobre quién puede actualizar los recursos de Kubernetes, un usuario puede cambiar la implementación de Kubernetes de un servicio para omitir el sidecar del servicio.

Para formar una postura de seguridad sólida para una malla de servicios, se deben aplicar los mecanismos de seguridad de la plataforma subyacente de modo que funcionen de forma conjunta con las políticas de seguridad de Cloud Service Mesh.

Las políticas de red de Kubernetes operan en la capa de red (L3 y L4) para las direcciones IP y los puertos en los Pods y espacios de nombres de Kubernetes. Las políticas de red de Kubernetes se pueden aplicar junto con las políticas de Cloud Service Mesh para mejorar la seguridad de la malla.

Por ejemplo, el administrador de la malla puede configurar las políticas de red de Kubernetes para permitir que solo el tráfico use puertos con la política de seguridad de Cloud Service Mesh aplicada. Si todo el tráfico se debe aplicar de manera forzosa con mTLS de Cloud Service Mesh, el administrador puede configurar una política de red de Kubernetes para permitir solo el tráfico en los puertos configurados con la política de mTLS de Cloud Service Mesh. El administrador de la malla también puede configurar las políticas de red de Kubernetes para limitar la conectividad de los puertos con excepciones de políticas. Por ejemplo, limita la conectividad de esos puertos para que estén dentro de un espacio de nombres.

Protege el acceso al plano de control

El plano de control de Cloud Service Mesh autentica a todos los clientes que se conectan. Por lo tanto, solo los llamadores con credenciales válidas (certificados JWT o X.509 de Kubernetes emitidos por AC permitidas) pueden acceder al plano de control de Cloud Service Mesh. TLS encripta las conexiones entre las cargas de trabajo y el plano de control de Cloud Service Mesh.

Además del mecanismo de autenticación, para Cloud Service Mesh en el clúster, las políticas de red de Kubernetes se pueden implementar a fin de aislar el espacio de nombres del sistema de Cloud Service Mesh (de forma predeterminada, istio-system) de espacios de nombres y clientes no administrados fuera de la malla, a la vez que se permite que los planos de datos accedan al plano de control. Las reglas de firewall de VPC pueden evitar que el tráfico fuera de un clúster llegue a Istiod. Con esas medidas de aislamiento de red, un atacante desde fuera de la malla no podrá acceder al plano de control, incluso si tiene una credencial válida. En los planos de control administrados, Google controla la seguridad de los planos de control y esas políticas de aislamiento de red para los planos de control no son necesarias.

Aplica límites de espacios de nombres

Para evitar que un usuario de un espacio de nombres acceda o actualice los recursos en un espacio de nombres no autorizado, haz lo siguiente:

  • Aplica controles de acceso.
  • Aplica políticas de red de Kubernetes Si los servicios en un espacio de nombres no tienen tráfico fuera del espacio de nombres, el administrador de la malla debe implementar una política de red de Kubernetes que solo permita el tráfico dentro del espacio de nombres: no hay entrada ni salida del espacio de nombres.
  • Aplica las políticas de RBAC de Kubernetes.
    • Los roles de los administradores de aplicaciones se deben vincular a un espacio de nombres.
    • Solo permite que los administradores de malla tengan ClusterRole.

Aplica las políticas de RBAC de Kubernetes

Los administradores de la malla deben aplicar políticas de RBAC de Kubernetes para controlar quién tiene permiso para acceder a los recursos de Kubernetes y actualizarlos. El control de acceso de Kubernetes puede mitigar los riesgos de seguridad en la malla. Por ejemplo, no se debe permitir que los usuarios no autorizados cambien las implementaciones de Kubernetes ni omitan las aplicaciones de la política de Cloud Service Mesh. Los roles de un usuario deben vincularse a un espacio de nombres para que el usuario no tenga acceso a más espacios de nombres que los necesarios. Para obtener guías detalladas y ejemplos de configuración de RBAC, consulta Configura el control de acceso basado en roles. Después de habilitar Workload Identity, también puedes permitir que una cuenta de servicio de Kubernetes actúe como una cuenta de servicio de IAM.

Seguridad perimetral de la malla

Debido a que la mayoría de los ataques también se originan fuera del clúster, es fundamental garantizar la seguridad en el perímetro de la malla.

Control de acceso de entrada del clúster

Cloud Service Mesh recibe tráfico externo entrante a través de la puerta de enlace de entrada. Los servicios que expone la puerta de enlace de entrada pueden enfrentar ataques de fuentes externas. Los administradores de seguridad siempre deben asegurarse de que los servicios expuestos al tráfico externo a través de puertas de enlace de entrada tengan protección suficiente para defenderse de los ataques.

Ingress debe aplicar la autenticación y la autorización para los servicios expuestos a emisores externos.

  • Aplica políticas de seguridad de entrada del clúster. Cuando el clúster necesita recibir tráfico externo, el administrador de la malla debe aplicar políticas de seguridad de entrada, como la TLS de la puerta de enlace de Cloud Service Mesh, la autenticación y las políticas de autorización, para autenticar solicitudes externas y verificar que las solicitudes externas estén autorizadas a acceder a los servicios expuestos por la puerta de enlace de entrada. La aplicación de políticas de seguridad de entrada protege contra ataques desde fuera de la malla que intentan acceder a un servicio sin credenciales o permisos válidos.
  • Usa Cloud Armor como un firewall de aplicación web (WAF) para protegerte contra ataques basados en la Web (por ejemplo, ataques de inyección y de ejecución remota). Para obtener más información, consulta Del perímetro a la malla: Exposición de las aplicaciones de la malla de servicios a través de Ingress de GKE.

Regula el tráfico de salida del clúster

La seguridad de salida del clúster es fundamental para la seguridad de la malla, ya que las políticas de seguridad de salida pueden proteger de los ataques de robo de datos, aplicar un filtrado del tráfico de salida y aplicar la iniciación de TLS para el tráfico de salida. Los administradores de seguridad deben regular y auditar el tráfico de salida del clúster.

Además de usar los muros de firewall de VPC a fin de restringir el tráfico de salida, los administradores de la malla también deben aplicar políticas de seguridad de salida para el clúster y configurar su tráfico saliente para que pase por las puertas de enlace de salida.

Las políticas de salida pueden mitigar los siguientes ataques:

  • Ataques de robo de datos.
  • Los atacantes pueden aprovechar los Pods de servicio si sus CVE no tienen parches. Los Pods vulnerados pueden convertirse en un botnet controlado por atacantes para enviar spam o iniciar ataques de DoS.

Las políticas de autorización aplicadas a las puertas de enlace de salida pueden garantizar que solo los servicios autorizados puedan enviar tráfico a hosts particulares fuera de la malla. Mientras tanto, para el tráfico que sale de la malla, en lugar de manejar la iniciación de TLS en sidecars individuales, TLS se puede iniciar en puertas de enlace de salida. Esto proporciona una manera uniforme y más segura de iniciar tráfico TLS porque los certificados de cliente para mTLS pueden aislarse de los espacios de nombres en los que se ejecutan las aplicaciones.

Usa un clúster privado o un Control de servicios de VPC para bloquear los accesos externos

Además de aplicar políticas de seguridad de entrada y salida, bloquea el acceso externo mediante clústeres privados o Controles del servicio de VPC siempre que sea posible. Si bien los administradores de seguridad de la malla controlan las políticas de seguridad, los administradores de seguridad de la organización pueden aplicar la configuración del clúster privado o los Controles del servicio de VPC.

Se pueden aplicar los Controles del servicio de VPC a fin de definir un perímetro de seguridad para los servicios para realizar las siguientes acciones:

  • Restringir el acceso de los servicios a los recursos externos
  • Restringir a los usuarios externos para que no accedan a los servicios en un perímetro de seguridad

Los Controles del servicio de VPC ayudan a defenderse de los ataques de robo de datos y evitan que los atacantes externos accedan a los servicios dentro de una malla.

Protégete contra ataques externos de DSD

Los ataques DSD externos pueden sobrecargar los servicios de backend y las puertas de enlace de entrada, lo que evita que se manejen las solicitudes legítimas. Puedes usar Cloud Armor para protegerte contra ataques de DSD. Cloud Armor protege no solo contra ataques de DSD de la capa de red (L3 y L4), sino también contra ataques de DSD de la capa de aplicación (L7).

Seguridad para la automatización y la administración de mallas

Es importante tener en cuenta la seguridad para las operaciones administrativas y cualquier automatización que compiles en torno a tu malla, por ejemplo, CI/CD. Las siguientes prácticas tienen como objetivo garantizar que la malla se pueda operar de forma segura sin el riesgo de exponer servicios a ataques adicionales.

Segmenta los roles que se usan para las operaciones de malla

De acuerdo con el mismo principio que el control de acceso basado en roles, los usuarios de una malla deben clasificarse según sus roles. A cada rol se le debe otorgar el conjunto mínimo de privilegios que necesita.

Por ejemplo, el conjunto de usuarios que realizan implementaciones de servicio no debe tener privilegios para actualizar las políticas de autenticación y autorización.

Existen diferentes categorías de operadores. Por ejemplo, los operadores de clústeres y los de espacios de nombres. Es importante evitar la elevación de privilegios de un operador, lo que puede provocar un acceso ilícito a recursos no autorizados.

Las políticas de RBAC de Kubernetes permiten que los administradores de malla limiten el acceso a los recursos solo a los usuarios autorizados.

Valida automáticamente las configuraciones de políticas

Los operadores pueden configurar de forma incorrecta las políticas de Cloud Service Mesh de forma accidental, lo que puede generar incidentes de seguridad graves. Para evitar la configuración incorrecta y validar automáticamente las políticas de Cloud Service Mesh, los administradores de la malla pueden usar el controlador de políticas para aplicar restricciones en la configuración de las políticas.

A fin de evitar confiar demasiado en las personas con permisos para actualizar las políticas de seguridad de Cloud Service Mesh y automatizar su validación, los administradores de la malla deben implementar restricciones en las políticas de Cloud Service Mesh mediante el Controlador de políticas.

El Controlador de políticas se basa en el proyecto de código abierto Gatekeeper y se puede ejecutar como un controlador de admisión de Kubernetes para impedir que se apliquen recursos no válidos o en modo de auditoría a fin de que los administradores puedan recibir alertas de incumplimientos. El controlador de políticas puede validar automáticamente la implementación de recursos en la malla, por ejemplo, validar que las anotaciones de una implementación no omitan las políticas de Cloud Service Mesh, validar que las políticas de Cloud Service Mesh sean las esperadas y validar que una implementación no incluya capacidades raíz (como NET_ADMIN y NET_RAW).

El controlador de políticas también puede auditar recursos existentes de Cloud Service Mesh en función de restricciones para detectar parámetros de configuración incorrectos de la política.

A continuación, se muestran algunos ejemplos del controlador de políticas de GKE Enterprise que aplica políticas de seguridad:

La biblioteca de plantillas de restricciones que se proporciona con el controlador de políticas contiene un conjunto de plantillas de restricciones que se pueden usar con el paquete de restricciones de seguridad de Cloud Service Mesh listo para usar para aplicar prácticas recomendadas específicas de seguridad de Cloud Service Mesh, por ejemplo, autenticación, autorización y políticas de tráfico. Las siguientes son algunas restricciones de ejemplo incluidas en el paquete:

  • Aplica de manera forzosa el PeerAuthentication estricto de mTLS a nivel de la malla.
  • Aplica que todos los PeerAuthentications no puedan reemplazar la mTLS estricta.
  • Aplica de manera forzosa la AuthorizationPolicy del nivel de malla defaultDeny.
  • Aplica los patrones seguros de AuthorizationPolicy.
  • Aplica los sidecars de Cloud Service Mesh siempre se insertan en las cargas de trabajo.

Para controlar excepciones y situaciones de emergencia, el administrador de malla puede hacer lo siguiente:

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. El Sincronizador de configuración se puede usar para evitar el desvío de configuración.

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

Los administradores de malla deben supervisar lo siguiente:

Estos recursos de observabilidad se pueden usar 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, te recomendamos que uses Google Cloud's operations suite (antes conocido como Stackdriver). La solución de observabilidad integrada para Google Cloud proporciona registro, recopilación de métricas, supervisión y alertas, y es completamente administrado y fácil de usar.

Protege la autoridad certificadora para los certificados en el clúster

De forma predeterminada, Cloud Service Mesh usa una autoridad certificadora (AC) administrada por Google llamada autoridad certificadora de Cloud Service Mesh.

Si usas la autoridad certificada (CA) de Istio no administrada, que se aloja como parte de Istio, la clave de firma de CA se almacena en un Secret de Kubernetes y pueden acceder a ella los operadores que tienen acceso al recurso de Secret en el espacio de nombres istio-system. Esto es un riesgo, ya que un operador puede usar la clave de CA de forma independiente de la CA de Istiod y, potencialmente, firmar certificados de carga de trabajo de forma independiente. También existe el riesgo de que una clave de firma de CA autoadministrada se filtre por accidente debido a un error operativo.

Para proteger la clave de firma de la AC, el administrador de la malla puede actualizarla a fin de usar la autoridad certificadora de Cloud Service Mesh o el Servicio de autoridad certificadora (Servicio de CA), que Google protege y administra. En comparación con la autoridad certificadora de Cloud Service Mesh, CA Service admite claves de firma por cliente a través de Cloud KMS, respaldadas por Cloud HSM. El servicio de CA también admite cargas de trabajo reguladas, mientras que la autoridad certificadora de Cloud Service Mesh no.

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.
  • Los Pods de Kubernetes que se ejecutan en modo privilegiado pueden manipular las pilas de red y otras funciones del kernel en el host. El controlador de políticas de GKE Enterprise se puede usar para evitar que los Pods ejecuten contenedores con privilegios.
  • Cloud Service Mesh se puede configurar para usar un contenedor init a fin de configurar el redireccionamiento del tráfico de iptables al archivo adicional. Esto requiere que el usuario que realiza las implementaciones de carga de trabajo tenga privilegios para implementar contenedores con funciones NET_ADMIN y NET_RAW. Para evitar el riesgo de ejecutar contenedores con privilegios elevados, los administradores de mallas pueden enable el complemento CNI de Istio 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

  • Container Analysis. Container Analysis puede analizar y mostrar vulnerabilidades en las cargas de trabajo de GKE.
  • Manejo de CVE (vulnerabilidades y riesgos comunes) Una vez que se descubre una vulnerabilidad en una imagen de contenedor, los administradores de malla deben corregirla lo antes posible. Para la malla de servicios de Cloud administrada con el plano de datos administrado, Google controla de forma automática la aplicación de parches a las CVE que afectan las imágenes de la malla.

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

Workload Identity es la forma recomendada para que las cargas de trabajo de malla accedan a los servicios de Google de forma segura. La alternativa a 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. El panel de seguridad de GKE Enterprise y la telemetría se pueden usar 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 analiza y visualiza 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 de servicio) y políticas de autenticación (mTLS).

Seguridad para las credenciales y datos sensibles del usuario

Los datos sensibles del usuario o las credenciales pueden ser vulnerables a ataques que se originan en Pods u operaciones maliciosas si se almacenan en el almacenamiento persistente del clúster, como el uso de Secrets de Kubernetes o directamente en Pods. 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.

¿Qué sigue?