Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Aísla cargas de trabajo con GKE Sandbox

Autopilot Standard

Puedes proteger el kernel del host de tus nodos de Google Kubernetes Engine (GKE) de los contenedores que ejecutan código desconocido o que no es de confianza con GKE Sandbox. En este documento, se muestra a los especialistas en seguridad cómo habilitar GKE Sandbox, ejecutar Pods en zonas de pruebas y verificar el aislamiento.

Ya debes conocer GKE Sandbox.

Tipos de zonas de pruebas disponibles

GKE Sandbox admite los siguientes tipos de sandbox, cada uno de los cuales usa una tecnología específica para separar el código de la aplicación del kernel del host:

gvisor: Es una reimplementación de espacio de usuario de la API del kernel de Linux que no necesita privilegios elevados. El kernel del espacio de usuario intercepta y entrega la mayoría de las llamadas al sistema en nombre del kernel del host, lo que limita el acceso directo al kernel del host.
microvm: VMs ligeras anidadas en la VM host con virtualización anidada. Cada Pod del nodo se ejecuta en su propia VM anidada con su propio kernel invitado. Debido a que el código se ejecuta en una VM dedicada, este tipo de zona de pruebas proporciona un aislamiento más sólido que las zonas de pruebas de gVisor.

Para obtener más información sobre cómo funciona cada tipo de zona de pruebas y cuándo usar un tipo específico, consulta Acerca de GKE Sandbox.

Limitaciones

GKE Sandbox y las tecnologías de zona de pruebas específicas tienen varias limitaciones, como la compatibilidad con GPU y TPU, o la compatibilidad con funciones específicas de Linux y Kubernetes. Para obtener más información, consulta Limitaciones.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Para seguir los pasos de la sección Elige un tipo de zona de pruebas para los nodos creados automáticamente, usa un clúster existente de Autopilot o Standard. Para usar zonas de pruebas de microVM, tus nodos deben ejecutar la versión 1.37.0-gke.4713000 o posterior de GKE.

Elige un tipo de zona de pruebas para los nodos creados automáticamente

Puedes usar ComputeClasses con el modo Autopilot o la creación automática de grupos de nodos para habilitar GKE Sandbox en los nodos que crea GKE. En los clústeres de Autopilot, gVisor es compatible de forma predeterminada, por lo que puedes omitir de forma opcional la configuración de zona de pruebas de tu ComputeClass.

Para configurar GKE Sandbox para los nodos creados automáticamente, sigue estos pasos:

Conéctate a un clúster de Autopilot o Standard existente:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
Reemplaza lo siguiente:
- CLUSTER_NAME: El nombre de tu clúster.
- CONTROL_PLANE_LOCATION: Es la región o zona del plano de control de tu clúster.
Guarda uno de los siguientes manifiestos de ComputeClass, según la tecnología de zona de pruebas que desees:
- gVisor:
```
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: sandbox-gvisor-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  nodePoolConfig:
    sandbox:
      type: gvisor
  nodePoolAutoCreation:
    enabled: true
  whenUnsatisfiable: DoNotScaleUp
```
- microVM:
```
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: sandbox-microvm-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  nodePoolConfig:
    sandbox:
      type: microvm
  priorityDefaults:
    enableNestedVirtualization: true
  nodePoolAutoCreation:
    enabled: true
  whenUnsatisfiable: DoNotScaleUp
```
  La ComputeClass para las zonas de pruebas de microVMs habilita la virtualización anidada con el campo enableNestedVirtualization. Este campo es obligatorio para los entornos de pruebas de microVM. Para usar este campo, tu clúster debe ejecutar la versión 1.37.0-gke.4713000 o posterior.
En estos manifiestos de ejemplo, se usa el campo nodePoolAutoCreation para habilitar la creación automática de grupos de nodos. También puedes especificar la configuración de zona de pruebas en una ComputeClass que use el campo autopilot para ejecutar Pods en modo Autopilot. Si usas clústeres de Autopilot, GKE ignora los campos nodePoolAutoCreation y autopilot.
Crea el objeto ComputeClass:
```
kubectl apply -f PATH_TO_COMPUTE_CLASS_MANIFEST
```
Reemplaza PATH_TO_COMPUTE_CLASS_MANIFEST por la ruta de acceso al manifiesto de ComputeClass.

Para seleccionar esta ComputeClass y solicitar un entorno de zona de pruebas, consulta Solicita un entorno de zona de pruebas para un Pod.

Elige un tipo de zona de pruebas cuando crees grupos de nodos

Puedes habilitar GKE Sandbox de forma manual cuando creas un grupo de nodos nuevo en un clúster Standard. Las siguientes limitaciones se aplican cuando habilitas GKE Sandbox de forma manual:

Para habilitar GKE Sandbox durante la creación del clúster Standard, debes configurar al menos un grupo de nodos adicional. Se requiere el grupo de nodos adicional porque GKE necesita al menos un grupo de nodos en el clúster que no use GKE Sandbox para ejecutar cargas de trabajo del sistema administradas por GKE. Si usas gcloud CLI para crear tu clúster, primero debes crear el clúster y, luego, un grupo de nodos que use GKE Sandbox.
Para seleccionar el tipo de zona de pruebas de microVM, debes usar gcloud CLI o la API de GKE. La consola deGoogle Cloud no admite la selección del tipo de zona de pruebas de microVM.

Habilita el tipo de zona de pruebas de gVisor

Para habilitar de forma manual las zonas de pruebas de gVisor cuando creas un grupo de nodos nuevo, selecciona una de las siguientes opciones:

Console

En la consola de Google Cloud , accede a la página Clústeres de Kubernetes.

Ir a clústeres de Kubernetes
Haz clic en el nombre del clúster que deseas modificar. Se abrirá la página Detalles del clúster.
Haz clic en la pestaña Nodos.
En la sección Grupos de nodos, haz clic en Agregar grupo de nodos administrado por el usuario. Se abrirá la página Agregar un grupo de nodos.
En el menú de navegación, haz clic en Nodos y establece la siguiente configuración:
1. En la lista desplegable Tipo de imagen, selecciona Container-Optimized OS con Containerd (cos_containerd).
2. En la sección Configuración de la máquina, selecciona una serie de máquinas y un tipo de máquina para los nodos.
3. Opcional: Selecciona un tipo de GPU compatible o un tipo de TPU compatible.
En el menú de navegación, haz clic en Seguridad. Se abrirá la página Seguridad de nodos.
Selecciona la casilla de verificación Habilitar zona de pruebas con gVisor.
Para crear el grupo de nodos, haz clic en Crear.

gcloud

Para crear un grupo de nodos que use gVisor para zonas de pruebas, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --sandbox=type=gvisor

Reemplaza lo siguiente:

NODE_POOL_NAME: Es un nombre para el grupo de nodos.
CLUSTER_NAME: El nombre de tu clúster.
CONTROL_PLANE_LOCATION: Es la región o zona del plano de control de tu clúster.

También puedes habilitar zonas de pruebas de gVisor cuando creas grupos de nodos que usan un tipo de GPU compatible o un tipo de TPU compatible. Para obtener más información, consulta los siguientes documentos:

Habilita el tipo de zona de pruebas de microVM

Puedes habilitar el tipo de zona de pruebas de microVM cuando creas un grupo de nodos con la gcloud CLI o la API de GKE. La consola de Google Cloud no admite la habilitación del tipo de zona de pruebas de microVM. Para crear un grupo de nodos que use zonas de pruebas de microVM, ejecuta el siguiente comando:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --sandbox=type=microvm \
    --enable-nested-virtualization \
    --machine-type=MACHINE_TYPE

Reemplaza lo siguiente:

NODE_POOL_NAME: Es un nombre para el grupo de nodos.
CLUSTER_NAME: El nombre de tu clúster.
CONTROL_PLANE_LOCATION: Es la región o la zona del plano de control de tu clúster.
MACHINE_TYPE: Es el tipo de máquina para los nodos. Este valor debe ser un tipo de máquina que admita la virtualización anidada. Para obtener más información, consulta la fila Virtualización anidada en la tabla de comparación de series de máquinas.

Habilita la supervisión y el registro

Para recopilar y ver registros y métricas de tus entornos de pruebas, asegúrate de que tu clúster habilite los siguientes servicios de observabilidad:

Estos servicios están habilitados de forma predeterminada en todos los clústeres nuevos de GKE.

Solicita un entorno de zona de pruebas para un Pod

Para ejecutar un Pod específico en una zona de pruebas, puedes especificar la clase gvisor o microvm RuntimeClass en la especificación del Pod. GKE programa el Pod en nodos que usan el tipo de zona de pruebas especificado. Para seleccionar un tipo de zona de pruebas en una especificación de Pod, sigue estos pasos:

Guarda uno de los siguientes manifiestos de Deployment de ejemplo, según si habilitas GKE Sandbox con ComputeClasses o grupos de nodos creados manualmente:

ComputeClasses:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-pod
  labels:
    environment: sandbox
spec:
  replicas: 2
  selector:
    matchLabels:
      environment: sandbox
  template:
    metadata:
      labels:
        environment: sandbox
    spec:
      nodeSelector:
        cloud.google.com/compute-class: COMPUTECLASS_NAME
      runtimeClassName: SANDBOX_TYPE
      
      containers:
      - name: nginx
        image: nginx

