Protección del acceso de contenedores a los recursos para cargas de trabajo de Azure Kubernetes Service (AKS) mediante características de seguridad integradas de Linux

Requisitos previos para espacios de nombres de usuario

• Un clúster de AKS existente Si no dispone de un clúster, cree uno mediante Azure CLI, Azure PowerShell o el Azure Portal.
• Versión mínima de Kubernetes 1.33 para el plano de control y los nodos de trabajo. Si no usa la versión 1.33 o posterior de Kubernetes, debe actualizar la versión de Kubernetes.
• Nodos de trabajo que ejecutan Azure Linux 3.0 o Ubuntu 24.04 para asegurarse de que cumple los requisitos mínimos de pila para habilitar espacios de nombres de usuario. Si necesita actualizar la versión del sistema operativo (SO), consulte Actualización de la versión del sistema operativo.

Limitaciones de los espacios de nombres de usuario

• La característica de espacios de nombres de usuario es para el kernel de Linux y no es compatible con los grupos de nodos de Windows.
• Consulte la documentación de Kubernetes sobre espacios de nombres de usuario para cualquier otra limitación.

Información general sobre los espacios de nombres de usuario

Los pods de Linux se ejecutan con varios espacios de nombres de forma predeterminada: espacios de nombres de red para aislar la identidad de red y un espacio de nombres PID para aislar los procesos. Un espacio de nombres de usuario (user_namespace) aísla a los usuarios dentro del contenedor de los usuarios del host. También limita el ámbito de las funcionalidades y las interacciones del pod con el resto del sistema.

Los uid y los gid dentro del contenedor se asignan a usuarios sin privilegios en el host, por lo que toda la interacción con el resto del host se produce como esos uid y gid sin privilegios. Por ejemplo, la raíz dentro del contenedor (UID 0) se puede asignar al usuario 65536 en el host. Kubernetes crea la asignación para garantizar que no se superpone con otros pods mediante espacios de nombres de usuario en el sistema.

La implementación de Kubernetes tiene algunas ventajas clave. Para obtener más información, consulte la documentación de Espacios de Nombres de Usuario de Kubernetes.

Habilitar espacios de nombres de usuario

1. Cree un archivo denominado mypod.yaml y cópielo en el siguiente código manifiesto. Para usar espacios de nombres de usuario, YAML debe tener el campo hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Implemente la aplicación mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML.

   kubectl apply -f mypod.yaml
   

3. Compruebe el estado de los pods implementados con el comando kubectl get pods.

   kubectl get pods
   

4. Ejecute en el pod usando el comando kubectl exec.

   kubectl exec -ti userns -- bash
   

5. Dentro del pod, compruebe /proc/self/uid_map con el comando siguiente:

   cat /proc/self/uid_map
   

   La salida debe tener 65536 en la última columna. Por ejemplo:

   0  833617920      65536
   

   Esta salida indica que la raíz dentro del contenedor (UID 0) se asigna al usuario 65536 en el host.

Vulnerabilidades y exposiciones comunes (CVEs) mitigadas por espacios de nombres de usuario

En la tabla siguiente se describen algunas vulnerabilidades y exposiciones comunes (ECV) que se mitigan parcialmente o totalmente mediante user_namespaces:

Tenga en cuenta que esta lista no es exhaustiva. Para más información, consulte Kubernetes v1.33: Espacios de nombres de usuario habilitados de forma predeterminada.

Requisitos previos de AppArmor

• Un clúster de AKS existente Si no dispone de un clúster, cree uno mediante Azure CLI, Azure PowerShell o el Azure Portal.

Introducción a AppArmor

Para limitar las acciones de los contenedores, puede usar el módulo de seguridad del kernel de Linux denominado AppArmor. AppArmor está disponible como parte del sistema operativo (SO) del nodo de AKS subyacente y está habilitado de forma predeterminada. Puede crear perfiles de AppArmor que restrinjan las acciones de lectura, escritura o ejecución, o funciones del sistema como el montaje de sistemas de archivos. Los perfiles de AppArmor predeterminados restringen el acceso a diferentes ubicaciones de /proc y /sys, y proporcionan un medio para aislar lógicamente los contenedores desde el nodo subyacente. AppArmor funciona para cualquier aplicación que se ejecuta en Linux, no solo para los pods de Kubernetes.

Asegurar los pods con AppArmor

Puede especificar perfiles de AppArmor en el nivel de pod o contenedor. El perfil de AppArmor del contenedor tiene prioridad sobre el perfil de AppArmor del pod. Si no se especifica ninguno, el contenedor se ejecuta sin restricciones. Para más información sobre los perfiles de AppArmor, consulte la documentación de Kubernetes sobre la protección de un pod con AppArmor.

Configuración de un perfil personalizado de AppArmor

En el ejemplo siguiente se crea un perfil que impide la escritura en archivos desde un contenedor.

1. Acceda mediante SSH a un nodo de AKS.

2. Cree un archivo denominado deny-write.profile y pegue el siguiente contenido:

   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   

3. Cargue el perfil de AppArmor en el nodo.

   # This example assumes that node names match host names, and are reachable via SSH.
   NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))
   
   for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   EOF'
   done
   

Despliega un pod con el perfil personalizado de AppArmor

1. Implemente un pod "Hello AppArmor" con el perfil de denegación de escritura.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
   spec:
     securityContext:
       appArmorProfile:
         type: Localhost
         localhostProfile: k8s-apparmor-example-deny-write
     containers:
     - name: hello
       image: busybox:1.28
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

