GKE Sandbox

Estándar

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 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 información detallada sobre cómo habilitar 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 habilitas GKE Sandbox en un grupo de nodos, se crea una zona de pruebas para cada pod que se ejecuta en un nodo en ese grupo de nodos. Además, los nodos que ejecutan pods con zona de pruebas no pueden acceder a otros servicios de Google Cloud ni a los metadatos del clúster.

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

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 Workload Identity, bloquea el acceso a los metadatos del clúster mediante 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, etcétera.

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.

Configuración de grupos de nodos

No puedes usar GKE Sandbox en grupos de nodos de Windows Server.
No puedes habilitar GKE Sandbox en el grupo de nodos predeterminado.
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. La 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

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.
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 Workload Identity para otorgar a los pods acceso a los servicios de Google Cloud.

Es posible que SMT esté inhabilitado.

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:

Tipos de máquina con procesadores Intel: SMT inhabilitado de forma predeterminada.
Tipos de máquina sin procesadores Intel: SMT habilitado de forma predeterminada.
Tipos de máquina con un solo subproceso por núcleo: no admite SMT. Todas las CPU virtuales solicitadas son visibles.

Antes de la versión 1.24.2-gke.300, SMT está inhabilitado en todos los tipos de máquina.

Habilita SMT

Puedes habilitar SMT si está inhabilitado en el tipo de máquina seleccionado. Se te cobra por cada CPU virtual, sin importar si activas SMT o lo mantienes desactivado. 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

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

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

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

Verifica que SMT has been enabled aparezca en los registros de los pods.
```
kubectl logs enable-smt-2xnnc enable-smt -n kube-system
```

Capacidades

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

Dependencias externas

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:

Aceleradores como GPU o TPU
Supervisión de estadísticas a nivel del Pod o contenedor
Almacenamiento de ruta de host
Los límites de CPU y memoria solo se aplican en pods garantizados y pods de alto rendimiento y solo cuando se especifican límites de CPU y memoria para todos los contenedores que se ejecutan en el pod.
Pods que usan PodSecurityPolicies que especifican espacios de nombres de host, como hostNetwork, hostPID o hostIPC

Advertencia: Kubernetes tiene oficialmentePodSecurityPolicy obsoleto en la versión 1.21. PodSecurityPolicy se cerrará en la versión 1.25. Para obtener información sobre las alternativas, consulta Baja de PodSecurityPolicy.
Pods que usan parámetros de configuración de PodSecurityPolicy como el modo privilegiado
VolumeDevices
Portforward
Módulos de seguridad del kernel de Linux, como Seccomp, Apparmor o Selinux, Sysctl, NoNewPrivileges, MountPropagation bidireccional, o ProcMount.
Traffic Director
ASM con CNI de Istio
FSGroup es compatible con la versión 1.22 de GKE y versiones posteriores.

Características de la carga de trabajo

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

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

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