Acceso de contenedor de seguridad a los recursos mediante características de seguridad integradas de Linux

En este artículo, aprenderá a proteger el acceso de contenedores a los recursos de las cargas de trabajo de Azure Kubernetes Service (AKS).

Información general

Por el mismo motivo que debería conceder a los usuarios o a los grupos el menor número de privilegios necesarios, también debería limitar los contenedores a solo las acciones y procesos necesarios. Para minimizar el riesgo de ataques, evite configurar las aplicaciones y los contenedores que requieren elevación de privilegios o acceso a raíz.

Puede usar contextos de seguridad de pod de Kubernetes integrados para definir más permisos, como el usuario o grupo para ejecutarse como, las funcionalidades de Linux que se van a exponer o establecer allowPrivilegeEscalation: false en el manifiesto de pod. Para más recomendaciones, consulte Protección del acceso del pod a los recursos.

Para mejorar el aislamiento del host y reducir el movimiento lateral en Linux, se pueden usar espacios de nombres de usuario.

Para un control aún más detallado de las acciones de los contenedores, puede usar las características de seguridad incorporadas de Linux como AppArmor y seccomp.

1. Defina las características de seguridad de Linux en el nivel de nodo.
2. Implemente las características mediante un manifiesto de pod.

Las características de seguridad integradas de Linux solo están disponibles en los pods y los nodos de Linux.

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

• Mayor aislamiento de host: si un contenedor escapa de los límites del pod, incluso si se ejecuta como raíz dentro del contenedor, no tiene privilegios en el host. El motivo es que los UID y los GID del contenedor se asignan a usuarios sin privilegios en el host. Si hay un escape de contenedor, los espacios de nombres de usuario protegen en gran medida qué archivos del host puede leer/escribir un contenedor y a qué proceso puede enviar señales. Las funcionalidades concedidas solo son válidas dentro del espacio de nombres de usuario y no en el host.

• Prevención del movimiento lateral: dado que los UID y GID para diferentes contenedores se asignan a UID y GID diferentes que no se superponen en el host, les resulta más difícil a los contenedores atacarse entre sí. Por ejemplo, supongamos que el contenedor A se ejecuta con diferentes UIDs y GIDs en el host que el contenedor B. En el caso de una fuga de contenedor, las operaciones que puede realizar en los archivos y procesos del contenedor B son limitadas: solo puede leer/escribir lo que un archivo permite a otros. Pero ni siquiera eso termina siendo posible, ya que hay una restricción adicional en el directorio principal del volumen raíz del pod para asegurarse de que solo el GID del pod puede acceder a él.

• Respetar el principio de privilegios mínimos: a medida que los UID y los GID se asignan a usuarios sin privilegios en el host, solo los usuarios que necesitan el privilegio en el host (y deshabilitan los espacios de nombres de usuario) lo obtienen. Sin espacios de nombres de usuario, no hay ninguna separación entre los usuarios del contenedor y los usuarios del host. No podemos evitar conceder privilegios en el host a los procesos que no lo necesitan, cuando necesitan privilegios justo dentro del contenedor.

• Habilitación de nuevos casos de uso: los espacios de nombres de usuario permiten a los contenedores obtener determinadas funcionalidades dentro de su propio espacio de nombres de usuario sin afectar al host. Las capacidades restringidas otorgadas al pod desbloquean nuevas posibilidades, como ejecutar aplicaciones que requieren operaciones privilegiadas sin otorgar acceso raíz completo en el host. Los nuevos casos de uso comunes que se pueden implementar de forma segura son: ejecutar contenedores anidados y compilaciones de contenedores sin privilegios.

• Configuración de contenedor sin privilegios: la mayoría de la creación y configuración del contenedor no se ejecutan como raíz en el host, lo que limita significativamente el impacto de muchos CVE.

No se cumple ninguna de estas cosas cuando no se usan espacios de nombres de usuario. Si el contenedor se ejecuta como raíz, cuando no se usan espacios de nombres de usuario, el proceso se ejecuta como raíz en el host, las funcionalidades son válidas en el host y la configuración del contenedor se realiza como raíz en el host.

