Conceptos de seguridad para aplicaciones y clústeres en Azure Kubernetes Service (AKS)

La seguridad del contenedor protege toda la canalización, de extremo a extremo, desde la compilación hasta las cargas de trabajo de la aplicación que se ejecutan en Azure Kubernetes Service (AKS).

La cadena de suministro segura incluye el registro y el entorno de compilación.

Kubernetes incluye componentes de seguridad, tales como normas de seguridad de pods y secretos. Azure incluye componentes como Active Directory, Microsoft Defender para contenedores, Azure Policy, Azure Key Vault, grupos de seguridad de red y actualizaciones de clúster orquestadas. AKS combina estos componentes de seguridad para:

• Proporcionar un caso completo de autenticación y autorización.
• Aplique Policy de Azure integradas en AKS para proteger sus aplicaciones.
• Perspectiva integral desde la creación hasta la aplicación con Microsoft Defender para contenedores.
• Hacer que el clúster de AKS ejecute las últimas actualizaciones de seguridad del sistema operativo y versiones de Kubernetes.
• Proporcionar tráfico de pod seguro y acceso a credenciales confidenciales.

En este artículo se presentan los conceptos básicos para proteger sus aplicaciones en AKS.

Seguridad de compilación

Como punto de entrada de la cadena de suministro, es importante realizar análisis estáticos de las compilaciones de imágenes antes de que se promuevan hacia abajo en la canalización. Esto incluye la evaluación de vulnerabilidades y cumplimiento. No se trata de que falle una compilación porque tenga una vulnerabilidad, ya que eso rompe el desarrollo. Se trata de observar el Estado del proveedor para segmentar según las vulnerabilidades en las que pueden actuar los equipos de desarrollo. Utilice también Períodos de gracia para conceder tiempo a los desarrolladores para corregir los problemas identificados.

Seguridad del registro

Al evaluar el estado de las vulnerabilidades de la imagen en el registro, se detecta el desfase y también se detectan las imágenes que no proceden del entorno de compilación. Use Notary V2 para adjuntar firmas a las imágenes para asegurarse de que las implementaciones proceden de una ubicación de confianza.

Seguridad de clúster

En AKS, los componentes maestros de Kubernetes forman parte del servicio administrado proporcionado, administrado y mantenido por Microsoft. Cada clúster de AKS tiene su propio maestro de Kubernetes dedicado y de alquiler único para proporcionar el servidor de API, el programador, etc. Para obtener más información, consulte Administración de vulnerabilidades para Azure Kubernetes Service.

De forma predeterminada, el servidor de API de Kubernetes utiliza una dirección IP pública y un nombre de dominio completo (FQDN). Puede limitar el acceso al punto de conexión del servidor de API mediante los intervalos IP autorizados. También puede crear un clúster privado por completo para limitar el acceso del servidor de la API a la red virtual.

Puede controlar el acceso al servidor de API mediante el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) y Azure RBAC. Para obtener más información, consulte Microsoft Entra integración con AKS.

Seguridad de nodos

Los nodos de AKS son máquinas virtuales (VMs) de Azure que usted administra y mantiene.

• Los nodos de Linux ejecutan versiones optimizadas de Ubuntu o Azure Linux.
• Los nodos de Windows Server ejecutan una versión optimizada de Windows Server usando el runtime de contenedor de containerd.

Cuando se crea o se escala verticalmente un clúster de AKS, los nodos se implementan automáticamente con las actualizaciones de seguridad del sistema operativo y las configuraciones más recientes.

Para obtener más información sobre el proceso de actualización de seguridad para nodos de trabajo de Linux y Windows, consulte Nodos de aplicación de revisiones de seguridad.

Los clústeres de AKS que ejecutan máquinas virtuales de Azure Generación 2 incluyen compatibilidad con Trusted Launch. Esta característica protege contra técnicas avanzadas y persistentes de ataque mediante la combinación de tecnologías que puede habilitar de forma independiente, como el arranque seguro y una versión virtualizada del módulo de plataforma segura (vTPM). Los administradores pueden implementar nodos de trabajo de AKS con cargadores de arranque comprobados y firmados, kernels del sistema operativo y controladores para garantizar la integridad de toda la cadena de arranque de la máquina virtual subyacente.

Opciones del sistema operativo optimizadas para contenedores y seguridad