Reemplaza lo siguiente:

COMPUTECLASS_NAME: Es el nombre de la ComputeClass que creaste, como se describe en Cómo elegir un tipo de zona de pruebas para los nodos creados automáticamente.
SANDBOX_TYPE: Es el tipo de zona de pruebas que se usará para los Pods. Se admiten los siguientes valores:
- gvisor
- microvm
El tipo de zona de pruebas que especifiques debe coincidir con el tipo de zona de pruebas que habilita la clase de procesamiento seleccionada.

Grupos de nodos creados de forma manual:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: SANDBOX_TYPE
      containers:
      - name: httpd
        image: httpd

Reemplaza SANDBOX_TYPE por el tipo de zona de pruebas. Se admiten los siguientes valores:

gvisor
microvm

El tipo de zona de pruebas que especifiques debe coincidir con el tipo de zona de pruebas de un grupo de nodos existente en el clúster.

Crea el Deployment:
```
kubectl apply -f PATH_TO_DEPLOYMENT_MANIFEST
```
Reemplaza PATH_TO_DEPLOYMENT_MANIFEST por la ruta de acceso al manifiesto de Deployment.

Verifica que se hayan creado los Pods:

kubectl get pods

El resultado es similar a lo siguiente:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

También puedes solicitar sandboxes cuando ejecutas Pods en un tipo de GPU compatible o un tipo de TPU compatible con el campo runtimeClassName. Para obtener más información, consulta los siguientes documentos:

Ejecuta un Pod común junto con Pods de zona de pruebas

Los pasos de esta sección se aplican a las cargas de trabajo en modo estándar. No es necesario ejecutar Pods regulares junto con los Pods de la zona de pruebas en el modo Autopilot, ya que el modelo de precios de Autopilot elimina la necesidad de optimizar de forma manual la cantidad de Pods programada en los nodos.

Después de habilitar GKE Sandbox en un grupo de nodos, puedes ejecutar aplicaciones confiables en esos nodos sin usar una zona de pruebas a través de tolerancias y taints de nodo. Estos pods se denominan “pods regulares” para distinguirlos de los pods de zona de pruebas.

Al igual que los Pods de zona de pruebas, los Pods normales no pueden acceder a otros servicios deGoogle Cloud ni a los metadatos del clúster. Esta prevención es parte de la configuración del nodo. Si tus Pods normales o Pods de zona de pruebas requieren acceso a los servicios deGoogle Cloud , usa la federación de identidades para cargas de trabajo para GKE.

GKE Sandbox agrega la siguiente etiqueta y taint a los nodos que pueden ejecutar pods de zona de pruebas:

Es la etiqueta del nodo sandbox.gke.io/runtime: SANDBOX_TYPE.
El taint de nodo sandbox.gke.io/runtime=SANDBOX_TYPE:NoSchedule. Solo se pueden programar en el nodo los Pods que tengan una tolerancia coincidente.

Si usas el campo RuntimeClass para ejecutar un Pod en una zona de pruebas, GKE aplica automáticamente una afinidad de nodo y una tolerancia al Pod. Para ejecutar un Pod normal en un nodo que usa GKE Sandbox, debes aplicar de forma manual los siguientes selectores a la especificación del Pod:

Para permitir que tu Pod se ejecute en nodos que usan GKE Sandbox cuando sea necesario, agrega solo la tolerancia para el taint del nodo.
Para ejecutar tu Pod solo en nodos que usan GKE Sandbox, agrega un selector de nodos y la tolerancia para el taint de nodo.

En los siguientes pasos, se muestra cómo ejecutar un Pod normal en un nodo que usa GKE Sandbox:

Guarda el siguiente manifiesto de Deployment como httpd-regular.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-regular
  labels:
    app: httpd-regular
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd-regular
  template:
    metadata:
      labels:
        app: httpd-regular
    spec:
      containers:
      - name: httpd-regular
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - SANDBOX_TYPE
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: SANDBOX_TYPE

Reemplaza SANDBOX_TYPE por el tipo de zona de pruebas, como gvisor o microvm.

