Zona de pruebas de GKE

En esta página, se describe cómo GKE Sandbox protege el kernel del host en tus nodos cuando los contenedores del pod ejecutan un código desconocido o que no es de confianza. Por ejemplo, los clústeres multiusuario, como los proveedores de software como servicio (SaaS), suelen ejecutar código desconocido que envían los usuarios. GKE Sandbox también es una medida de defensa útil en profundidad para ejecutar contenedores de alto valor.

GKE Sandbox usa gVisor, un proyecto de código abierto. En este tema, se explica gVisor en líneas generales, pero puedes obtener más detalles en la documentación oficial de gVisor.

Para obtener instrucciones sobre cómo habilitar y usar GKE Sandbox, consulta Configura GKE Sandbox.

Descripción general

GKE Sandbox proporciona una capa adicional de seguridad para evitar que el código no confiable afecte al kernel del host en los nodos de clústeres. Antes de analizar cómo funciona GKE Sandbox, es útil comprender la naturaleza de los riesgos potenciales que ayuda a mitigar.

Un entorno de ejecución de contenedor como containerd proporciona cierto grado de aislamiento entre los procesos del contenedor y el kernel que se ejecuta en el nodo. Sin embargo, el entorno de ejecución del contenedor a menudo se ejecuta como un usuario privilegiado en el nodo y tiene acceso a la mayoría de las llamadas del sistema al kernel del host.

Amenazas potenciales

Los clústeres de múltiples instancias y aquellos cuyos contenedores ejecutan cargas de trabajo que no son de confianza están más expuestos a vulnerabilidades de seguridad que otros clústeres. Los ejemplos incluyen proveedores de SaaS, proveedores de hosting web y otras organizaciones que permiten a sus usuarios subir y ejecutar código. Una falla en el entorno de ejecución del contenedor o en el kernel del host podría permitir que un proceso que se ejecuta dentro de un contenedor “escape” de este y afecte al kernel del nodo, lo que podría provocar la caída del nodo.

También existe la posibilidad de que una instancia maliciosa acceda a los datos de otro usuario o los filtre en la memoria o en el disco mediante la explotación de ese defecto.

Por último, una carga de trabajo que no sea de confianza podría acceder a otros servicios de Google Cloud o metadatos del clúster.

Cómo GKE Sandbox mitiga estas amenazas

gVisor es una reimplementación de espacio de usuario de la API del kernel de Linux que no necesita privilegios elevados. En conjunto con un entorno de ejecución de contenedor como containerd, el kernel del espacio de usuario vuelve a implementar la mayoría de las llamadas al sistema y las entrega en nombre del kernel del host. El acceso directo al kernel del host es limitado. Consulta la guía de arquitectura de gVisor para obtener información detallada sobre cómo funciona. Desde el punto de vista del contenedor, gVisor es casi transparente y no requiere ningún cambio en la aplicación en contenedores.

Cuando solicitas GKE Sandbox en un pod de clústeres de Autopilot, GKE ejecuta ese pod en una zona de pruebas. En GKE Standard, si habilitas GKE Sandbox en los nodos, todos los pods que se ejecutan en esos nodos se ejecutan en zonas de pruebas.

Cada zona de pruebas usa su propio kernel de espacio de usuario. Con esto en mente, puedes tomar decisiones sobre cómo agrupar tus contenedores en pods, según el nivel de aislamiento que necesites y las características de tus aplicaciones.

GKE Sandbox es adecuado especialmente para los siguientes tipos de aplicaciones. Consulta Limitaciones para obtener más información que te ayude a decidir qué aplicaciones poner en zona de pruebas.

  • Aplicaciones no confiables o de terceros que usen entornos de ejecución, como Rust, Java, Python, PHP, Node.js o Golang
  • Cachés, proxies o frontends de servidores web
  • Aplicaciones que procesan medios o datos externos mediante CPU
  • Cargas de trabajo de aprendizaje automático con CPU
  • Aplicaciones que consumen mucha memoria o CPU
  • Cargas de trabajo con uso intensivo de GPU

Recomendaciones de seguridad adicionales

Cuando uses GKE Sandbox, te sugerimos que también sigas estas recomendaciones:

  • Especifica límites de recursos en todos los contenedores que se ejecutan en una zona de pruebas. Esto protege contra el riesgo de que una aplicación defectuosa o maliciosa prive al nodo de recursos y tenga un impacto negativo en otras aplicaciones o procesos del sistema que se ejecutan en el nodo.

  • Si usas la federación de identidades para cargas de trabajo para GKE, bloquea el acceso a los metadatos del clúster a través de la política de red para bloquear el acceso a 169.254.169.254. Esto protege contra el riesgo de que una aplicación maliciosa acceda a la información de datos potencialmente privados, como el ID del proyecto, el nombre del nodo y la zona. La federación de identidades para cargas de trabajo para GKE siempre está habilitada en los clústeres de Autopilot de GKE.

