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. Por otra parte, Azure incluye componentes como Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, grupos de seguridad de red y actualizaciones de clústeres orquestadas. AKS combina estos componentes de seguridad para:

  • Proporcionar un caso completo de autenticación y autorización.
  • Utilizar 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 generar un error en una compilación porque tiene una vulnerabilidad, ya que eso interrumpirá el desarrollo. Se trata de observar el "Estado del proveedor" para segmentar en función de 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 detectará el desfase y también se detectarán 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 con un solo inquilino para proporcionar el servidor de API, Scheduler, etc.

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 más información, consulte el artículo de integración de Azure AD 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 una distribución Ubuntu optimizada con containerd o el entorno de ejecución del contenedor de Docker.
  • 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.

Nota

Clústeres de AKS que usan:

  • Kubernetes versión 1.19 y posteriores para que los grupos de nodos de Linux usen containerd como su entorno de ejecución de contenedores. El uso de containerd con grupos de nodos de Windows Server 2019 está actualmente en versión preliminar. Para más información, consulte Adición de un grupo de nodos de Windows Server con containerd.
  • Las versiones de Kubernetes anteriores a la 1.19 para grupos de nodos de Linux usan Docker como su entorno de ejecución de contenedores. En el caso de los grupos de nodos de Windows Server 2019, Docker es el entorno de ejecución de contenedores predeterminado.

Parches de seguridad de nodo

Nodos de Linux

Cada noche, los nodos Linux de AKS reciben las actualizaciones de seguridad a través de su canal de actualización de seguridad de distribución. 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.

Las actualizaciones nocturnas aplican actualizaciones de seguridad al sistema operativo en el nodo, pero la imagen de nodo que se usa para crear nodos para el clúster permanece sin cambios. 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 nodo de Azure Kubernetes Service (AKS).

Nodos de Windows Server

Para los nodos de Windows Server, Windows Update no ejecuta ni aplica las actualizaciones más recientes de manera automática. Programe las actualizaciones del grupo de nodos de Windows Server en el clúster de AKS según el ciclo de Windows Update normal y su propio proceso de validación. Este proceso de actualización crea nodos que ejecutan la imagen y las revisiones más recientes de Windows Server y elimina los nodos anteriores. Para obtener más información sobre este proceso, consulte Actualización de un grupo de nodos en AKS.

Autorización de nodo

La autorización de nodos es un modo de autorización especial, que autoriza de manera específica las solicitudes de la API que realiza kubelet para protegerse de los ataques horizontales de derecha a izquierda. 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.

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 VM aisladas para usarse como nodos de agente en un clúster de AKS. Estas VM están aisladas en un tipo de hardware específico y están dedicadas 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.

Actualizaciones de clústeres

Azure proporciona herramientas de orquestación de actualizaciones para actualizar un clúster de AKS y sus componentes, mantener la seguridad y el cumplimiento y acceder a las características más recientes. La orquestación de esta actualización incluye los componentes tanto de maestro como de agente de Kubernetes.

Para iniciar el proceso de actualización, especifique una de las versiones de Kubernetes disponibles de la lista. A continuación, Azure acordona y purga de manera segura cada uno de los nodos de AKS y los actualiza.

Acordonar y purgar

Durante el proceso de actualización, los nodos de AKS se acordonan de manera individual desde el clúster para evitar que se programen nuevos pods en ellos. A continuación, los nodos se purgan y actualizan de la siguiente manera:

  1. Se implementa un nuevo nodo en el grupo de nodos.
    • Este nodo ejecuta la imagen de sistema operativo y las revisiones más recientes.
  2. Se identifica uno de los nodos existentes para la actualización.
  3. Los pods del nodo identificado finalizan correctamente y se programan en los otros nodos del grupo.
  4. El nodo vacío se elimina del clúster de AKS.
  5. Los pasos del 1 al 4 se repiten hasta que todos los nodos se reemplazan correctamente como parte del proceso de actualización.

Para más información, consulte Actualización de un clúster de Azure Kubernetes Service (AKS).

Seguridad de las redes

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 interfieran 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 y 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, utilice 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, dicho secreto se elimina del tmpfs del nodo.
    • Los secretos se almacenan en un espacio de nombres determinado y solo son accesibles para 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.

Nota

Los archivos de manifiesto de secreto sin formato contienen los datos secretos en formato base64 (consulte la documentación oficial para más detalles). Trate estos archivos como información confidencial y no los confirme nunca en el control de código fuente.

Los secretos de Kubernetes se almacenan en etcd, un almacén distribuido de pares clave-valor. El almacén etcd está totalmente administrado por AKS y los datos se cifran en reposo dentro de la plataforma de 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: