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

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

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.

Responsabilidades de seguridad del modo de clúster de AKS

AKS admite dos modos de clúster: AKS Automatic y AKS Standard. Los objetivos de seguridad son los mismos en ambos modos, pero la responsabilidad de implementación difiere.

AKS Automatic incluye una base reforzada con más controles preconfigurados en las configuraciones compatibles. AKS Standard proporciona un control de configuración directo más amplio, lo que aumenta la responsabilidad del operador para la configuración de línea base y las operaciones en curso.

Area AKS Automatic AKS Standard
Línea base de autenticación y autorización del clúster Más valores predeterminados preconfigurados en configuraciones admitidas Normalmente configurado explícitamente por operadores
Refuerzo de la red del servidor API Más comportamientos de referencia preconfigurados en las configuraciones admitidas Decisiones explícitas de refuerzo de la seguridad de los operadores
Directiva y controles de seguridad de línea base Más valores predeterminados preconfigurados en configuraciones admitidas Selección de modo y habilitación de directivas explícitas
Controles de higiene de imágenes Controles de línea base disponibles en configuraciones admitidas Habilitación explícita y propiedad del ciclo de vida
Operaciones del grupo de nodos del sistema Más comportamiento administrado por el servicio Más comportamiento administrado por el operador
Mejorar la propiedad Más configuraciones predeterminadas de actualización administradas Estrategia seleccionada por el operador y gobernanza de la implementación

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.

Esta guía se aplica a ambos modos. Incluso cuando AKS Automatic proporciona valores predeterminados de seguridad preconfigurados, los flujos de trabajo de incorporación de protección contra amenazas y respuesta a alertas siguen siendo responsabilidades operativas para su equipo.

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. Para controlar el acceso al servidor de la API, integre RBAC de Kubernetes con Microsoft Entra ID. 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 gestión de identidades, puede resultarle difícil restringir de forma granular el acceso al servidor 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.

Integración de Microsoft Entra para clústeres de AKS

Con la integración de Kubernetes RBAC y Microsoft Entra ID, puede proteger el servidor API y proporcionar los permisos mínimos necesarios para un conjunto de recursos de ámbito limitado, como un único espacio de nombres. 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.

En AKS Automatic, la autorización y las configuraciones de seguridad de referencia están más preconfiguradas en las configuraciones compatibles, por lo que los operadores se centran en la validación, la gobernanza y la gestión de excepciones. En AKS Standard, los operadores suelen configurar estos controles directamente y mantener su posición de ciclo de vida.

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 --network-plugin azure --network-policy azure --generate-ssh-keys

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

En AKS Standard, asegúrese de que el modelo de red y el motor de directivas seleccionados admitan esta ruta de acceso de directiva. En AKS Automatic, aplique restricciones de salida equivalentes a nivel de espacio de nombres cuando la configuración del clúster lo admita.

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.

Mediante los espacios de nombres de usuario, se mejora el aislamiento del host y se limita el movimiento lateral en caso de evasión de contenedores. Estas mejoras son significativas tanto si el pod se ejecuta como raíz como si no.

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.

Incluso cuando AKS Automatic proporciona valores predeterminados protegidos, los controles de seguridad de nivel de carga de trabajo siguen siendo responsabilidades del equipo de la aplicación y la plataforma.

Para más información, consulte Protección del acceso del contenedor a los recursos.

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).

En AKS Automatic, el comportamiento relacionado con la actualización es más preconfigurado en las configuraciones admitidas, y los operadores deben centrarse en la validación de la preparación de la carga de trabajo y la gobernanza de versiones. En AKS Standard, los operadores eligen y rigen la estrategia de actualización y el tiempo de lanzamiento más directamente.

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

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

Después, puede actualizar el clúster de AKS mediante el az aks upgrade comando . El proceso de actualización seguro:

  • 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 podría dejar de usar las API (como en la versión 1.16) de las que dependen 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.

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.

En AKS Automatic, el comportamiento de actualización de nodos está más preconfigurado en configuraciones admitidas. En AKS Standard, los operadores suelen definir la gobernanza de revisiones y reinicios con controles operativos explícitos.

Actualizaciones de imágenes de nodo

Las actualizaciones automáticas instalan actualizaciones en el sistema operativo Linux del nodo, pero la imagen utilizada para crear los nodos de su clúster permanece inalterada. 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 disponibles en la comprobación automática nocturna, pero permanecerá sin parchear 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.

Contenido relacionado

Para obtener más información sobre AKS y proteger el clúster de AKS, consulte los artículos siguientes:

  • Last updated on