Antes de empezar

Antes de comenzar, asegúrese de que dispone de lo siguiente:

• 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, deberá actualizar la versión de Kubernetes.
• Nodos de trabajo que ejecutan Azure Linux 3.0 o Ubuntu 24.04. Si no utiliza estas versiones del sistema operativo, no tendrá los requisitos de pila mínimos para habilitar los espacios de nombres de usuario. Deberá actualizar la versión del sistema operativo.

Limitaciones

• Los espacios de nombres de usuario son una característica del núcleo de Linux y no se admiten en los grupos de nodos de Windows.
• No dude en consultar la documentación de Kubernetes para los espacios de nombres de usuario, especialmente la sección de limitaciones.

Habilitar espacios de nombres de usuario

No hay ninguna configuración necesaria para usar esta característica. Si usa la versión de AKS necesaria, todo funciona de forma predeterminada.

1. Cree un archivo denominado mypod.yaml y cópielo en el siguiente 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. Acceda al pod para comprobar /proc/self/uid_map usando el comando kubectl exec:

   kubectl exec -ti userns -- bash
   # Now inside the pod run
   cat /proc/self/uid_map
   

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

0  833617920      65536

CVEs mitigados

Estos son algunos CVEs que se mitigan completamente o parcialmente con espacios de nombres de usuario.

Tenga en cuenta que la lista no es exhaustiva, es solo una selección de CVE con puntuación alta que se mitigan:

• CVE-2019-5736 - Puntuación 8.6 (ALTA)
• CVE 2024-21262: Puntuación 8.6 (ALTA)
• CVE 2022-0492: Puntuación 7.8 (ALTA)
• CVE-2021-25741: Puntuación: 8.1 (HIGH) / 8.8 (HIGH)
• CVE-2017-1002101: Puntuación: 9.6 (CRÍTICO) / 8.8(HIGH)

Para más información, lea esta entrada de blog con información adicional sobre los espacios de nombres de usuario.

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 SO del nodo de AKS subyacente del sistema operativo y está habilitado de forma predeterminada. Puede crear perfiles de AppArmor para restringir acciones como leer, escribir o ejecutar, o funciones del sistema como montar 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.

Para ver AppArmor en acción, en el ejemplo siguiente se crea un perfil que impide la escritura en archivos.

1. Acceda mediante SSH a un nodo de AKS.

2. Cree un archivo denominado deny-write.profile.

3. Copie 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,
   }
   

Los perfiles de AppArmor se agregan con el comando apparmor_parser.

1. Agregue el perfil a AppArmor.

2. Especifique el nombre del perfil creado en el paso anterior:

   sudo apparmor_parser deny-write.profile
   

   Si el perfil se analiza y se aplica correctamente a AppArmor, no verá ninguna salida y volverá al símbolo del sistema.

3. Desde la máquina local, cree un manifiesto de pod denominado aks-apparmor.yaml. Este manifiesto:

   • Define una anotación para container.apparmor.security.beta.kubernetes.
   • Hace referencia al perfil deny-write creado en los pasos anteriores.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. Con el pod implementado, ejecute el comando siguiente y compruebe que el pod hello-apparmor muestra un estado En ejecución:

   kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Running   0          50s
   

Para más información sobre AppArmor, consulte los perfiles de AppArmor en Kubernetes.

Informática segura (seccomp)

Si bien AppArmor funciona con cualquier aplicación de Linux, seccomp (secure computing) funciona en el nivel de proceso. Seccomp también es un módulo de seguridad del kernel de Linux, y es compatible de forma nativa con el tiempo de ejecución de containerd que utilizan los nodos de AKS. 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.

Configuración de un perfil de seccomp predeterminado (versión preliminar)

Puede aplicar perfiles de seccomp predeterminados mediante configuraciones de nodo personalizadas al crear un nuevo grupo de nodos de Linux. Hay dos valores admitidos en AKS: RuntimeDefault 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.

