GKE Sandbox


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 docker o 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:

  • Recomendamos que especifiques límites de recursos en todos los contenedores que se ejecutarán 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, recomendamos que bloquees el acceso a los metadatos del clúster con la política de red para bloquear el acceso a la IP 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.
  • Los grupos de nodos no pueden usar tipos de máquinas e2-micro, e2-small y e2-medium.

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.

El hipersubproceso está inhabilitado

Los nodos de gVisor tienen inhabilitado el hipersubproceso de forma predeterminada en todas las arquitecturas para mitigar las vulnerabilidades de los canales secundarios que aprovechan el estado principal que se comparte entre los hipersubprocesos. Por ejemplo, la vulnerabilidad del Muestreo de datos de microarquitectura (MDS). A fin de habilitar el hipersubproceso para un grupo de nodos, sigue estos pasos:

  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. Habilitará el hipersubproceso y, luego, reiniciará el nodo.

    kubectl create -f \
        https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
    
  3. Después de que el nodo se reinicie, asegúrate de que los pods de DaemonSet estén en estado de ejecución.

    kubectl get pods --selector=name=enable-smt -n kube-system
    
  4. Deberías obtener una respuesta similar a la siguiente:

    NAME               READY     STATUS    RESTARTS   AGE
    enable-smt-2xnnc   1/1       Running   0          6m
    
  5. 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. El controlador de CSI de Persistent Disk de Compute Engine es compatible con GKE Sandbox.

Características incompatibles

En la actualidad, no es posible usar GKE Sandbox junto 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
  • Pods que usan 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, FSGroup o ProcMount.
  • Traffic Director
  • Istio no es compatible con las versiones de clúster anteriores a la 1.18.6-gke.4801. Istio es compatible con las versiones 1.18.6-gke.4801 y 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

¿Qué sigue?