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 Microsoft Entra ID, 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 la directiva integrada de Azure Policy para AKS para proteger sus 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.

AKS admite dos modos de clúster: AKS Automatic y AKS Standard. Los conceptos de seguridad de este artículo se aplican a ambos modos a menos que se indique lo contrario. AKS Automatic incluye una línea base de seguridad protegida con varios controles preconfigurados de forma predeterminada, mientras que AKS Standard proporciona más flexibilidad de configuración.

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

Construir seguridad

La seguridad en la compilación es la puerta de entrada a su cadena de suministro segura. Antes de promover imágenes a entornos de implementación, ejecute análisis estáticos y evaluación de vulnerabilidades y cumplimiento en CI.

En ambos modos de AKS, use el triaje basado en riesgos en lugar de bloquear todas las compilaciones por cualquier vulnerabilidad. Priorice la corrección mediante el estado y la gravedad del proveedor y aplique períodos de gracia para excepciones no aprovechables o limitadas por tiempo.

AKS Automatic ayuda a reducir la deriva de configuración en fases posteriores al iniciar los clústeres a partir de una línea base reforzada con controles de seguridad preconfigurados. Esto hace que la validación en tiempo de compilación de la calidad de la imagen y del cumplimiento de directivas sea aún más importante, porque las imágenes fiables se incorporan de manera más sistemática a una base de referencia segura de ejecución.

AKS Standard proporciona más flexibilidad en el nivel de clúster, por lo que las canalizaciones de compilación deben aplicar explícitamente la base de referencia de su organización para la procedencia de las imágenes, los umbrales de vulnerabilidad y los controles de directiva antes de la implementación.

Seguridad del Registro

La seguridad del Registro comprueba que solo hay imágenes de confianza y compatibles disponibles para la implementación y ayuda a detectar el desfase después de la compilación. Evalúe el estado de vulnerabilidad de la imagen en el registro continuamente, no solo en tiempo de compilación. El examen del Registro detecta vulnerabilidades e imágenes recién divulgadas que omiten las rutas de compilación aprobadas. Use la firma y comprobación de imágenes, como Notary V2, para asegurarse de que las cargas de trabajo se implementan desde orígenes de confianza con la procedencia verificable.

Para AKS Automatic, donde varias funcionalidades de seguridad en tiempo de ejecución están preconfiguradas, los controles del Registro siguen siendo una puerta ascendente crítica para mantener la cadena de suministro en tiempo de ejecución limpia. Para AKS Standard, aplique los mismos controles del registro y alinéalos con la configuración de admisión y directivas del clúster para exigir de forma coherente el uso de imágenes de confianza.

Seguridad de clúster

En AKS, los componentes principales de Kubernetes forman parte del servicio administrado proporcionado, administrado y mantenido por Microsoft. Cada clúster de AKS tiene su propia instancia de Kubernetes principal dedicada y de un solo inquilino para proporcionar el servidor de API, scheduler, 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.

Para AKS Automatic, la integración de red virtual del servidor de API está preconfigurada como parte de la posición de seguridad predeterminada. En AKS Standard, la misma funcionalidad está disponible y se puede habilitar en función del diseño de red y los requisitos de seguridad.

Puede controlar el acceso al servidor de API mediante el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) y Azure RBAC. En AKS Automatic, Azure RBAC para la autorización de Kubernetes está preconfigurado. En AKS Standard, puede elegir y configurar el modelo de autorización que mejor se adapte a su entorno. Para obtener más información, consulte Microsoft Entra integración con AKS.

Valores predeterminados de seguridad automática de AKS

AKS Automatic incluye una línea base protegida con controles de seguridad preconfigurados de forma predeterminada, entre los que se incluyen:

• Azure RBAC para la autorización de Kubernetes
• Integración de red virtual del servidor de API
• Identidad de carga de trabajo y emisor de OIDC
• Medidas de seguridad de implementación y estándares de seguridad de pod de línea base en modo de aplicación
• Limpiador de imágenes para quitar imágenes vulnerables sin usar
• Restricciones de seguridad del grupo de nodos del sistema administrado que conservan los límites entre las cargas de trabajo del cliente y la infraestructura administrada por AKS

AKS Standard admite estas funcionalidades con mayor flexibilidad de implementación, pero podrían requerir habilitación explícita y administración operativa.

Seguridad de nodos

Los nodos de AKS son máquinas virtuales de Azure (VM). En AKS Standard, se administran las opciones de configuración y ciclo de vida del grupo de nodos. En AKS Automatic, AKS administra los grupos de nodos del sistema y los componentes principales del sistema en su nombre, incluido el escalado y las actualizaciones, con restricciones de seguridad para la infraestructura del sistema administrada.

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

Azure Container Linux (ACL) es un sistema operativo inmutable y optimizado para contenedores para AKS. ACL deriva del proyecto Flatcar Container Linux y se basa en el diseño inmutable de Flatcar, centrado en contenedores y sobradamente probado, a la vez que incorpora paquetes, servicio e integración con la plataforma de Azure Linux. Esto permite que la ACL permanezca estrechamente alineada con la innovación ascendente de Flatcar, al tiempo que cumple los requisitos de producción, seguridad y cumplimiento de Azure. Para más información sobre Flatcar Container Linux, consulte la documentación de Flatcar.

La ACL está disponible con carácter general (GA) como opción de sistema operativo en AKS a partir de AKS v1.34. Puede implementar grupos de nodos de ACL en un nuevo clúster de AKS, agregar grupos de nodos de ACL a los clústeres existentes y migrar grupos de nodos de Linux existentes a ACL.

Para obtener más información sobre la ACL, consulte Azure Container Linux (ACL) para información general sobre AKS.

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.

En AKS Automatic, las funcionalidades de red virtual administrada y los valores predeterminados de entrada y salida principales están preconfigurados para proporcionar una línea base segura. En AKS Standard, los modelos de red y los controles de salida/entrada son más flexibles y deben seleccionarse en función de la arquitectura de seguridad.

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 la aplicación

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.

En AKS Automatic, la identidad de carga de trabajo y el emisor de OIDC están preconfigurados para simplificar el acceso seguro a las cargas de trabajo a los servicios de Azure. En AKS Standard, estas funcionalidades están disponibles y se pueden habilitar como parte de la posición de seguridad de línea base.

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.

Contenido relacionado

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

Si está evaluando los valores predeterminados específicos del modo y las responsabilidades operativas, consulte ¿Qué es Azure Kubernetes Service (AKS) automático?

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