Procedimientos recomendados para administrar la seguridad y las actualizaciones de los clústeres en Azure Kubernetes Service (AKS)

  • Artículo

A medida que administra los clústeres en Azure Kubernetes Service (AKS), es clave considerar la seguridad de los datos y de las cargas de trabajo. Cuando ejecuta clústeres multiinquilino con aislamiento lógico, debe proteger especialmente el acceso a los recursos y a las cargas de trabajo. Minimice el riesgo de ataque mediante la aplicación de las actualizaciones de seguridad más recientes de Kubernetes y del sistema operativo del nodo.

En este artículo se indica cómo proteger el clúster de AKS. Aprenderá a:

  • Usar Microsoft Entra ID y el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) para proteger el acceso al servidor de API.
  • Proteger el acceso del contenedor a los recursos del nodo.
  • Actualizar un clúster de AKS a la última versión de Kubernetes.
  • Mantener actualizados los nodos y aplicar automáticamente los parches de seguridad.

También puede leer las prácticas recomendadas para la administración de imágenes de contenedor y para seguridad de pod.

Habilitación de la protección contra amenazas

Guía de procedimientos recomendados

Puede habilitar Defender para contenedores para ayudar a proteger los contenedores. Defender para contenedores puede evaluar las configuraciones de clúster y proporcionar recomendaciones de seguridad, ejecutar exámenes de vulnerabilidades y proporcionar protección y alertas en tiempo real para los nodos y clústeres de Kubernetes.

Proteger el acceso a los nodos del clúster y al servidor de API

Guía de procedimientos recomendados

Una de las formas más importantes de proteger el clúster es proteger el acceso al servidor de API de Kubernetes. Integre el control de acceso basado en rol de Kubernetes con Microsoft Entra ID para controlar el acceso al servidor de API. Con estos controles puede proteger AKS del mismo modo que protege el acceso a las suscripciones a Azure.

El servidor de API de Kubernetes proporciona un punto de conexión único para las solicitudes para realizar acciones dentro de un clúster. Para proteger y auditar el acceso al servidor de API, limite el acceso y proporcione los niveles de permiso más bajos posibles. Aunque este enfoque no es exclusivo de Kubernetes, es especialmente importante cuando ha aislado lógicamente el clúster de AKS para el uso multiinquilino.

Microsoft Entra ID proporciona una solución de administración de identidades para el ámbito empresarial que se puede integrar con los clústeres de AKS. Dado que Kubernetes no proporciona una solución de administración de identidades, es posible que se sienta obligado a restringir de forma individual el acceso al servidor de API. Con los clústeres integrados con Microsoft Entra en AKS, usted utiliza sus cuentas de usuario y de grupo existentes para autenticar a los usuarios en el servidor de API.

Microsoft Entra integration for AKS clusters

Mediante la integración del control de acceso basado en rol de Kubernetes y Microsoft Entra ID, puede proteger el servidor de API y proporcionar los permisos mínimos necesarios para un conjunto de recursos con ámbito como, por ejemplo, un espacio de nombres único. Puede conceder a diferentes usuarios o grupos de Microsoft Entra diferentes roles de Kubernetes. Con permisos específicos puede restringir el acceso al servidor de API y proporcionar una pista de auditoría clara de las acciones realizadas.

El procedimiento recomendado consiste en utilizar grupos para proporcionar acceso a archivos y carpetas en lugar de identidades individuales. Por ejemplo, utilizar una pertenencia a un grupo de Microsoft Entra ID para enlazar usuarios a roles de Kubernetes en lugar de usuarios individuales. A medida que cambie la pertenencia al grupo de un usuario, también lo harán sus permisos de acceso en el clúster de AKS.

Mientras tanto, supongamos que enlaza al usuario individual directamente a un rol y su función de trabajo cambia. Aunque las pertenencias al grupo de Microsoft Entra se actualizarán, sus permisos en el clúster de AKS no lo harán. En este escenario, el usuario al final cuenta con más permisos de los que necesita.

Para más información sobre la integración de Microsoft Entra, RBAC de Kubernetes y Azure RBAC, consulte los procedimientos recomendados para la autenticación y autorización en AKS.

Restricción del acceso a la API de Instance Metadata

Guía de procedimientos recomendados

Agregue una directiva de red en todos los espacios de nombres de usuario para bloquear la salida del pod al punto de conexión de metadatos.

Nota:

Para implementar la directiva de red, incluya el atributo --network-policy azure al crear el clúster de AKS. Usa el siguiente comando para crear el clúster: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Proteger el acceso del contenedor a los recursos

Guía de procedimientos recomendados

Limite el acceso a las acciones que los contenedores pueden realizar. Proporcione el menor número de permisos y evite el uso del acceso a raíz y la elevación de privilegios.

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.

Por ejemplo, establezca allowPrivilegeEscalation: false en el manifiesto de pod. Estos contextos de seguridad de pod integrados en Kubernetes le permiten definir permisos adicionales, como el usuario o grupo como el que se ejecutará, o qué funcionalidades de Linux se expondrán. Para más recomendaciones, consulte Protección del acceso del pod a los recursos.

Para un control aún más detallado de las acciones de los contenedores, también 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.

Nota:

