En esta página se describe cómo protege GKE Sandbox el kernel del host en tus nodos cuando los contenedores del pod ejecutan código desconocido o no fiable. Por ejemplo, los clústeres multiinquilino, como los proveedores de software como servicio (SaaS), suelen ejecutar código desconocido enviado por sus usuarios. GKE Sandbox también es una medida de defensa en profundidad útil para ejecutar contenedores de alto valor.
Esta página está dirigida a especialistas en seguridad que quieran conocer las ventajas de GKE Sandbox. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Antes de leer esta página, asegúrate de que conoces la documentación oficial de gVisor, el proyecto de código abierto que usa GKE Sandbox.
Para obtener instrucciones sobre cómo habilitar y usar GKE Sandbox, consulta Configurar GKE Sandbox.
Información general
GKE Sandbox proporciona una capa de seguridad adicional para evitar que el código no fiable afecte al kernel del host en los nodos de tu clúster. Antes de hablar sobre cómo funciona GKE Sandbox, es útil entender la naturaleza de los posibles riesgos que ayuda a mitigar.
Un tiempo 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 tiempo de ejecución del contenedor suele ejecutarse como un usuario con privilegios en el nodo y tiene acceso a la mayoría de las llamadas al sistema en el kernel del host.
Posibles amenazas
Los clústeres de multitenancy y los clústeres cuyos contenedores ejecutan cargas de trabajo no fiables están más expuestos a vulnerabilidades de seguridad que otros clústeres. Por ejemplo, proveedores de SaaS, proveedores de alojamiento web u otras organizaciones que permitan a sus usuarios subir y ejecutar código. Un fallo en el tiempo de ejecución del contenedor o en el kernel del host podría permitir que un proceso que se ejecuta en un contenedor "escape" del contenedor y afecte al kernel del nodo, lo que podría provocar que el nodo deje de funcionar.
También existe la posibilidad de que un inquilino malintencionado acceda a los datos de otro inquilino y los extraiga de la memoria o del disco aprovechando un defecto de este tipo.
Por último, una carga de trabajo no fiable podría acceder a otros servicios o metadatos de clúster. Google Cloud
Cómo mitiga GKE Sandbox las posibles amenazas
gVisor es una reimplementación en el espacio de usuario de la API del kernel de Linux que no necesita privilegios elevados. Junto con un tiempo 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 atiende en nombre del kernel del host. El acceso directo al kernel del host
está 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 un sandbox. En GKE Standard, si habilitas GKE Sandbox en los nodos, todos los pods que se ejecuten en esos nodos lo harán en entornos aislados.
Cada sandbox usa su propio kernel de espacio de usuario. Teniendo esto en cuenta, puedes tomar decisiones sobre cómo agrupar tus contenedores en pods, en función del nivel de aislamiento que necesites y de las características de tus aplicaciones.
GKE Sandbox es especialmente adecuado para los siguientes tipos de aplicaciones. Consulta Limitaciones para obtener más información que te ayude a decidir qué aplicaciones incluir en el entorno aislado.
- Aplicaciones de terceros o no fiables que usan entornos de ejecución como Rust, Java, Python, PHP, Node.js o Golang
- Front-ends, cachés o proxies de servidores web
- Aplicaciones que procesan contenido multimedia o datos externos mediante CPUs
- Cargas de trabajo de aprendizaje automático que usan CPUs
- Aplicaciones que requieren un uso intensivo de la CPU o de la memoria
Las cargas de trabajo o los servicios de IA o aprendizaje automático suelen requerir una implementación más rápida en producción. gVisor se ha diseñado para protegerse frente a clases enteras de vulnerabilidades comunes de Linux. Con GKE Sandbox, puedes mejorar tu postura de seguridad en cargas de trabajo intensivas de GPU y TPU sin hacer cambios importantes en tu código. Los principales casos prácticos en los que GKE Sandbox encaja bien son habituales en las cargas de trabajo de IA y aprendizaje automático:
- Cargas de trabajo que consumen muchos recursos de GPU y TPU.
- Servicios que aceptan y ejecutan código de usuario no fiable.
- Servicios que procesan entradas de usuario arbitrarias.
- Cargas de trabajo que procesan conjuntos de datos y modelos de terceros de gran tamaño.
- Aplicaciones que usan bibliotecas de terceros.
Para obtener más información sobre el diseño y la seguridad del acceso a los aceleradores, consulta las guías de GPU y TPU de gVisor.
Recomendaciones de seguridad adicionales
Cuando uses GKE Sandbox, te recomendamos que sigas estas recomendaciones:
Especifica límites de recursos en todos los contenedores que se ejecuten en un espacio aislado. De esta forma, se evita el riesgo de que una aplicación defectuosa o maliciosa prive al nodo de recursos y afecte negativamente a otras aplicaciones o procesos del sistema que se ejecuten en el nodo.
Si usas Workload Identity Federation for GKE, bloquea el acceso a los metadatos del clúster mediante Network Policy para bloquear el acceso a
169.254.169.254. De esta forma, se protege frente al riesgo de que una aplicación maliciosa acceda a información potencialmente privada, como el ID del proyecto, el nombre del nodo y la zona. Workload Identity Federation para GKE siempre está habilitado 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 ofrece más información sobre las limitaciones actuales de GKE Sandbox.
GPUs en GKE Sandbox
En la versión 1.29.2-gke.1108000 de GKE y posteriores, GKE Sandbox admite el uso de GPUs NVIDIA.
GKE Sandbox no mitiga todas las vulnerabilidades de los controladores de NVIDIA, pero mantiene la protección frente a las vulnerabilidades del kernel de Linux. Para obtener información sobre cómo protege el proyecto gVisor las cargas de trabajo de GPU, consulta la guía de compatibilidad con GPU.
Las siguientes limitaciones se aplican a las cargas de trabajo de GPU en GKE Sandbox:
- Solo se admiten cargas de trabajo de CUDA.
- GKE Sandbox admite un subconjunto de las GPUs compatibles con GKE. Para obtener más información, consulta la tabla de compatibilidad.
- gVisor solo admite determinadas versiones de controladores de NVIDIA. GKE Sandbox se asegura de que tanto el controlador
latestcomo eldefaultde cada GPU compatible con cada versión de GKE sean compatibles. No se garantiza que otros controladores funcionen. - No todas las funciones de la GPU funcionarán de forma nativa (por ejemplo, RDMA o IMEX). Las funciones de GPU se admitirán caso por caso en función de las necesidades de los clientes. Envía un caso de asistencia o registra un error en GitHub Issues de gVisor.
Puedes usar GKE Sandbox con cargas de trabajo de GPU sin coste adicional.
Compatibilidad con modelos de GPU de GKE Sandbox
En la siguiente tabla se describe la compatibilidad con diferentes modelos de GPU en GKE Sandbox:
| Modelo | Vista previa | Asistencia de GA | Notas |
|---|---|---|---|
|
|
- |
|
Compatible desde el lanzamiento inicial. |
|
|
|
- | - |
|
|
|
- | - |
|
|
|
- | - |
|
|
- | - | disponible próximamente |
|
|
no admitida | no admitida | Los modelos V100 y P100 usan controladores propietarios y no serán compatibles. |
|
|
- | - | {gke_sandbox} no admite los tipos de nodo de Windows ni de Ubuntu, que son necesarios para los nodos de estación de trabajo virtual. |
TPUs en GKE Sandbox
En GKE 1.31.3-gke.1111001 y versiones posteriores, GKE Sandbox admite el uso de TPUs.
GKE Sandbox no mitiga todas las vulnerabilidades de los controladores de TPU, pero mantiene la protección frente a las vulnerabilidades del kernel de Linux. Para obtener información detallada sobre cómo protege el proyecto gVisor las cargas de trabajo de las TPU, consulta la guía de asistencia de las TPU.
Se admiten las siguientes versiones de hardware de TPU: V4pod, V4lite, V5litepod, V5pod y V6e.
Puedes usar GKE Sandbox con cargas de trabajo de TPU sin coste adicional.
Configuración del grupo de nodos
Se aplica a clústeres estándar
- No puedes usar el entorno aislado de GKE 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 el grupo de nodos predeterminado de las cargas de trabajo que no son de confianza mediante GKE Sandbox.
- Cuando usas GKE Sandbox, tu clúster debe tener al menos dos grupos de nodos. Siempre debe tener al menos un grupo de nodos en el que GKE Sandbox esté inhabilitado. Este grupo de nodos debe contener al menos un nodo, aunque todas tus cargas de trabajo estén en un espacio aislado.
- Las versiones de GKE anteriores a la 1.24.2-gke.300 no admiten los tipos de máquina e2-micro, e2-small y e2-medium. La versión 1.24.2-gke.300 de GKE y las posteriores admiten estos tipos de máquina.
- Los nodos deben usar la imagen de nodo Container-Optimized OS con containerd (
cos_containerd).
Acceso a los metadatos del clúster
Se aplica a los clústeres de Autopilot y Standard
- Los nodos que ejecutan pods en un espacio aislado no pueden acceder a los metadatos del clúster a nivel del sistema operativo del nodo.
- En GKE Standard, puedes ejecutar pods normales en un nodo con GKE Sandbox habilitado. Sin embargo, de forma predeterminada, esos pods normales no pueden acceder a los servicios ni a los metadatos del clúster. Google Cloud
- Usa Workload Identity Federation for GKE para conceder acceso a los pods a los servicios de Google Cloud .
Es posible que SMT esté inhabilitado
Se aplica a los clústeres de Autopilot y Standard
Los ajustes de multihilo simultáneo (SMT) se usan para mitigar las vulnerabilidades de canal lateral que aprovechan los hilos que comparten el estado del núcleo, como las vulnerabilidades de muestreo de datos de microarquitectura (MDS).
En las versiones 1.25.5-gke.2500 y posteriores, y 1.26.0-gke.2500 y posteriores de GKE, gVisor está configurado para usar Linux Core Scheduling para mitigar los ataques de canal lateral. Los ajustes de SMT no han cambiado respecto a los predeterminados. La programación Core se usa únicamente en cargas de trabajo que se ejecutan con gVisor.
A partir de la versión 1.24.2-gke.300 de GKE, la SMT se configura por tipo de máquina en función de la vulnerabilidad de la máquina a MDS, de la siguiente manera:
Pods de Autopilot que se ejecutan en la clase de computación
Scale-Out: SMT inhabilitado.Tipos de máquinas con procesadores Intel: SMT inhabilitado de forma predeterminada.
Tipos de máquinas sin procesadores Intel: SMT habilitado de forma predeterminada.
Tipos de máquinas con un solo hilo por núcleo: no se admite SMT. Todas las vCPUs solicitadas están visibles.
Antes de la versión 1.24.2-gke.300, SMT está inhabilitado en todos los tipos de máquinas.
Habilitar SMT
Se aplica a clústeres estándar
En los clústeres estándar de GKE, puedes habilitar SMT si está inhabilitado en el tipo de máquina seleccionado. Se te cobra por cada vCPU, independientemente de si activas o desactivas SMT. Para obtener información sobre los precios, consulta la página Precios de Compute Engine.
GKE 1.24.2-gke.300 y versiones posteriores
Define la marca --threads-per-core al crear un grupo de nodos de GKE Sandbox:
gcloud container node-pools create smt-enabled \
--cluster=CLUSTER_NAME \
--location=LOCATION \
--machine-type=MACHINE_TYPE \
--threads-per-core=2 \
--sandbox type=gvisor
CLUSTER_NAME: el nombre de un clúster en el que quieras crear el nuevo grupo de nodos.LOCATION: la región o la zona de Compute Engine del clúster.MACHINE_TYPE: el tipo de máquina.
Para obtener más información sobre --threads-per-core, consulta Definir el número de subprocesos por núcleo.
Versiones de GKE anteriores a la 1.24.2-gke.300
Crea un 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 \ --location=LOCATION \ --machine-type=MACHINE_TYPE \ --node-labels=cloud.google.com/gke-smt-disabled=false \ --image-type=cos_containerd \ --sandbox type=gvisorHaz los cambios siguientes:
CLUSTER_NAME: el nombre de un clúster en el que quieras crear el nuevo grupo de nodos.LOCATION: la región o la zona de Compute Engine del clúster.MACHINE_TYPE: el tipo de máquina.
Despliega el DaemonSet en el grupo de nodos. El DaemonSet solo se ejecutará en los 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.yamlAsegúrate de que los pods de DaemonSet estén en estado de ejecución.
kubectl get pods --selector=name=enable-smt -n kube-systemEl resultado debería ser similar al siguiente:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mComprueba que
SMT has been enabledaparece en los registros de los pods.kubectl logs enable-smt-2xnnc enable-smt -n kube-system
Funciones
Se aplica a clústeres estándar
De forma predeterminada, el contenedor no puede abrir sockets sin procesar para reducir el riesgo de ataques maliciosos. Algunas herramientas relacionadas con la red, como ping
y tcpdump, crean sockets sin formato como parte de su funcionamiento principal. Para habilitar los sockets sin formato, debes añadir explícitamente la función NET_RAW al contexto de seguridad del contenedor:
spec:
containers:
- name: my-container
securityContext:
capabilities:
add: ["NET_RAW"]
Si usas Autopilot de GKE, Google Cloud no puedes
añadir el permiso NET_RAW a los contenedores debido a las implicaciones de seguridad de esta función.
Dependencias externas
Se aplica a los clústeres de Autopilot y Standard
Es posible que se permita que el código no fiable que se ejecuta en el espacio aislado acceda a servicios externos, como servidores de bases de datos, APIs, otros contenedores y controladores CSI. Estos servicios se ejecutan fuera del límite del entorno aislado y deben protegerse individualmente. Un atacante puede intentar aprovechar las vulnerabilidades de estos servicios para salir del entorno aislado. Debes tener en cuenta el riesgo y el impacto de que el código que se ejecuta en el entorno aislado pueda acceder a estos servicios y aplicar las medidas necesarias para protegerlos.
Esto incluye implementaciones del sistema de archivos para volúmenes de contenedores, como ext4 y controladores CSI. Los controladores CSI se ejecutan fuera del aislamiento del entorno aislado y pueden tener acceso privilegiado al host y a los servicios. Una vulnerabilidad en estos controladores puede afectar al kernel del host y poner en peligro todo el nodo. Te recomendamos que ejecutes el controlador CSI en un contenedor con la menor cantidad de permisos necesarios para reducir la exposición en caso de que se produzca una vulnerabilidad. GKE Sandbox admite el uso del controlador de CSI para Persistent Disk en Compute Engine.
Funciones incompatibles
No puedes usar el entorno aislado de GKE con las siguientes funciones de Kubernetes:
- Métricas de uso de memoria a nivel de contenedor. Sin embargo, se admite el uso de memoria de los pods.
- Almacenamiento de rutas de host
- Los límites de CPU y memoria solo se aplican a los pods garantizados y a los pods con ráfagas, y solo cuando se especifican límites de CPU y memoria para todos los contenedores que se ejecutan en el pod.
- Contenedores que se ejecutan en modo con privilegios
- VolumeDevices
- Portforward
- Módulos de seguridad del kernel de Linux, como Seccomp, Apparmor o Selinux,
Sysctl,
NoNewPrivileges, MountPropagation bidireccional, o ProcMount. FSGroup se admite en GKE 1.22 y versiones posteriores.
Cloud Service Mesh no es compatible con los pods de GKE Sandbox en clústeres de Autopilot.
Características de la carga de trabajo
Se aplica a los clústeres de Autopilot y Standard
Imponer una capa adicional de indirección para acceder al kernel del nodo conlleva ciertas consecuencias en el rendimiento. GKE Sandbox ofrece las ventajas más tangibles en clústeres grandes multicliente en los que el aislamiento es importante. Ten en cuenta las siguientes directrices al probar tus cargas de trabajo con GKE Sandbox.
Llamadas del sistema
Se aplica a los clústeres de Autopilot y Standard
Las cargas de trabajo que generan un gran volumen de llamadas al sistema con poca sobrecarga, como un gran número de operaciones de E/S pequeñas, pueden requerir más recursos del sistema cuando se ejecutan en un sandbox, por lo que es posible que tengas que usar nodos más potentes o añadir nodos adicionales a tu clúster.
Acceso directo al hardware o a la virtualización
Se aplica a los clústeres de Autopilot y Standard
Si tu carga de trabajo necesita alguno de los siguientes elementos, es posible que GKE Sandbox no sea la opción más adecuada, ya que impide el acceso directo al kernel del host en el nodo:
- Acceso directo al hardware del nodo
- Funciones de virtualización a nivel de kernel
- Contenedores con privilegios
Siguientes pasos
- Configura GKE Sandbox.
- Consulta la descripción general de la seguridad.
- Consulta información sobre el ciclo de vida de los pods.