Prácticas recomendadas de seguridad de Cloud Service Mesh

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 e instalar 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 Cloud Service Mesh y a los usuarios que ejecutan servicios en Cloud Service Mesh. Las medidas de seguridad que se describen aquí también son útiles para las organizaciones que necesitan mejorar la seguridad de sus mallas de servicios para cumplir 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. 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 conceder excepciones excluyendo determinadas aplicaciones, puertos o direcciones IP de la participación en una malla. Es importante contar con controles para gestionar las configuraciones de la 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 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 la sección Gestionar de forma segura las excepciones a las políticas.
  • 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.
    • 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.
    • Cloud Armor puede protegerte frente a ataques de denegación de servicio distribuido (DDoS) externos y de capa 7. Actúa como cortafuegos de aplicación web (WAF) para proteger la malla frente a ataques de red. Por ejemplo, ataques de inyección y de ejecución remota de código.
    • 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.
    • Las AC gestionadas, como la autoridad de certificación de Cloud Service Mesh y el servicio de autoridades de certificación, aprovisionan y gestionan 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 ofrece una monitorización de las configuraciones 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 de los pods en función de las direcciones IP, las etiquetas de los pods, los espacios de nombres y más.
    • La seguridad del plano de control protege frente a los ataques al plano de control. Esta protección evita que los atacantes modifiquen, exploten o filtren datos de configuración de servicios y de la malla.
  • 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 CNI (interfaz de red de contenedores) 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.
    • Google Cloud El registro de auditoría audita las operaciones de la malla.

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

Diagrama de seguridad del flujo de tráfico

Seguridad del clúster

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

Las políticas de seguridad de Cloud Service Mesh (como las políticas de autenticación y autorización) se deben aplicar a todo el tráfico que entra y sale 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 Cloud Service Mesh en algunos puertos y rangos de IPs. Por ejemplo, para establecer conexiones nativas con servicios que no gestiona Cloud Service Mesh. Para proteger la malla de servicios de Cloud en estos casos prácticos, consulta el artículo Gestionar de forma segura las excepciones de las políticas de la malla de servicios de Cloud.

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, 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 deben aplicarse en función de las identidades autenticadas derivadas de los resultados de la autenticación. Las autenticaciones basadas en mTLS o en tokens web JSON (JWT) deben usarse 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

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.

Las políticas de autorización de Cloud Service Mesh deben aplicarse 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, el acceso a un servicio debe denegarse 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 deben restringir la confianza tanto como sea posible. Por ejemplo, se puede definir el acceso a un servicio en función de las rutas de URL individuales expuestas por un servicio, de forma 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 protegerse frente a ataques de repetición de tokens, en los que se roban tokens y se reutilizan para acceder a servicios de la malla, un token de una solicitud procedente de fuera de la malla se debe intercambiar 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 protegerse frente a los ataques de repetición de tokens, un token de fuera de la malla se debe intercambiar por un token interno de la malla de corta duración con un ámbito limitado en la 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 cifrar. 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. Puede añadir anotaciones (como excludeInboundPorts, excludeOutboundPorts y excludeOutboundIPRanges) a los pods para evitar que el sidecar de Envoy gestione el tráfico. Además de las anotaciones para excluir el tráfico, puedes omitir la malla por completo si implementas una aplicación con la inyección de sidecar inhabilitada. Por ejemplo, añadiendo una etiqueta sidecar.istio.io/inject="false" al pod de la aplicación.

Si se omiten las políticas de seguridad de Cloud Service Mesh, se verá afectada negativamente 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 del puerto y se podrán producir escuchas o modificaciones del tráfico. Además, si se eluden 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.

Cuando se omite la política de seguridad de Cloud Service Mesh en un puerto o una IP (ya sea de forma intencionada o no), deben aplicarse otras medidas de seguridad para proteger la malla y monitorizar las excepciones de seguridad, las posibles vulnerabilidades de seguridad y el estado general de la aplicación de la seguridad. Para proteger tu malla en estos casos, puedes hacer lo siguiente:

  • Asegúrate 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 con la política de seguridad de Cloud Service Mesh aplicada.
  • Implementa GKE Enterprise Policy Controller para validar automáticamente las políticas de Cloud Service Mesh. Por ejemplo, puedes obligar a que los sidecars de Cloud Service Mesh se inserten siempre en las cargas de trabajo.