Limitaciones

GKE Sandbox funciona bien con muchas aplicaciones, pero no con todas. En esta sección, se proporciona más información sobre las limitaciones actuales de GKE Sandbox.

GPU en GKE Sandbox

En la versión 1.29.2-gke.1108000 y posteriores de GKE, GKE Sandbox admite el uso de GPU de NVIDIA.

GKE Sandbox no mitiga todas las vulnerabilidades del controlador de NVIDIA, pero mantiene la protección contra las vulnerabilidades del kernel de Linux. Para obtener detalles sobre cómo el proyecto gVisor protege las cargas de trabajo de GPU, consulta la Guía de asistencia de GPU.

Las siguientes limitaciones se aplican a las cargas de trabajo de GPU dentro de GKE Sandbox:

  • Solo se admite la versión del controlador NVIDIA latest en una versión de GKE determinada. Los clústeres de Autopilot instalan automáticamente las versiones del controlador NVIDIA que admiten GKE Sandbox.
  • Solo se admiten cargas de trabajo CUDA.
  • Los siguientes modelos de GPU son compatibles: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4 y nvidia-h100-80gb.

Puedes usar GKE Sandbox con cargas de trabajo de GPU sin costo adicional.

Configuración de grupos de nodos

Se aplica a los clústeres de Standard

  • No puedes usar GKE Sandbox en grupos de nodos de Windows Server.
  • No puedes habilitar GKE Sandbox en el grupo de nodos predeterminado para separar los servicios del sistema que se ejecutan en este grupo de las cargas de trabajo no confiables mediante GKE Sandbox.
  • Cuando usas GKE Sandbox, tu clúster debe tener al menos dos grupos de nodos. Siempre debes tener al menos un grupo de nodos en el que GKE Sandbox esté inhabilitado. Este grupo de nodos debe contener al menos un nodo, incluso si todas tus cargas de trabajo están en la zona de pruebas.
  • Las versiones de GKE anteriores a 1.24.2-gke.300 no son compatibles con los tipos de máquinas e2-micro, e2-small y e2-medium. Versión de GKE 1.24.2-gke.300 y las versiones posteriores admiten estos tipos de máquinas.
  • Los nodos deben usar la imagen de nodo Container-Optimized OS con containerd (cos_containerd).

Acceso a metadatos de clúster

Se aplica a los clústeres de Autopilot y Standard

  • Los nodos que ejecutan pods de zona de pruebas no pueden acceder a los metadatos del clúster a nivel del sistema operativo del nodo.
  • En GKE Standard, puedes ejecutar pods regulares en un nodo con GKE Sandbox habilitado. Sin embargo, de forma predeterminada, esos pods regulares no pueden acceder a los servicios de Google Cloud ni a los metadatos del clúster.
  • Usa la federación de identidades para cargas de trabajo para GKE para otorgar a los Pods acceso a los servicios de Google Cloud.

Es posible que los SMT estén inhabilitados

Se aplica a los clústeres de Autopilot y Standard

La configuración del multiprocesamiento simultáneo (SMT) se usa para mitigar las vulnerabilidades de los canales secundarios que aprovechan los subprocesos que comparten el estado principal, como las vulnerabilidades de muestreo de datos de microarquitectura (MDS).

En las versiones de GKE 1.25.5-gke.2500 o posteriores y 1.26.0-gke.2500 o posteriores, gVisor está configurado para usar la Linux Core Scheduling a fin de mitigar los ataques de canal lateral. La configuración de SMT no se modifica de forma predeterminada. Core Scheduling solo se usa para cargas de trabajo que se ejecutan con gVisor.

A partir de la versión de GKE 1.24.2-gke.300, el SMT se configura por tipo de máquina en función de qué tan vulnerable sea la máquina al MDS, de la siguiente manera:

  • Pods de Autopilot que se ejecutan en la clase de procesamiento Scale-Out: SMT inhabilitado.

  • Tipos de máquina con procesadores Intel: SMT inhabilitado de forma predeterminada.

  • Tipos de máquinas sin procesadores Intel: SMT habilitado de forma predeterminada.

  • Tipos de máquina con un solo subproceso por núcleo: sin compatibilidad con SMT. Todas las CPU virtuales solicitadas son visibles.

En las versiones anteriores a la 1.24.2-gke.300, SMT estaba inhabilitado en todos los tipos de máquinas.

Habilita SMT

Se aplica a los clústeres de Standard

En los clústeres de GKE Standard, puedes habilitar SMT si está inhabilitado en el tipo de máquina seleccionado. Se te cobrará por cada CPU virtual, sin importar si activas o no el SMT. Para obtener información sobre los precios, consulta los precios de Compute Engine.