Crea el Deployment:
```
kubectl apply -f httpd-regular.yaml
```
Si el Pod no es programable, verifica que la afinidad del nodo y la tolerancia estén configuradas correctamente en el manifiesto del Pod.
Verifica que el Pod no esté en una zona de pruebas:
```
kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'
```
El resultado es similar a lo siguiente:
```
httpd-db5899bc9-dk7lk: SANDBOX_TYPE
httpd-regular-5bf87996c6-cfmmd:
```
El Pod httpd-regular no tiene un valor de RuntimeClass, lo que significa que el Pod no está en una zona de pruebas.
Verifica que el Pod regular se ejecute en un nodo que use GKE Sandbox:
```
kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'
```
El resultado es similar a lo siguiente:
```
httpd-db5899bc9-dk7lk: gke-cluster-2-pool-1-75c8fc63-h373
httpd-regular-5bf87996c6-cfmmd: gke-cluster-2-pool-1-75c8fc63-h373
```
Tanto el Pod de zona de pruebas como el Pod normal están en el mismo nodo, lo que indica que el Pod normal se ejecuta en un nodo que usa GKE Sandbox.

Verifica la configuración del entorno de pruebas

En las siguientes secciones, se muestra cómo verificar que un Pod se ejecute en una zona de pruebas y que el Pod de zona de pruebas esté aislado del kernel del host. En estas secciones, se supone que creaste el Deployment de ejemplo en Solicita un entorno de zona de pruebas para un Pod.

Verifica que un Pod se esté ejecutando en un entorno de pruebas.

Para verificar si tus Pods usan un espacio aislado, obtén el RuntimeClass de los Pods. Este método es más confiable que ejecutar un comando dentro del Pod, ya que no verás datos desde el interior de la zona de pruebas. Todo lo que se informe desde la zona de pruebas no es confiable, ya que podría ser defectuoso o malicioso.

Obtén el objeto RuntimeClass de cada Pod en ejecución:
```
kubectl get pods -l=app=httpd -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'
```
El resultado es similar a lo siguiente:
```
httpd-db5899bc9-dk7lk: gvisor
httpd-db5899bc9-ab3cd: gvisor
```
Si el resultado muestra gvisor o microvm, el Pod se está ejecutando en un entorno de pruebas.

Verifica el aislamiento de los Pods en zona de pruebas del host

Puedes verificar si un Pod en zona de pruebas está aislado del nodo host. Para ello, comprueba los dispositivos virtuales disponibles y la versión del kernel a la que puede acceder el Pod.

En el caso de las zonas de pruebas de gVisor y microVM, verifica si la versión del kernel a la que puede acceder el Pod es diferente de la versión del kernel del nodo host:
1. Obtén la versión del kernel a la que puede acceder el Pod:
```
kubectl exec POD_NAME -- uname -r
```
  Reemplaza POD_NAME con el nombre del pod.
  
  El resultado es similar a lo siguiente:
```
4.19.0-gvisor
```
2. Obtén la versión del kernel en el nodo host:
```
kubectl get node NODE_NAME \
    -o jsonpath='{.status.nodeInfo.kernelVersion}'
```
  Reemplaza NODE_NAME por el nombre del nodo que ejecuta el Pod.
  
  El resultado es similar a lo siguiente:
```
6.12.94+
```
La versión del kernel del nodo host es diferente de la versión del kernel a la que puede acceder el Pod en zona de pruebas, ya que el Pod solo ve el kernel del espacio de usuario para gVisor o el kernel invitado para las microVM.
En el caso de los entornos de pruebas de microVM, también puedes verificar si Cloud Hypervisor virtualiza los dispositivos a los que puede acceder el Pod:
```
kubectl exec POD_NAME -- cat /sys/class/dmi/id/product_name
```
Si el resultado es cloud-hypervisor, el Pod se encuentra en una zona de pruebas de microVM.

Inhabilita GKE Sandbox

No puedes inhabilitar GKE Sandbox en clústeres de GKE Autopilot ni en grupos de nodos de GKE Standard. Si deseas dejar de usar GKE Sandbox, borra el grupo de nodos.

¿Qué sigue?

Obtén más información sobre cómo administrar grupos de nodos.
Lee la descripción general de seguridad.

Aísla cargas de trabajo con GKE Sandbox Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Tipos de zonas de pruebas disponibles

Limitaciones

Antes de comenzar

Elige un tipo de zona de pruebas para los nodos creados automáticamente

Elige un tipo de zona de pruebas cuando crees grupos de nodos

Habilita el tipo de zona de pruebas de gVisor

Console

gcloud

Habilita el tipo de zona de pruebas de microVM

Habilita la supervisión y el registro

Solicita un entorno de zona de pruebas para un Pod

Ejecuta un Pod común junto con Pods de zona de pruebas

Verifica la configuración del entorno de pruebas

Verifica que un Pod se esté ejecutando en un entorno de pruebas.

Verifica el aislamiento de los Pods en zona de pruebas del host

Inhabilita GKE Sandbox

¿Qué sigue?

Aísla cargas de trabajo con GKE Sandbox