Aplicar 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, si no se controla quién puede actualizar los recursos de Kubernetes, un usuario puede cambiar el despliegue de Kubernetes de un servicio para omitir el sidecar del servicio.

Para conseguir una postura de seguridad sólida en una malla de servicios, los mecanismos de seguridad de la plataforma subyacente deben aplicarse para que funcionen conjuntamente 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 de los pods y los 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 políticas de red de Kubernetes para permitir que el tráfico use solo los puertos con la política de seguridad de Cloud Service Mesh aplicada. Si todo el tráfico debe aplicarse con mTLS de Cloud Service Mesh, el administrador puede configurar una política de red de Kubernetes para permitir el tráfico solo en los puertos que estén configurados con la política mTLS de Cloud Service Mesh. El administrador de la malla también puede configurar políticas de red de Kubernetes para limitar la conectividad de los puertos con excepciones de políticas. Por ejemplo, limita la conectividad de estos puertos a un espacio de nombres.

Acceso seguro al plano de control

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

Además del mecanismo de autenticación, en el caso de la malla de servicios de Cloud en el clúster, se pueden implementar políticas de red de Kubernetes para aislar el espacio de nombres del sistema de la malla de servicios de Cloud (istio-system de forma predeterminada) de los espacios de nombres no gestionados y de los clientes que no estén en la malla, al tiempo que se permite que los planos de datos accedan al plano de control. Las reglas de cortafuegos de VPC pueden impedir que el tráfico ajeno a un clúster llegue a Istiod. Con estas medidas de aislamiento de la red, un atacante que esté fuera de la malla no podrá acceder al plano de control, aunque tenga credenciales válidas. En el caso de los planos de control gestionados, Google se encarga de la seguridad de los planos de control, por lo que no se necesitan estas políticas de aislamiento de red para los planos de control.

Aplicar límites de espacio de nombres

Para evitar que un usuario de un espacio de nombres acceda o actualice recursos en un espacio de nombres no autorizado, sigue estos pasos:

Aplicar políticas de control de acceso basado en roles de Kubernetes