Limitaciones

• SeccompDefault no es un parámetro compatible para los grupos de nodos de Windows.
• SeccompDefault está disponible a partir de la API 2024-09-02-preview.

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
   

Restricción de las llamadas del sistema del contenedor con seccomp

1. Siga los pasos para aplicar un perfil de seccomp en la configuración de kubelet especificando "seccompDefault": "RuntimeDefault".

RuntimeDefault usa el perfil de seccomp predeterminado del contenedor, lo que restringe determinadas llamadas del sistema para mejorar la seguridad. Se producirá un error en las llamadas del sistema restringidas. Para más información, consulte el perfil seccomp predeterminado de containerD.

2. Compruebe que se aplicó la configuración .

Puede confirmar que la configuración se ha aplicado a los nodos mediante la conexión al host y la comprobación de que los cambios de configuración se han realizado en el sistema de archivos.

3. Solución de errores de carga de trabajo.

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. Esto puede provocar un error en las cargas de trabajo debido a llamadas de syscall bloqueadas. Si se ha producido un error de carga de trabajo, es posible que vea errores como:

• La carga de trabajo existe inesperadamente después de habilitar la característica, 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 los errores anteriores, se recomienda cambiar el perfil de seccomp a Unconfined. Unconfined no aplica restricciones a las llamadas sys, lo que permite todas las llamadas del sistema, lo que reduce la seguridad.

Configuración de un perfil de seccomp personalizado

Con un perfil de seccomp personalizado, puede tener un control más granular sobre las llamadas de sys restringidas. Adopte el procedimiento recomendado de conceder al contenedor el permiso mínimo solo para ejecutarlo mediante:

• La definición que filtra qué acciones se permiten o deniegan.
• La anotación dentro de un manifiesto YAML de pod para asociarlo al filtro de seccomp.

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.
   • Hace referencia al filtro prevent-chmod que se creó en el paso anterior.

   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 con el comando kubectl apply:

   kubectl apply -f ./aks-seccomp.yaml
   

6. Consulte el estado de los pod mediante el comando kubectl get pods.

   • El pod indica un error.
   • El filtro seccomp impide que se ejecute el comando chmod, tal como se muestra en la salida del ejemplo:

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

Para obtener ayuda para solucionar problemas de su perfil de seccomp, consulte el artículo Solución de problemas de configuración de perfiles de seccomp en Azure Kubernetes Service.

Opciones de perfil de seguridad de Seccomp

Los perfiles de seguridad de Seccomp son un conjunto de llamadas syscall definidas permitidas o restringidas. La mayoría de los entornos de ejecución de contenedor tienen un perfil de seccomp predeterminado similar si no es el mismo que el que usa Docker. Para obtener más información sobre los perfiles disponibles, consulte Perfiles de seccomp predeterminados de Docker o containerD.

AKS usa el perfil de seccomp predeterminado containerD para RuntimeDefault al configurar seccomp mediante la configuración de nodo personalizada.

Llamadas de syscall significativas bloqueadas por perfil predeterminado

Tanto Docker como containerD mantienen listas de permitidos de llamadas seguras de syscalls. En esta tabla se enumeran las llamadas de sistema significativas (pero no todas) que están bloqueadas de forma eficaz porque no están en la lista de permitidos. Si la carga de trabajo requiere alguna de las llamadas de syscall bloqueadas, no use el perfil de seccomp RuntimeDefault.

Cuando se realizan cambios en Docker y containerD, AKS actualiza su configuración predeterminada para que coincida. Las actualizaciones de esta lista pueden provocar un error en la carga de trabajo. Para obtener actualizaciones de versión, consulte las notas de la versión de AKS.

Pasos siguientes

Para los procedimientos recomendados asociados, consulte Procedimientos recomendados para la seguridad de clústeres y las actualizaciones en AKS y Procedimientos recomendados para la seguridad de pod en AKS.