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

La seguridad de los contenedores protege toda la canalización de un extremo a otro, 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.
• Aplicar el servicio Azure Policy integrado en AKS para proteger las aplicaciones.
• Obtener información completa de la compilación mediante 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 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 regular el acceso al servidor de API mediante control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) y RBAC de Azure. Para obtener más información, consulte Integración de Microsoft Entra con AKS.

Seguridad de nodos

Los nodos de AKS son máquinas virtuales (VM) de Azure que el usuario administra y mantiene.

• Los nodos de Linux ejecutan versiones optimizadas de Ubuntu o Azure Linux.
• Los nodos de Windows Server ejecutan una versión de Windows Server 2019 optimizada con containerd o el entorno de ejecución del contenedor de Docker.

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 más información sobre el proceso de actualización de seguridad para los 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 segunda generación de Azure incluyen compatibilidad con inicio seguro (versión preliminar), que protege contra técnicas de ataque avanzadas y persistentes combinando tecnologías que se pueden habilitar de forma independiente, como el arranque seguro y la 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.

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, las instancias de 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, las instancias de 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 de proceso

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 para 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 los contenedores de otros grupos o pods de contenedor, así como 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

Por motivos de conectividad y seguridad con las redes locales, puede implementar el clúster de AKS en subredes de red virtual de Azure existentes. Estas redes virtuales se conectan de vuelta a su red local con una VPN de sitio a sitio o ExpressRoute de Azure. 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.

Grupos de seguridad de red de Azure

Para filtrar el flujo del 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 (tanto si usa Azure CNI como Kubernetes), no modifique el grupo de seguridad de red de nivel de subred 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 usar Microsoft Defender for Containers para detectar y restringir los ciberataques contra las aplicaciones que se ejecutan en los pods. Ejecute un examen continuo para detectar el desfase en el estado de vulnerabilidad de la aplicación e implemente un proceso "azul/verde/valor controlado" para aplicar revisiones y reemplazar las imágenes vulnerables.

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 administra por completo el almacén etcd y los datos se cifran en reposo dentro de la plataforma Azure.

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