Los administradores de la malla deben aplicar políticas de control de acceso basado en roles (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 ni que eludan las medidas de cumplimiento de la política de Cloud Service Mesh. Los roles de un usuario deben estar vinculados a un espacio de nombres para que el usuario no pueda acceder a más espacios de nombres de los que necesita. Para consultar guías detalladas y ejemplos de configuración de RBAC, consulta Configurar el control de acceso basado en roles. Después de habilitar la federación de identidades de cargas de trabajo para GKE, también puedes permitir que una cuenta de servicio de Kubernetes actúe como una cuenta de servicio de gestión de identidades y accesos.

Seguridad de los extremos de la malla

Dado que la mayoría de los ataques también pueden proceder de fuera de un clúster, es fundamental garantizar la seguridad en el perímetro de la malla.

Control de acceso de entrada de clúster

Cloud Service Mesh recibe el tráfico externo entrante a través de la pasarela de entrada. Los servicios expuestos por la pasarela de entrada pueden sufrir ataques de fuentes externas. Los administradores de seguridad siempre deben asegurarse de que los servicios expuestos al tráfico externo a través de las pasarelas de entrada sean lo suficientemente seguros para defenderse de los ataques.

Ingress debe aplicar la autenticación y la autorización a los servicios expuestos a las llamadas externas.

  • Aplica políticas de seguridad de entrada de clústeres. Cuando el clúster necesite recibir tráfico externo, el administrador de la malla debe aplicar políticas de seguridad de entrada, incluidas las políticas de TLS de la pasarela, 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 expuestos por la pasarela de entrada. Aplicar políticas de seguridad de entrada protege contra ataques procedentes de fuera de la malla que intentan acceder a un servicio sin credenciales ni permisos válidos.
  • Usa Cloud Armor como cortafuegos de aplicación web (WAF) para protegerte frente a ataques web (por ejemplo, ataques de inyección y ataques de ejecución remota). Para obtener más información, consulta el artículo Del perímetro a la malla: exponer aplicaciones en una malla de servicios a través de Ingress de GKE.

Regular el tráfico de salida de un 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 frente a ataques de exfiltración de datos, aplicar el filtrado del tráfico de salida y aplicar la creació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 cortafuegos de VPC para restringir el tráfico de salida, los administradores de la malla también deben aplicar políticas de seguridad de salida en el clúster y configurar su tráfico de salida para que pase por las pasarelas de salida.

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

  • Ataques de filtración externa de datos.
  • Los pods de servicio pueden ser vulnerables a ataques si no se aplican parches a sus CVEs. Los pods vulnerados pueden convertirse en una botnet controlada por atacantes para enviar spam o lanzar ataques DoS.

Las políticas de autorización aplicadas a las pasarelas de salida pueden asegurar que solo los servicios autorizados puedan enviar tráfico a hosts concretos fuera de la malla. Mientras tanto, en el caso del tráfico que sale de la malla, en lugar de gestionar la creación de TLS en sidecars individuales, se puede crear en las pasarelas de salida. De esta forma, se proporciona una forma uniforme y más segura de originar el tráfico TLS, ya que los certificados de cliente de mTLS se pueden aislar de los espacios de nombres en los que se ejecutan las aplicaciones.

Usa un clúster privado o Controles de Servicio 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 de Servicio de VPC siempre que sea posible. Aunque 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 de Servicio de VPC.

Los Controles de Servicio de VPC se pueden aplicar para definir un perímetro de seguridad para los servicios con el fin de:

  • Restringe el acceso de los servicios a recursos externos.
  • Restringe el acceso de personas ajenas a los servicios de un perímetro de seguridad.

Controles de Servicio de VPC ayuda a protegerse frente a los ataques de exfiltración de datos e impide que los atacantes externos accedan a los servicios de una malla.

Protección frente a ataques DDoS externos

Los ataques DDoS externos pueden sobrecargar las pasarelas de entrada y los servicios de backend, lo que impide que se gestionen las solicitudes legítimas. Cloud Armor se puede usar para protegerse frente a ataques DDoS. Cloud Armor ofrece protección no solo frente a ataques DDoS de capa de red (L3 y L4), sino también de capa de aplicación (L7).

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

Es importante tener en cuenta la seguridad de las operaciones administrativas y de cualquier automatización que crees en torno a tu malla, como la integración continua y la entrega continua (CI/CD). Las siguientes prácticas tienen como objetivo asegurar que la malla se pueda utilizar de forma segura sin el riesgo de exponer los servicios a ataques adicionales.

Segmentar los roles utilizados en las operaciones de la malla

Siguiendo 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 solo se le debe conceder el conjunto mínimo de privilegios que necesite.

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

Hay diferentes categorías de operadores. Por ejemplo, los operadores de clúster y los operadores de espacio de nombres. Es importante evitar que un operador pueda apropiarse de privilegios, ya que esto puede provocar que se acceda de forma ilícita a recursos no autorizados.

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

Validar automáticamente las configuraciones de políticas

Los operadores pueden configurar por error las políticas de Cloud Service Mesh, lo que puede provocar incidentes de seguridad graves. Para evitar errores de configuración y validar automáticamente las políticas de Cloud Service Mesh, los administradores de la malla pueden usar Policy Controller para aplicar restricciones a las configuraciones de políticas.

Para evitar depositar demasiada confianza en personas con permisos para actualizar las políticas de seguridad de Cloud Service Mesh y para automatizar la validación de las políticas de Cloud Service Mesh, los administradores de la malla deben implementar restricciones en las políticas de Cloud Service Mesh mediante Policy Controller.

Policy Controller se basa en el proyecto de código abierto Gatekeeper y se puede ejecutar como controlador de admisión de Kubernetes para evitar que se apliquen recursos no válidos o en modo de auditoría para que los administradores reciban alertas sobre las infracciones. Policy Controller 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 las esperadas y validar que una implementación no incluya funciones raíz (como NET_ADMIN y NET_RAW).

Policy Controller también puede auditar recursos de Cloud Service Mesh para detectar errores de configuración de las políticas.

A continuación, se muestran algunos ejemplos de cómo aplica GKE Enterprise Policy Controller las 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 predefinido para aplicar prácticas recomendadas de seguridad específicas de Cloud Service Mesh, como las políticas de autenticación, autorización y tráfico. A continuación, se incluyen algunas restricciones de ejemplo del paquete:

  • Implementa el nivel de malla mTLS estricto PeerAuthentication.
  • Fuerza que ningún PeerAuthentication pueda sobrescribir mTLS estricto.
  • Implementa obligatoriamente la política de autorización denegar predeterminado a nivel de malla.
  • Aplica los patrones seguros de AuthorizationPolicy.
  • Fuerza que los sidecars de Cloud Service Mesh se inserten siempre en las cargas de trabajo.

Para gestionar las excepciones y las situaciones de emergencia, el administrador de la malla puede hacer lo siguiente:

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. Config Sync se puede usar para evitar la deriva de la configuración.

Implementar el registro de auditoría y la monitorización

Los administradores de la malla deben monitorizar lo siguiente:

Estos recursos de observabilidad se pueden usar 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 la suite de operaciones deGoogle Cloud (antes Stackdriver). La solución de observabilidad integrada de Google Cloud proporciona registro, recogida de métricas, monitorización y alertas, que se gestionan por completo y son fáciles de usar.

Proteger la autoridad de certificación de los certificados del clúster

De forma predeterminada, Cloud Service Mesh usa una autoridad de certificación (CA) gestionada por Google llamada autoridad de certificación de Cloud Service Mesh.

Si utilizas la autoridad de certificación (CA) de Istio no gestionada, que se aloja como parte de Istiod, la clave de firma de la CA se almacena en un secreto de Kubernetes y los operadores que tengan acceso al recurso secreto en el espacio de nombres istio-system pueden acceder a ella. Esto supone un riesgo, ya que un operador puede usar la clave de la AC independientemente de la AC 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 una CA autogestionada se filtre accidentalmente debido a un error operativo.

Para proteger la clave de firma de la AC, el administrador de la malla puede actualizarla para usar la autoridad de certificación de Cloud Service Mesh o el servicio de autoridad de certificación, que están protegidos y gestionados por Google. En comparación con la autoridad de certificación de Cloud Service Mesh, el servicio de AC admite claves de firma por cliente a través de Cloud KMS respaldadas por Cloud HSM. Servicio de AC también admite cargas de trabajo reguladas, mientras que la autoridad de certificación de Cloud Service Mesh no.

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.
  • Los pods de Kubernetes que se ejecutan en modo con privilegios pueden manipular pilas de red y otras funciones del kernel en el host. GKE Enterprise Policy Controller se puede usar para evitar que los pods ejecuten contenedores con privilegios.
  • Cloud Service Mesh se puede configurar para usar un contenedor init con el fin de configurar la redirección del tráfico de iptables al sidecar. Para ello, el usuario que realice las implementaciones de cargas de trabajo debe tener 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

  • Container Analysis. Container Analysis puede analizar y mostrar vulnerabilidades en cargas de trabajo de GKE.
  • Gestión de CVE (vulnerabilidades y exposiciones comunes). Cuando se descubre una vulnerabilidad en una imagen de contenedor, los administradores de la malla deben corregirla lo antes posible. En el caso de Cloud Service Mesh gestionado con plano de datos gestionado, 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. El panel de seguridad de GKE Enterprise y la telemetría se pueden usar 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 analiza y visualiza 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

Los datos o las credenciales de usuario sensibles pueden ser vulnerables a ataques procedentes de pods u operaciones maliciosas si se almacenan en el almacenamiento persistente del clúster, como los secretos de Kubernetes o directamente en los pods. También son vulnerables a ataques de red si se transfieren a través de la red para autenticarse en los 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 muchos privilegios.

Siguientes pasos