2. Aplique el manifiesto del pod mediante el comando kubectl apply.

   kubectl apply -f hello-apparmor.yaml
   

3. Ejecute el comando exec en el pod y compruebe que el contenedor se está ejecutando con el perfil de AppArmor.

   kubectl exec hello-apparmor -- cat /proc/1/attr/current
   

   La salida debe mostrar el perfil de AppArmor en uso. Por ejemplo:

   k8s-apparmor-example-deny-write (enforce)
   

Requisitos previos de Seccomp

• Un clúster de AKS existente Si no dispone de un clúster, cree uno mediante Azure CLI, Azure PowerShell o el Azure Portal.
• Debe registrar la marca de características KubeletDefaultSeccompProfilePreview para usar perfiles de seccomp predeterminados en los grupos de nodos.

Registro de la marca de característica KubeletDefaultSeccompProfilePreview

1. Registre la marca de características de KubeletDefaultSeccompProfilePreview mediante el comando az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   Tarda unos minutos en que el estado muestre Registrado.

2. Comprobar el estado del registro mediante el comando az feature show.

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. Cuando aparezca el estado Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register.

   az provider register --namespace Microsoft.ContainerService
   

Limitaciones de Seccomp

• AKS solo admite los perfiles de seccomp predeterminados (RuntimeDefault y Unconfined). No se admiten perfiles de seccomp personalizados.
• SeccompDefault no es un parámetro admitido para los grupos de nodos de Windows.

Introducción a los perfiles de seccomp predeterminados (versión preliminar)

Aunque AppArmor funciona para cualquier aplicación Linux, seccomp (o informática segura) funciona en el nivel de proceso. Seccomp también es un módulo de seguridad de kernel de Linux. El containerd tiempo de ejecución usado por los nodos de AKS proporciona compatibilidad nativa con seccomp. Con seccomp, puede limitar las llamadas del sistema de un contenedor. Seccomp establece una capa adicional de protección contra vulnerabilidades comunes de llamadas del sistema explotadas por actores malintencionados y permite especificar un perfil predeterminado para todas las cargas de trabajo del nodo.

Puede aplicar perfiles de seccomp predeterminados mediante configuraciones de nodo personalizadas al crear un nuevo grupo de nodos de Linux. AKS admite los RuntimeDefault valores y Unconfined . Algunas cargas de trabajo pueden requerir un número menor de restricciones de syscall que otras. Esto significa que pueden producir errores durante el tiempo de ejecución con el perfil RuntimeDefault. Para mitigar este error, puede especificar el perfil Unconfined. Si la carga de trabajo requiere un perfil personalizado, consulte Configuración de un perfil de seccomp personalizado.

Restringir las llamadas al sistema de contenedores con seccomp

1. Siga los pasos para aplicar un perfil de seccomp en la configuración de kubelet especificando "seccompDefault": "RuntimeDefault".
2. Conéctese al host.
3. Compruebe que la configuración se aplicó a los nodos.

Resolución de errores de carga de trabajo con seccomp

Cuando SeccompDefault está habilitado, el perfil de seccomp predeterminado del entorno de ejecución del contenedor se usa de forma predeterminada para todas las cargas de trabajo programadas en el nodo, lo que podría provocar un error en las cargas de trabajo debido a llamadas de syscall bloqueadas. Si se produce un error de carga de trabajo, es posible que vea errores como:

• La tarea se cierra inesperadamente después de activar la función, con el error "permiso denegado".
• Los mensajes de error de Seccomp también se pueden ver en auditado o syslog reemplazando SCMP_ACT_ERRNO por SCMP_ACT_LOG en el perfil predeterminado.

Si experimenta estos errores, se recomienda cambiar el perfil de seccomp a Unconfined. Unconfined no aplica restricciones a las llamadas sys, lo que permite ejecutar todas las llamadas del sistema.

Resumen de perfiles de seccomp personalizados

Con un perfil de seccomp personalizado, tiene un control más pormenorizado sobre las llamadas al sistema restringidas para los contenedores. Puede crear sus propios perfiles de seccomp mediante:

• Usar filtros para especificar qué acciones se van a permitir o denegar.
• La anotación dentro de un manifiesto YAML de pod para asociarlo al filtro de seccomp.

Configuración de un perfil de seccomp personalizado

Para ver seccomp en acción, cree un filtro que evite el cambio de permisos en un archivo.

1. Acceda mediante SSH a un nodo de AKS.

2. Cree un filtro de seccomp denominado /var/lib/kubelet/seccomp/prevent-chmod.

3. Copie y pegue el siguiente contenido:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   En la versión 1.19 y versiones posteriores, debe configurar:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. En la máquina local, cree un manifiesto de pod denominado aks-seccomp.yaml y pegue el contenido siguiente. Este manifiesto define una anotación para seccomp.security.alpha.kubernetes.io y hace referencia al filtro prevent-chmod existente.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   En la versión 1.19 y versiones posteriores, debe configurar:

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Implemente el pod de ejemplo mediante el kubectl apply comando :

   kubectl apply -f ./aks-seccomp.yaml
   

6. Vea el estado del pod mediante el kubectl get pods comando .

   kubectl get pods
   

   En la salida, debería ver que el pod notifica un error. El filtro seccomp impide que se ejecute el comando chmod, tal como se muestra en la salida del ejemplo:

   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s