Prácticas recomendadas de seguridad de Cloud Service Mesh

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 los parámetros de configuración y la instalación de Cloud Service Mesh, y se describe cómo puedes usar Cloud Service Mesh con otros productos y funciones de Google Cloud para protegerte de las amenazas de seguridad que las aplicaciones en una malla pueden enfrentar.

El público objetivo de este documento incluye administradores que controlan 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 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.

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 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.
    • Cloud Armor puede protegerte contra ataques externos de denegación de servicio distribuido (DSD) 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 la 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 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.
    • 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 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 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.
    • CNI (interfaz de red de contenedor) de Kubernetes evita los ataques de elevación de privilegios mediante la eliminación de la necesidad de un contenedor init 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 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 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

Las políticas de seguridad de Cloud Service Mesh (como las de autenticación y autorización) deben aplicarse 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 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 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, rechazar una solicitud no autorizada proveniente 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: las autenticaciones basadas en mTLS o en un token web JSON (JWT) deben usarse juntas 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 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.

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

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

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 para permitir que cierto tráfico interno o externo se excluya de las políticas de seguridad de Cloud Service Mesh, lo que crea problemas de seguridad.

Es posible que tengas motivos legítimos para omitir las políticas de seguridad de Cloud Service Mesh en algunos puertos y rangos de IP. Puedes agregar annotations (como excludeInboundPorts, excludeOutboundPorts o 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, 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 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 IP (ya sea de forma intencional o involuntaria), debe haber otras medidas de seguridad implementadas a fin de 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 con la política de seguridad de Cloud Service Mesh aplicada.
  • Aplica el Controlador de políticas de GKE Enterprise para validar automáticamente las políticas de Cloud Service Mesh. Por ejemplo, aplica que los sidecars de Cloud Service Mesh siempre se inyecten en las cargas de trabajo.

Aplica políticas de red de Kubernetes

Cloud Service Mesh 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 para que funcionen en conjunto 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 direcciones IP y puertos en 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 malla puede configurar las políticas de red de Kubernetes para permitir que el tráfico solo use puertos en los que se aplica la política de seguridad de Cloud Service Mesh. Si a todo el tráfico se le debe aplicar la 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 que tienen configurada 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 los clientes que se conectan. Por lo tanto, solo los emisores con credenciales válidas (JWT de Kubernetes o certificados X.509 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, se pueden implementar políticas de red de Kubernetes para aislar el espacio de nombres del sistema de Cloud Service Mesh (istio-system de forma predeterminada) de los espacios de nombres y los 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 las políticas de RBAC de Kubernetes para controlar quién puede 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 y omitan las aplicaciones de políticas 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 la federación de identidades para cargas de trabajo para GKE, 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 malla debe aplicar las políticas de seguridad de entrada, incluidas las políticas de TLS de la puerta de enlace, autenticación y autorización de Cloud Service Mesh para autenticar las solicitudes externas y verificar que estén autorizadas para acceder a los servicios que expone 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 incorrectamente las políticas de Cloud Service Mesh por accidente, lo que puede generar incidentes de seguridad graves. Para evitar una configuración incorrecta y validar de forma automática las políticas de Cloud Service Mesh, los administradores de la malla pueden usar el Controlador de políticas para aplicar restricciones a las políticas de configuración.

Para evitar generar demasiada confianza en las personas con permisos para actualizar las políticas de seguridad de Cloud Service Mesh y automatizar la validación de las políticas de Cloud Service Mesh, los administradores de 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, como 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 como se espera y validar que una implementación no incluya capacidades de raíz (como NET_ADMIN y NET_RAW).

El Controlador de políticas también puede auditar los recursos existentes de Cloud Service Mesh en comparación con las restricciones para detectar configuraciones incorrectas de políticas.

Los siguientes son algunos ejemplos de cómo el Controlador de políticas de GKE Enterprise aplica políticas de seguridad:

La biblioteca de plantillas de restricciones que se proporciona con Policy Controller 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 de seguridad específicas de Cloud Service Mesh, por ejemplo, políticas de autenticación, autorización y tráfico. Las siguientes son algunas restricciones de ejemplo incluidas en el paquete:

  • Aplica PeerAuthentication de mTLS estricta a nivel de malla.
  • Aplica que todos los PeerAuthentications no puedan reemplazar la mTLS estricta.
  • Aplica la denegación predeterminada a nivel de malla de AuthorizationPolicy.
  • Aplica los patrones seguros de AuthorizationPolicy.
  • Aplica que los sidecars de Cloud Service Mesh siempre se inyecten 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, recomendamos usar Google Cloud Observability (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 (CA) 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 AC, el administrador de la malla puede actualizar la malla a fin de usar la autoridad certificadora de Cloud Service Mesh o Certificate Authority Service (servicio de AC), que Google protege y administra. En comparación con la AC de Cloud Service Mesh, CA Service admite claves de firma por cliente a través de Cloud KMS respaldado por Cloud HSM. El servicio de AC también admite cargas de trabajo reguladas, mientras que la autoridad certificadora de Cloud Service Mesh no lo hace.

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 sidecar. 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 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

  • 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 Cloud Service Mesh administrado con el plano de datos administrado, 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 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 a servicios) 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?