Actualmente, los entornos de Kubernetes no están completamente seguros ante el uso de varios inquilinos hostiles. Las características de seguridad adicionales, como Microsoft Defender para contenedores, AppArmor, seccomp, las directivas de seguridad de pods o el control de acceso basado en rol de Kubernetes para los nodos, bloquean eficazmente las vulnerabilidades de seguridad.

Para una verdadera seguridad al ejecutar cargas de trabajo multiinquilino hostiles, solo debe confiar en un hipervisor. El dominio de seguridad de Kubernetes se convierte en todo el clúster, no en un nodo específico.

En el caso de estos tipos de cargas de trabajo multiinquilino hostiles, debe usar clústeres que estén físicamente aislados.

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.

AppArmor profiles in use in an AKS cluster to limit container actions

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 se le devolverá 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

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 Docker que utilizan los nodos de AKS. Con seccomp, puede limitar las llamadas de proceso de contenedor. 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 lo siguiente:

    {
  "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 lo siguiente:

    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 siguiente:
    kubectl get pods

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

Para más información sobre los filtros disponibles, consulte Perfiles de seguridad de Seccomp para Docker.

Actualización regular a la versión más reciente de Kubernetes

Guía de procedimientos recomendados

Para mantenerse al día con las nuevas características y correcciones de errores, actualice regularmente la versión de Kubernetes en el clúster de AKS.

Kubernetes presenta nuevas características a un ritmo más rápido que otras plataformas de infraestructura más tradicionales. Las actualizaciones de Kubernetes incluyen:

  • Nuevas características
  • Correcciones de errores o de seguridad

Las nuevas características normalmente pasan al estado alfa y beta antes de convertirse en estables. Una vez que son estables, están disponibles con carácter general y se recomiendan para su uso en producción. Este nuevo ciclo de versión de actualización de características debería permitirle actualizar Kubernetes sin encontrar normalmente cambios importantes ni tener que ajustar las implementaciones ni las plantillas.

AKS es compatible con tres versiones secundarias de Kubernetes. Cuando se introduce una nueva versión secundaria de revisión, se retiran la versión secundaria y la versión de revisión compatibles más antiguas. Las actualizaciones secundarias de Kubernetes se realizan periódicamente. Para poder disponer de soporte técnico, asegúrese de que tiene un proceso de gobernanza para comprobar si hay actualizaciones necesarias. Para más información, consulte Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS).

Para comprobar las versiones que están disponibles para el clúster, use el comando az aks get-upgrades tal como se muestra en el ejemplo siguiente:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

A continuación, puede actualizar el clúster de AKS con el comando az aks upgrade. De forma segura, el proceso de actualización:

  • Acordona y purga un nodo cada vez.
  • Programa pods en los nodos restantes.
  • Implementa un nuevo nodo que ejecuta las versiones más recientes del sistema operativo y Kubernetes.

Importante

Pruebe las nuevas versiones secundarias en un entorno de desarrollo y pruebas, y compruebe que la carga de trabajo funciona correctamente con la nueva versión de Kubernetes.

Kubernetes puede poner en desuso las API (como en la versión 1.16) en las que se basan las cargas de trabajo. Al incorporar nuevas versiones en producción, considere la posibilidad de usar varios grupos de nodos en versiones independientes y actualizar grupos individuales de uno en uno para implementar progresivamente la actualización en un clúster. Si se ejecutan varios clústeres, actualice un clúster cada vez para supervisar progresivamente el impacto o los cambios.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Para obtener más información sobre las actualizaciones de AKS, consulte Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS) y Actualización de un clúster de AKS.

Procesamiento de las actualizaciones de los nodos de Linux

Cada noche, los nodos Linux de AKS obtienen las actualizaciones de seguridad a través de su canal de actualización de distribuciones. Este comportamiento se configura automáticamente cuando se implementan los nodos en un clúster de AKS. Para minimizar las interrupciones y el posible impacto sobre las cargas de trabajo en ejecución, los nodos no se reinician automáticamente si lo requiere una revisión de seguridad o una actualización de kernel. Para más información sobre cómo controlar los inicios del nodo, consulte Aplicación de actualizaciones de kernel y de seguridad en los nodos en AKS.

Actualizaciones de imágenes de nodo

Las actualizaciones desatendidas aplican actualizaciones al sistema operativo del nodo de Linux, pero la imagen que se usa para crear los nodos del clúster no se modifica. Si se agrega un nuevo nodo de Linux al clúster, se usa la imagen original para crear el nodo. Este nuevo nodo recibirá todas las actualizaciones de seguridad y del kernel que haya disponibles durante la comprobación automática cada noche, pero no se le aplicarán revisiones hasta que se completen todas las comprobaciones y los reinicios. Puede usar la actualización de la imagen de nodo para buscar y actualizar las imágenes de nodo que usa el clúster. Para más información sobre la actualización de imágenes de nodo, consulte Actualización de la imagen de nodos de Azure Kubernetes Service (AKS).

Procesamiento de las actualizaciones de los nodos de Windows Server

Para los nodos de Windows Server, realice periódicamente una operación de actualización de imágenes de nodo para acordonar y drenar los pods de forma segura, e implemente los nodos actualizados.