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 de múltiples instancias, como los proveedores de software como servicio (SaaS), suelen ejecutar código desconocido enviado por sus 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.

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:

  • Se recomienda que especifiques 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.

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

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 el hipersubproceso inhabilitado de forma predeterminada para mitigar las vulnerabilidades de muestreo de datos microarquitectónicas (MDS) anunciadas por Intel. 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] \
      --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"]

Características incompatibles

En la actualidad, no es posible usar GKE Sandbox junto con las siguientes funciones de Kubernetes:

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

Próximos pasos