Aísla las cargas de trabajo en grupos de nodos dedicados

En esta página se muestra cómo reducir el riesgo de ataques de escalada de privilegios en tu clúster configurando GKE en Azure para programar tus cargas de trabajo en un grupo de nodos independiente y dedicado, lejos de las cargas de trabajo gestionadas con privilegios.

Información general

Los clústeres de GKE en Azure usan cargas de trabajo con privilegios que gestionamos para habilitar funciones y características específicas del clúster, como la recogida de métricas. Estas cargas de trabajo reciben permisos especiales para ejecutarse correctamente en el clúster.

Las cargas de trabajo que despliegues en tus nodos pueden verse comprometidas por una entidad maliciosa. Si ejecutas estas cargas de trabajo junto con cargas de trabajo del sistema privilegiadas, un atacante que salga de un contenedor vulnerado podrá usar las credenciales de la carga de trabajo privilegiada del nodo para aumentar los privilegios en tu clúster.

Evitar fugas de contenedores

Tu defensa principal deben ser tus aplicaciones. GKE en Azure tiene varias funciones que puedes usar para reforzar la seguridad de tus clústeres y pods. En la mayoría de los casos, recomendamos encarecidamente usar Policy Controller y funciones de seguridad del kernel para reforzar tus cargas de trabajo. Para obtener más recomendaciones de seguridad, consulta el artículo Información general sobre la seguridad.

Evitar ataques de apropiación de privilegios

Si quieres añadir una capa de aislamiento adicional a otras medidas de refuerzo, puedes usar taints de nodos y afinidades de nodos para programar tus cargas de trabajo en un grupo de nodos dedicado.

Un taint de nodo indica a GKE en Azure que evite programar cargas de trabajo sin una tolerancia correspondiente (como las cargas de trabajo gestionadas por GKE en Azure) en esos nodos. La afinidad de nodo de tus cargas de trabajo indica a GKE en Azure que programe tus pods en los nodos dedicados.

Limitaciones del aislamiento de nodos

  • Los atacantes pueden seguir iniciando ataques de denegación de servicio (DoS) desde el nodo vulnerado.
  • Los nodos vulnerados pueden seguir leyendo muchos recursos, incluidos todos los pods y los espacios de nombres del clúster.
  • Los nodos vulnerados pueden acceder a los secretos y las credenciales que usan todos los pods que se ejecutan en ese nodo.
  • Usar un grupo de nodos independiente para aislar tus cargas de trabajo puede afectar a la eficiencia de los costes, al escalado automático y al uso de los recursos.
  • Los nodos vulnerados pueden seguir eludiendo las políticas de red de salida.
  • Algunas cargas de trabajo gestionadas de GKE en Azure deben ejecutarse en todos los nodos de tu clúster y están configuradas para tolerar todos los taints.
  • Si implementas DaemonSets que tienen permisos elevados y pueden tolerar cualquier taint, esos pods pueden ser una vía para la elevación de privilegios desde un nodo vulnerado.

Cómo funciona el aislamiento de nodos

Para implementar el aislamiento de nodos en tus cargas de trabajo, debes hacer lo siguiente:

  1. Aplica un taint y una etiqueta a un grupo de nodos para tus cargas de trabajo.
  2. Actualiza tus cargas de trabajo con la regla de tolerancia y afinidad de nodo correspondiente.

En esta guía se presupone que empiezas con un grupo de nodos en tu clúster. No es obligatorio usar la afinidad de nodos junto con los taints de nodos, pero te recomendamos que lo hagas porque te permite tener un mayor control sobre la programación.

Antes de empezar

Para seguir los pasos de esta página, primero debes hacer lo siguiente:

Taint y etiqueta de un grupo de nodos para tus cargas de trabajo

Crea un grupo de nodos para tus cargas de trabajo y aplica un taint y una etiqueta de nodo. Cuando aplicas un taint o una etiqueta a nivel del grupo de nodos, los nodos nuevos, como los que se crean mediante el escalado automático, obtendrán automáticamente los taints y las etiquetas especificados.