Versión de GKE 1.24.2-gke.300 y versiones posteriores

Establece la marca --threads-per-core cuando crees un grupo de nodos de GKE Sandbox:

gcloud container node-pools create smt-enabled \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --threads-per-core=2 \
  --sandbox type=gvisor
  • CLUSTER_NAME: es el nombre del clúster existente.
  • MACHINE_TYPE: Es el tipo de máquina.

Para obtener más información sobre --threads-per-core, consulta Establece la cantidad de subprocesos por núcleo.

Versiones de GKE anteriores a 1.24.2-gke.300

  1. Crea un nuevo grupo de nodos en tu clúster con la etiqueta de nodo cloud.google.com/gke-smt-disabled=false:

    gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

  2. Implementa DaemonSet en el grupo de nodos. DaemonSet solo se ejecutará en nodos con la etiqueta cloud.google.com/gke-smt-disabled=false.

    kubectl create -f \
    https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml

  3. Asegúrate de que los pods del DaemonSet estén en estado de ejecución.

    kubectl get pods --selector=name=enable-smt -n kube-system

    El resultado es similar a este:

    NAME               READY     STATUS    RESTARTS   AGE
enable-smt-2xnnc   1/1       Running   0          6m

  4. Verifica que SMT has been enabled aparezca en los registros de los pods.

    kubectl logs enable-smt-2xnnc enable-smt -n kube-system

Funciones

Se aplica a los clústeres de Standard

De forma predeterminada, el contenedor no puede abrir sockets sin procesar para reducir la posibilidad de ataques maliciosos. Algunas herramientas relacionadas con la red, como ping y tcpdump, crean sockets sin procesar como parte de su funcionalidad principal. Para habilitar los sockets sin procesar, debes agregar de forma explícita la capacidad NET_RAW al contexto de seguridad del contenedor:

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

Si usas GKE Autopilot, Google Cloud te impide agregar el permiso NET_RAW a los contenedores debido a las implicaciones de seguridad de esta capacidad.

Dependencias externas

Se aplica a los clústeres de Autopilot y Standard

Es posible permitir que el código no confiable que se ejecuta dentro de la zona de pruebas llegue a servicios externos como servidores de bases de datos, API, otros contenedores y controladores de CSI. Estos servicios se ejecutan fuera de los límites de la zona de pruebas y deben protegerse de forma individual. Un atacante puede intentar aprovecharse de las vulnerabilidades en estos servicios para salir de la zona de pruebas. Debes tener en cuenta el riesgo y el impacto de que el código que se ejecuta dentro de la zona de pruebas pueda acceder a estos servicios y aplicar las medidas necesarias para protegerlos.

Esto incluye implementaciones de sistemas de archivos de volúmenes de contenedores como ext4 y controladores de CSI. Los controladores de CSI se ejecutan fuera del aislamiento de la zona de pruebas y pueden tener acceso con privilegios al host y a los servicios. Un ataque a estos controladores puede afectar el kernel del host y comprometer todo el nodo. Te recomendamos que ejecutes el controlador de CSI dentro de un contenedor con la menor cantidad de permisos necesarios a fin de reducir la exposición en caso de un ataque. GKE Sandbox es compatible con el uso del controlador CSI de Persistent Disk de Compute Engine.

Funciones incompatibles

No puedes usar GKE Sandbox con las siguientes características de Kubernetes:

Características de la carga de trabajo

Se aplica a los clústeres de Autopilot y Standard

La imposición de una capa adicional de indirección para acceder al kernel del nodo tiene compensaciones de rendimiento. GKE Sandbox proporciona el beneficio más tangible en grandes clústeres de múltiples instancias en los que el aislamiento es importante. Ten en cuenta los siguientes lineamientos cuando pruebes tus cargas de trabajo con GKE Sandbox.

Llamadas al sistema

Se aplica a los clústeres de Autopilot y Standard

Las cargas de trabajo que generan un gran volumen de llamadas al sistema de baja sobrecarga, como una gran cantidad de pequeñas operaciones de E/S, pueden requerir más recursos del sistema cuando se ejecutan en una zona de pruebas, por lo que es posible que necesites usar nodos más potentes o agregar nodos adicionales a tu clúster.

Acceso directo a hardware o virtualización

Se aplica a los clústeres de Autopilot y Standard

Si tu carga de trabajo necesita algunos de los siguientes elementos, es posible que GKE Sandbox no sea una buena opción porque impide el acceso directo al kernel del host en el nodo:

  • Acceso directo al hardware del nodo
  • Funciones de virtualización a nivel del kernel
  • Contenedores privilegiados

¿Qué sigue?