AKS lanzó compatibilidad con dos nuevas opciones de sistema operativo Linux optimizadas. Azure Linux OS Guard (versión preliminar) es creado por Microsoft y optimizado para Azure. OS Guard se basa en Azure Linux con una configuración especializada para admitir cargas de trabajo en contenedores con optimizaciones de seguridad. Flatcar Container Linux para AKS (versión preliminar) es un sistema operativo inmutable optimizado para contenedores y neutral respecto al proveedor, basado en CNCF, que se adapta mejor a la ejecución en entornos multinube y locales. Estas opciones del sistema operativo proporcionan mayor seguridad en comparación con otras opciones del sistema operativo Linux, como:

• Tanto Azure Linux OS Guard como Flatcar Container Linux para AKS tienen un sistema operativo inmutable que no se puede modificar en tiempo de ejecución. Todos los archivos binarios del sistema operativo, las bibliotecas y la configuración estática son de solo lectura y la integridad de bits para bits a menudo está protegida criptográficamente. Estos sistemas operativos de propósito especial se envían como imágenes independientes y vienen sin ningún tipo de administración de paquetes u otros medios tradicionales de modificar el sistema operativo. Las cargas de trabajo de usuario se ejecutan en entornos aislados, como contenedores, en espacio aislado del sistema operativo.
• Tanto Azure Linux OS Guard como Flatcar Container Linux para AKS usan SELinux para Access Control obligatorios.
• Azure Linux OS Guard aplica las habilitaciones de FIPS y Trusted Launch, proporcionando un mejor cumplimiento y protección contra ataques avanzados y persistentes mediante la combinación de arranque seguro y la versión virtualizada del módulo de plataforma de confianza (vTPM).

Al decidir entre qué opciones de sistema operativo optimizadas para contenedores se van a usar, AKS recomienda lo siguiente:

• Use Flatcar Container Linux para AKS (versión preliminar) si busca un sistema operativo inmutable neutro respecto al proveedor con compatibilidad multi-nube.
• Use Azure Linux OS Guard (versión preliminar) si busca un sistema operativo inmutable listo para la empresa, recomendado por Microsoft.
• Use Ubuntu si busca un sistema operativo neutro respecto al proveedor, de propósito general y con compatibilidad entre nubes.
• Use Azure Linux si busca un sistema operativo de uso general listo para la empresa, recomendado por Microsoft.

Autorización de nodo

La autorización de nodo es un modo de autorización especial que autoriza específicamente las solicitudes de API de kubelet para proteger contra ataques Este-Oeste. La autorización de nodos está habilitada en clústeres de AKS 1.24 + de manera predeterminada.

Implementación de nodo

Los nodos se implementan en una subred de una red privada virtual, sin ninguna dirección IP pública asignada. Con fines de solución de problemas y administración, SSH está habilitado de manera predeterminada y solo es accesible mediante la dirección IP interna. La deshabilitación del SSH durante la creación de clústeres y grupos de nodos, o para un clúster o grupo de nodos existente, está en versión preliminar. Consulte Administración del acceso SSH para obtener más información.

Almacenamiento del nodo

Para proporcionar almacenamiento, los nodos usan Azure Managed Disks. Para la mayoría de los tamaños de nodo de máquina virtual, Azure Managed Disks son discos Premium respaldados por SSD de alto rendimiento. Los datos almacenados en discos administrados se cifran automáticamente en reposo dentro de la plataforma Azure. Para mejorar la redundancia, Azure Managed Disks se replican de forma segura en el centro de datos de Azure.

Cargas de trabajo multiinquilino hostiles

Actualmente, los entornos de Kubernetes no están completamente seguros ante el uso de varios inquilinos hostiles. Las características de seguridad adicionales, como las directivas de seguridad de pods o Kubernetes RBAC para 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. Para obtener más información sobre las formas de aislar las cargas de trabajo, consulte Procedimientos recomendados para el aislamiento de clústeres en AKS.

Aislamiento informático

Debido a los requisitos normativos o de cumplimiento, ciertas cargas de trabajo pueden requerir un alto grado de aislamiento de otras cargas de trabajo del cliente. Para estas cargas de trabajo, Azure proporciona:

• Contenedores aislados de kernel que se usarán como nodos de agente en un clúster de AKS. Estos contenedores están completamente aislados de un tipo de hardware específico y están aislados del tejido de host de Azure, el sistema operativo host y el hipervisor. Están dedicados a un solo cliente. Seleccione uno de los tamaños de VM aisladas como tamaño de nodo al crear un clúster de AKS o agregar un grupo de nodos.
• Confidential Containers (versión preliminar), también basado en Kata Confidential Containers, cifra la memoria del contenedor y evita que los datos en la memoria durante el cálculo estén en texto no cifrado, formato legible y manipulación. Ayuda a aislar tus contenedores de otros grupos de contenedores o pods, y del kernel del sistema operativo del nodo de la máquina virtual. Confidencial Containers (versión preliminar) usa el cifrado de memoria basado en hardware (SEV-SNP).
• Espacios aislados de pods (versión preliminar) proporciona un límite de aislamiento entre, por un lado, la aplicación contenedora y, por otro, el kernel compartido y los recursos de proceso (CPU, memoria y red) del host de contenedor.

Seguridad de red

Para la conectividad y la seguridad con redes locales, puede implementar el clúster de AKS en subredes de redes virtuales de Azure existentes. Estas redes virtuales se conectan de nuevo a la red local mediante Azure VPN de sitio a sitio o ExpressRoute. Defina controladores de entrada de Kubernetes con direcciones IP privadas internas para limitar el acceso de los servicios a la conexión de red interna.

Azure grupos de seguridad de red

Para filtrar el flujo de tráfico de red virtual, Azure usa reglas de grupo de seguridad de red. Estas reglas definen los intervalos, los puertos y los protocolos de IP de origen y destino que tienen permitido o denegado el acceso a los recursos. Se crean reglas predeterminadas para permitir el tráfico TLS al servidor de API de Kubernetes. Los servicios se crean con equilibradores de carga, asignaciones de puertos o rutas de entrada. AKS modifica automáticamente el grupo de seguridad de red para el flujo de tráfico.

Si proporciona su propia subred para el clúster de AKS (ya sea mediante Azure CNI o Kubenet), no modifique el grupo de seguridad de red a nivel de NIC administrado por AKS. En su lugar, cree más grupos de seguridad de red de nivel de subred para modificar el flujo de tráfico. Asegúrese de que no interfieren con el tráfico necesario para administrar el clúster, como el acceso al equilibrador de carga, la comunicación con el plano de control o la salida.

Directiva de red de Kubernetes

Para limitar el tráfico de red entre los pods del clúster, AKS ofrece compatibilidad con las directivas de red de Kubernetes. Con las directivas de red, puede permitir o denegar las rutas de acceso de red específicas en el clúster en función de los espacios de nombres y los selectores de etiquetas.

Seguridad de aplicaciones

Para proteger los pods que se ejecutan en AKS, considere la posibilidad de utilizar Microsoft Defender for Containers para detectar y restringir los ataques cibernéticos contra las aplicaciones que se ejecutan en los pods. Ejecute un escaneo continuo para detectar la deriva en el estado de vulnerabilidad de su aplicación e implemente un proceso "blue/green/canary" para corregir y reemplazar las imágenes vulnerables.

Proteger el acceso del contenedor a los recursos

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. Se recomiendan características de seguridad integradas de Linux, como AppArmor y seccomp , como procedimientos recomendados para proteger el acceso de contenedores a los recursos.

Secretos de Kubernetes

Con un secreto de Kubernetes, puede insertar datos confidenciales en pods, como credenciales de acceso o claves.

1. Cree un secreto mediante la API de Kubernetes.
2. Defina el pod o la implementación y solicite un secreto específico.
   • Los secretos solo se proporcionan a nodos con un pod programado que los requiera.
   • El secreto se almacena en tmpfs, no se escribe en el disco.
3. Cuando se elimina el último pod de un nodo que requiere un secreto, ese secreto se elimina del tmpfs del nodo.
   • Los secretos se almacenan en un espacio de nombres determinado y solo son accesibles desde los pods del mismo espacio de nombres.

El uso de secretos reduce la información confidencial definida en el pod o el manifiesto YAML del servicio. En su lugar, solicite el secreto almacenado en el servidor de API de Kubernetes como parte de su manifiesto YAML. Este enfoque proporciona acceso al secreto solo al pod específico.

Los secretos de Kubernetes se almacenan en etcd, un almacén distribuido de claves y valores. AKS permite cifrado en reposo de secretos en etcd mediante claves administradas por el cliente.

Pasos siguientes

Para empezar a proteger los clústeres de AKS, consulte Actualización de un clúster de Azure Kubernetes Service (AKS).

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.

Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte:

• Clústeres y cargas de trabajo de Kubernetes/AKS
• Identidad de Kubernetes/AKS
• Redes virtuales de Kubernetes/AKS
• Almacenamiento de Kubernetes/AKS
• Escala de Kubernetes/AKS