También puedes añadir taints y etiquetas de nodo a grupos de nodos que ya tengas. Si usas el efecto NoExecute, GKE en Azure expulsa los pods que se ejecutan en los nodos que no tienen una tolerancia para el nuevo taint.

Para añadir un taint y una etiqueta a un grupo de nodos nuevo, ejecuta el siguiente comando:

gcloud container azure node-pools create POOL_NAME \
    --cluster CLUSTER_NAME \
    --node-taints TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
    --node-labels LABEL_KEY=LABEL_VALUE

Haz los cambios siguientes:

  • POOL_NAME: el nombre del nuevo grupo de nodos para tus cargas de trabajo.
  • CLUSTER_NAME: el nombre de tu clúster de GKE en Azure.
  • TAINT_KEY=TAINT_VALUE: un par clave-valor asociado a una programación TAINT_EFFECT. Por ejemplo, workloadType=untrusted.
  • TAINT_EFFECT: uno de los siguientes valores de efecto: NoSchedule, PreferNoSchedule o NoExecute. NoExecute ofrece una garantía de desalojo mejor que NoSchedule.
  • LABEL_KEY=LABEL_VALUE: pares clave-valor de las etiquetas de nodo, que corresponden a los selectores que especificas en los manifiestos de carga de trabajo.

Añadir una tolerancia y una regla de afinidad de nodos a tus cargas de trabajo

Después de aplicar un taint al grupo de nodos dedicado, no se podrá programar ninguna carga de trabajo en él a menos que tenga una tolerancia correspondiente al taint que hayas añadido. Añade la tolerancia a la especificación de tus cargas de trabajo para que esos pods se programen en tu grupo de nodos con intolerancias.

Si has etiquetado el grupo de nodos dedicado, también puedes añadir una regla de afinidad de nodos para indicar a GKE en Azure que solo programe tus cargas de trabajo en ese grupo de nodos.

En el siguiente ejemplo se añade una tolerancia para el taint workloadType=untrusted:NoExecute y una regla de afinidad de nodo para la etiqueta de nodo workloadType=untrusted.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      - key: TAINT_KEY
        operator: Equal
        value: TAINT_VALUE
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: LABEL_KEY
                operator: In
                values:
                - "LABEL_VALUE"
      containers:
      - name: sleep
        image: ubuntu
        command: ["/bin/sleep", "inf"]

Haz los cambios siguientes:

  • TAINT_KEY: la clave de taint que has aplicado a tu grupo de nodos dedicado.
  • TAINT_VALUE: el valor de taint que has aplicado a tu grupo de nodos dedicado.
  • LABEL_KEY: la clave de la etiqueta de nodo que has aplicado a tu grupo de nodos dedicado.
  • LABEL_VALUE: el valor de la etiqueta de nodo que has aplicado a tu grupo de nodos dedicado.

Cuando actualizas tu Deployment con kubectl apply, GKE en Azure vuelve a crear los Pods afectados. La regla de afinidad de nodos fuerza a los pods a usar el grupo de nodos dedicado que has creado. La tolerancia permite que solo esos pods se coloquen en los nodos.

Verificar que la separación funciona

Para verificar que la programación funciona correctamente, ejecuta el siguiente comando y comprueba si tus cargas de trabajo están en el grupo de nodos dedicado:

kubectl get pods -o=wide

Recomendaciones y prácticas recomendadas

Después de configurar el aislamiento de nodos, te recomendamos que hagas lo siguiente:

  • Restringe grupos de nodos específicos a cargas de trabajo gestionadas por GKE en Azure añadiendo el taint components.gke.io/gke-managed-components. Añadir esta marca evita que tus pods se programen en esos nodos, lo que mejora el aislamiento.
  • Cuando crees grupos de nodos, evita que la mayoría de las cargas de trabajo gestionadas de GKE en Azure se ejecuten en esos nodos añadiendo tu propio taint a esos grupos de nodos.
  • Cada vez que implementes nuevas cargas de trabajo en tu clúster, como cuando instales herramientas de terceros, audita los permisos que requieren los pods. Cuando sea posible, evite desplegar cargas de trabajo que usen permisos elevados en nodos compartidos.

Siguientes pasos