Seguridad para AKS

Este artículo le guía por los aspectos de la gobernanza de seguridad de Azure Kubernetes Service (AKS) que se deben tener en cuenta antes de implementar cualquier solución.

El artículo se centra en cómo implementar soluciones mediante Azure y software de código abierto. Las decisiones que tome al crear una zona de aterrizaje a escala empresarial pueden predefinir parcialmente la gobernanza. Para comprender los principios de gobernanza, consulte Gobernanza y cumplimiento de la seguridad a escala empresarial.

Superficies expuestas a ataques

Tenga en cuenta las cinco superficies de ataque siguientes al crear una estrategia de seguridad para clústeres de Kubernetes:

• Construir
• Registro
• Clúster
• Nodo
• Aplicación

Para cada categoría, analizamos los principales riesgos que se deben tener en cuenta y contramedidas para esos riesgos.

Construir seguridad

La seguridad de compilación trata sobre el uso adecuado de DevSecOps con imágenes de contenedor.

Principales riesgos

Una configuración de imagen deficiente puede provocar vulnerabilidades de seguridad en la canalización. Por ejemplo, es posible que tenga contenedores que se ejecuten con privilegios mayores de los que necesitan. Los contenedores también se pueden configurar para permitir cierto acceso a la red, lo que podría poner en riesgo el sistema. No limitar las llamadas del sistema permitidas a esas llamadas necesarias para el funcionamiento seguro de los contenedores puede aumentar el riesgo de un contenedor en peligro.

Otra vulnerabilidad podría permitir que el contenedor obtenga acceso a un directorio confidencial del host o permitir que los contenedores cambien las ubicaciones que controlan la función básica del host.

Los contenedores no autorizados son contenedores no planeados en un entorno. Pueden ser el resultado de que los desarrolladores prueben su código en entornos de prueba. Es posible que estos contenedores no hayan pasado por un análisis riguroso de vulnerabilidades o estén configurados correctamente. Estas vulnerabilidades pueden abrir un punto de entrada para los atacantes.

El uso de imágenes base que no proceden de orígenes de confianza o que no están actualizadas con las actualizaciones de seguridad también puede provocar vulnerabilidades en los contenedores que usan para compilar.

Contramedidas de riesgo

La seguridad de la compilación consiste en la implementación de DevSecOps para desplazar la seguridad a un momento anterior y corregir la mayoría de los problemas antes de que avancen a la canalización. No se trata de atribuir toda la responsabilidad a los desarrolladores, sino de compartirla con el equipo de operaciones. A continuación, los desarrolladores pueden ver y corregir vulnerabilidades y problemas de cumplimiento que realmente pueden solucionar.

Puede crear una canalización que examine y no realice compilaciones porque tiene una o diez vulnerabilidades críticas. Un mejor enfoque podría ser examinar la siguiente capa hacia abajo. Puede empezar a segmentar el punto de responsabilidad en función del estado del proveedor.

Establezca un umbral en la capa de estado de la vulnerabilidad. Todo lo que tenga el estado Abierto, No se corregirá o Aplazado sigue fluyendo por la canalización donde las operaciones de seguridad pueden acceder al riesgo, como lo hacen actualmente. Una vulnerabilidad con el estado de Correcciones del proveedor disponibles es algo que un desarrollador puede solucionar. El uso de períodos de gracia permite a los desarrolladores corregir las vulnerabilidades.

Junto con la evaluación de vulnerabilidades es la evaluación de cumplimiento. Por ejemplo, permitir que una imagen se ejecute con privilegios de root o exponer SSH compromete la postura de cumplimiento de la mayoría de las empresas. Solucione este problema durante la compilación en lugar de durante la implementación.

Por lo general, se examinan las imágenes con el punto de referencia Docker CIS. Al usar estos tipos de flujos, no interrumpirá el desarrollo aplicando remediaciones de seguridad, sino que puede mejorar integralmente la postura de seguridad general de la empresa.

El uso de una herramienta que permite estas funcionalidades es fundamental para implementar eficazmente la estrategia adecuada para su empresa. Las herramientas tradicionales a menudo no pueden detectar vulnerabilidades dentro de los contenedores, lo que puede provocar una falsa sensación de seguridad. Se necesitan herramientas que tomen en cuenta el enfoque de compilación basado en la canalización y la naturaleza inmutable y declarativa de las tecnologías de contenedor para proteger correctamente el ecosistema de contenedores.

Estas herramientas deben tener las siguientes propiedades:

• Integración con todo el ciclo de vida de las imágenes, desde el principio del proceso de compilación hasta el registro y el tiempo de ejecución.
• Visibilidad de las vulnerabilidades en todas las capas de la imagen, incluida la capa base de la imagen, los marcos de trabajo de aplicaciones y el software personalizado.
• Aplicación controlada por directivas con el nivel correcto de granularidad, lo que permite a la organización crear puertas de calidad en cada fase de los procesos de compilación e implementación.

Seguridad del Registro

La seguridad del Registro trata de:

• Control de desfase desde la compilación.
• Prevención de inserción/extracción de imágenes contaminadas.
• Firma de imágenes.

Principales riesgos

Las imágenes suelen contener información propietaria, incluido el código fuente de una organización. Si las conexiones a registros no son adecuadamente seguras, el contenido de una imagen podría suponer riesgos de confidencialidad tan graves como cualquier otra forma de datos transmitidos dentro de la organización. Las imágenes obsoletas con versiones obsoletas vulnerables en el registro pueden aumentar los riesgos de seguridad si se implementan accidentalmente.

Otra vulnerabilidad de seguridad podría incluir restricciones de autenticación y autorización insuficientes para los registros de contenedor. Estos registros pueden alojar activos propietarios confidenciales en las imágenes.

A medida que el contenido se compila e implementa, la distribución de este contenido es uno de los muchos vectores de ataque. ¿Cómo se asegura de que el contenido almacenado provisionalmente para la distribución sea el mismo contenido que se entrega a un punto de conexión previsto?

Contramedidas de riesgo

Configure los procesos de implementación para asegurarse de que las herramientas de desarrollo, las redes y los entornos de ejecución de contenedor están conectados a registros solo a través de canales cifrados. Además, asegúrese de que el contenido procede de un origen de confianza. Para reducir los riesgos del uso de imágenes obsoletas:

• Quite las imágenes no seguras y vulnerables que ya no se deben usar de los registros de contenedor.
• Exigir el acceso a imágenes mediante nombres inmutables que especifican versiones concretas de imágenes que se van a usar. Puede implementar esta configuración mediante una etiqueta más reciente o una versión específica de las imágenes. Una etiqueta no garantiza la frescura. Debido a esto, se debe poner en marcha un proceso para asegurarse de que el orquestador de Kubernetes usa los números únicos más recientes o que la etiqueta más reciente representa las versiones más actualizadas.

El acceso a los registros que contienen imágenes confidenciales debe requerir autenticación y autorización. Todo acceso de escritura también debe requerir autenticación. Por ejemplo, la directiva podría permitir que los desarrolladores solo inserten imágenes en los repositorios específicos para los que son responsables.

El acceso a estos registros debe estar federado y aprovechar las políticas de acceso al nivel del área de negocio. Por ejemplo, puede configurar su canalización de CI/CD para que las imágenes se inserten en los repositorios solo después de haber superado las pruebas de control de calidad y evaluación de cumplimiento del examen de vulnerabilidades.

Los registros de contenedor ahora considerados registros de artefactos se están convirtiendo en un medio principal para implementar cualquier tipo de contenido, no solo imágenes de contenedor. Cada nube proporciona un registro con proyectos de código abierto y productos de proveedor que están disponibles para el hospedaje local o privado dentro de proveedores de nube. El contenido se promueve dentro y entre registros de su compilación inicial a su implementación de producción.

¿Cómo puede asegurarse de que la integridad del contenido que entró en el registro es el mismo contenido que sale del registro? La adopción de una solución de firma de imágenes garantiza que las implementaciones solo proceden de registros de confianza e implementan contenido de confianza.

Seguridad de clúster

La seguridad del clúster consiste en:

• Autenticación y autorización.
• Seguridad de red.
• Administración de vulnerabilidades y cumplimiento.

Principales riesgos

A veces, un único clúster de Kubernetes se puede usar para ejecutar diferentes aplicaciones administradas por distintos equipos con requisitos de nivel de acceso diferentes. Si se proporciona acceso a usuarios sin restricciones o solo según sus necesidades, un usuario malintencionado o descuidado podría comprometer las cargas de trabajo a las que tiene acceso y otros recursos del clúster.

Otra vulnerabilidad de seguridad puede producirse cuando el directorio de usuario propio del clúster administra la autorización y la autenticación. A menudo, un directorio de autenticación de la organización se controla más rigurosamente. Dado que estas cuentas son altamente privilegiadas y, con mayor frecuencia, quedan huérfanas, aumentan las posibilidades de que una cuenta se comprometa.

Este escenario podría provocar vulnerabilidades de clúster o incluso de todo el sistema. Los orquestadores administran los datos almacenados por volúmenes de contenedor, que deben tener acceso a los datos independientemente del nodo en el que se hospede.

Los filtros de red tradicionales pueden tener una ceguera de seguridad debido a una capa de red diseñada para cifrar los datos en tránsito. Este diseño dificulta la supervisión del tráfico dentro del clúster, por lo que es posible que se requieran disposiciones especiales para supervisar los clústeres de Kubernetes.

El tráfico de diferentes aplicaciones que comparten el mismo clúster puede tener distintos niveles de confidencialidad, como un sitio web orientado al público y una aplicación interna que ejecuta procesos empresariales críticos confidenciales. Compartir la misma red virtual dentro del clúster puede dar lugar a datos confidenciales en peligro. Por ejemplo, un atacante podría usar la red compartida expuesta a Internet para atacar las aplicaciones internas.

Proteja los componentes que ejecutan el propio clúster frente a vulnerabilidades y problemas de cumplimiento. Asegúrese de que se está ejecutando en la versión más reciente posible de Kubernetes para aprovechar las ventajas de la corrección.

Contramedidas de riesgo

El acceso de usuario del clúster de Kubernetes debe usar un modelo de acceso con privilegios mínimos. Conceda solo a los usuarios acceso para realizar acciones específicas en hosts, contenedores e imágenes específicos necesarios para que realicen sus trabajos. Los miembros del equipo de prueba deben tener acceso limitado o no a los contenedores en producción. Las cuentas de usuario con acceso a todo el clúster deben controlarse estrechamente y usarse con moderación.

Use métodos de autenticación seguros, como la autenticación multifactor, para proteger el acceso a estas cuentas. Se debe usar un directorio de usuarios de la organización para administrar clústeres a través del inicio de sesión único en lugar de las cuentas de usuario específicas del clúster que podrían no tener el mismo nivel de directivas y controles.

Use métodos de cifrado que permitan a los contenedores acceder adecuadamente a los datos, independientemente del host en el que se ejecuten. Estas herramientas de cifrado deben impedir el acceso no autorizado a los datos por parte de otros contenedores incluso dentro del mismo nodo que no debería tener acceso a ellos.

Configure clústeres de Kubernetes para separar el tráfico de red en redes virtuales discretas o subredes por nivel de confidencialidad. La segmentación por aplicación también puede ser posible, pero la definición de redes por niveles de confidencialidad podría ser suficiente. Por ejemplo, las redes virtuales para las aplicaciones orientadas al cliente separadas de las que sirven aplicaciones internas con tráfico confidencial deben implementarse como mínimo.

Puede usar las tolerancias e intolerancias para aislar las implementaciones en conjuntos específicos de nodos por niveles de confidencialidad. Evite hospedar cargas de trabajo altamente confidenciales en el mismo nodo que esas cargas de trabajo con menos sensibilidades. El uso de clústeres administrados independientes es una opción más segura.

Segmente los contenedores por propósito, confidencialidad y posición de subproceso para proporcionar protección adicional para cargas de trabajo confidenciales. Al segmentar contenedores de esta manera, es más difícil que un atacante que haya obtenido acceso a un segmento obtenga acceso a otros segmentos. Esta configuración tiene la ventaja adicional de garantizar que los datos residuales, como las memorias caché o los montajes de volumen, estén aislados por nivel de sensibilidad.

Los clústeres de Kubernetes deben configurarse para:

• Proporcione un entorno seguro para las aplicaciones que se ejecutan en ellas.
• Asegúrese de que los nodos se agregan de forma segura al clúster.
• Tener identidades persistentes para ayudar a garantizar la seguridad a lo largo de su ciclo de vida.
• Proporcione información activa y precisa sobre el estado del clúster, incluidas las redes y los nodos que contiene.

Debe ser fácil aislar y eliminar un nodo comprometido del clúster sin afectar el rendimiento del clúster. AKS hace que sea tan sencillo.

Defina los estándares de configuración del entorno de ejecución del contenedor para garantizar automáticamente el cumplimiento. Hay muchas directivas en Azure que facilitan este proceso y los usuarios también pueden crear sus propias directivas. Use las características de seguridad de Azure para evaluar continuamente las opciones de configuración en todo el entorno y aplicarlas activamente.

Asegúrese automáticamente de que se abordan las vulnerabilidades de los componentes de Kubernetes. Use entornos independientes para el desarrollo, la prueba y la producción, cada uno con sus propios controles y el control de acceso basado en rol (RBAC) para la administración de contenedores. Asocie toda la creación de contenedores a identidades de usuario individuales y regístrela para la auditoría. Esta configuración ayuda a reducir el riesgo de contenedores no autorizados.

Seguridad de nodos

La seguridad del nodo consiste en:

• Protección en tiempo de ejecución.
• Administración de vulnerabilidades y cumplimiento.

Principales riesgos

Un nodo de trabajo tiene acceso con privilegios a todos los componentes del nodo. Los atacantes pueden usar cualquier servicio accesible desde la red como punto de entrada, por lo que proporcionar acceso al host desde varios puntos puede aumentar seriamente su superficie expuesta a ataques. Cuanto mayor sea la superficie expuesta a ataques, más posibilidades de que un atacante obtenga acceso al nodo y a su sistema operativo.

Además, los sistemas operativos específicos del contenedor, como los que se usan en los nodos de AKS, tienen una superficie de ataque más pequeña porque no contienen bibliotecas que permiten que los sistemas operativos normales ejecuten directamente bases de datos y servidores web. El uso de un kernel compartido da como resultado una superficie de ataque mayor para los contenedores que se ejecutan en el mismo entorno que los contenedores en máquinas virtuales independientes. Este es el caso incluso cuando los sistemas operativos específicos del contenedor que se ejecutan en nodos de AKS están en uso.

Los sistemas operativos host proporcionan componentes fundamentales del sistema que pueden tener vulnerabilidades y riesgos de cumplimiento. Dado que son componentes de bajo nivel, sus vulnerabilidades y configuración pueden afectar a todos los contenedores que se hospedan. AKS protege a los usuarios asegurándose de que estas vulnerabilidades se gestionan a través de actualizaciones regulares del sistema operativo en los nodos que se ejecutan en AKS, y se mantiene la postura de cumplimiento del nodo de trabajo.

Los derechos de acceso de usuario incorrectos también pueden provocar riesgos de seguridad cuando los usuarios inician sesión directamente en los nodos para administrar los contenedores en lugar de a través del plano de control de AKS. Iniciar sesión directamente puede permitir al usuario realizar cambios en las aplicaciones más allá de las que deben tener acceso.

Además, los contenedores malintencionados pueden provocar alteraciones del sistema de archivos del sistema operativo host. Por ejemplo, si un contenedor puede montar un directorio confidencial en el sistema operativo host, ese contenedor podría realizar cambios en los archivos. Los cambios podrían afectar a la seguridad de otros contenedores que se ejecutan en el host.

Contramedidas de riesgo

Restrinja el acceso al nodo limitando el acceso SSH.

El uso del sistema operativo específico del contenedor en los nodos de AKS normalmente reduce las superficies de ataque porque otros servicios y funcionalidades están deshabilitados. También tienen sistemas de archivos de solo lectura y emplean otros procedimientos de protección de clústeres de forma predeterminada.

La plataforma Azure aplica automáticamente las revisiones de seguridad del sistema operativo a los nodos de Linux y Windows de forma nocturna. Si una actualización de seguridad del sistema operativo Linux requiere un reinicio del host, no se reiniciará automáticamente. AKS proporciona mecanismos para reiniciar para aplicar esas revisiones específicas.

Microsoft Defender para servidores no es aplicable a los nodos de WINDOWS y Linux de AKS porque Microsoft administra su sistema operativo. Si ninguna otra máquina virtual está en la suscripción donde se implementa AKS, puede deshabilitar microsoft Defender para servidores de forma segura.

Si se ha implementado el entorno, incluidas las directivas de Azure recomendadas para zona de aterrizaje de escala empresarial, puede configurar una exclusión para la asignación de directivas en el grupo de administración que habilita automáticamente Microsoft Defender para servidores, con el fin de evitar costos innecesarios.

Seguridad de la aplicación

La seguridad de la aplicación trata de:

• Protección en tiempo de ejecución.
• Administración de vulnerabilidades y cumplimiento.

Principales riesgos

Las imágenes son archivos que incluyen todos los componentes necesarios para ejecutar una aplicación. Cuando se usan las versiones más recientes de estos componentes para crear imágenes, podrían estar libres de vulnerabilidades conocidas en el momento, pero pueden cambiar rápidamente.

Debe mantener estos archivos actualizados con las versiones más recientes, ya que los desarrolladores de paquetes identifican periódicamente las vulnerabilidades de seguridad. Realice las actualizaciones de contenedores en un nivel superior mediante la actualización de las imágenes que se usan para crear los contenedores, a diferencia de las aplicaciones tradicionales, que normalmente se actualizan en el host.

Los archivos malintencionados también se pueden incrustar en una imagen, que luego se pueden usar para atacar otros contenedores o componentes del sistema. Los contenedores de terceros pueden ser un posible vector de ataque. Es posible que no se conozcan detalles específicos sobre ellos y podrían filtrar datos. Quizás los contenedores no se hayan actualizado con las actualizaciones de seguridad necesarias.

Otro vector de ataque es el uso de secretos de inserción, como contraseñas y cadenas de conexión directamente dentro de un sistema de archivos de imagen. Esta práctica puede provocar un riesgo de seguridad porque cualquier persona con acceso a la imagen puede obtener acceso a los secretos.

Puede haber errores en las propias aplicaciones, como las aplicaciones que son vulnerables al scripting entre sitios o la inyección de CÓDIGO SQL. Cuando existen errores, es posible que la vulnerabilidad se use para habilitar el acceso no autorizado a información confidencial dentro de otros contenedores o incluso el sistema operativo host.

El entorno de ejecución del contenedor de AKS facilita la supervisión de vulnerabilidades mediante las distintas herramientas de seguridad disponibles en Azure. Para obtener más información, consulte Introducción a Microsoft Defender para Kubernetes.

También debe controlar el tráfico de red de salida enviado a contenedores para asegurarse de que los contenedores no puedan enviar tráfico entre redes de diferentes niveles de confidencialidad, como entornos que hospedan datos seguros o a Internet. Azure facilita este control con sus diversas características de seguridad de red y AKS.

De forma predeterminada, los programadores de Kubernetes se centran en impulsar la escala y maximizar la densidad de las cargas de trabajo que se ejecutan en los nodos. Pueden colocar pods de diferentes niveles de sensibilidad en el mismo nodo solo porque ese host tiene los recursos más disponibles. Este escenario puede provocar incidentes de seguridad cuando los atacantes usan el acceso a cargas de trabajo orientadas al público para atacar contenedores que ejecutan procesos más confidenciales en el mismo host. Un contenedor en peligro también se puede usar para examinar la red para encontrar otras vulnerabilidades que el atacante pueda aprovechar.

Contramedidas de riesgo

Nunca almacene secretos en sistemas de archivos o código de aplicación. Los secretos deben almacenarse en almacenes de claves y proporcionarse a los contenedores en tiempo de ejecución cuando sea necesario. AKS puede asegurarse de que solo los contenedores que necesitan acceso a determinadas claves tienen acceso a ellos y que estos secretos no se conservan en el disco. Por ejemplo, Azure Key Vault puede almacenar estos secretos de forma segura y proporcionarlos al clúster de AKS según sea necesario. También es sencillo asegurarse de que estos secretos se cifran tanto en almacenamiento como en tránsito.

Evite el uso de imágenes y registros que no son de confianza y asegúrese de que solo se permiten ejecutar imágenes de conjuntos de confianza en sus clústeres. Para un enfoque multicapa:

• Controlar de forma centralizada exactamente qué imágenes y registros son de confianza.
• Identifique discretamente cada imagen mediante firma criptográfica.
• Coloque directivas en vigor que aseguren que todos los hosts solo ejecuten imágenes que proceden del conjunto aprobado.
• Valide estas firmas antes de la ejecución.
• Supervise y actualice estas imágenes y registros a medida que cambian las vulnerabilidades y los requisitos de configuración.

Los perfiles de computación seguros deben usarse para restringir los contenedores y asignarse en tiempo de ejecución. Los perfiles personalizados se pueden crear y pasar a los entornos de ejecución de contenedor para limitar aún más sus funcionalidades. Como mínimo, asegúrese de que los contenedores se ejecutan con los perfiles predeterminados. Considere la posibilidad de usar perfiles personalizados y más restringidos para contenedores que ejecutan aplicaciones de alto riesgo.

Las herramientas pueden generar perfiles automáticamente de aplicaciones mediante el aprendizaje del comportamiento y detectar anomalías. Puede usar soluciones de terceros para detectar anomalías en tiempo de ejecución. Las anomalías pueden incluir eventos como:

• Ejecución de procesos o llamadas del sistema no válidas o inesperadas.
• Cambios en archivos de configuración protegidos y archivos binarios.
• Escribe en ubicaciones y tipos de archivo inesperados.
• Creación de agentes de escucha de red inesperados.
• Tráfico enviado a destinos de red inesperados.
• Almacenamiento y ejecución de malware.

Microsoft Defender para Kubernetes está invirtiendo actualmente en esta área.

Los contenedores deben ejecutarse con su sistema de archivos raíz en modo de solo lectura para aislar las escrituras en directorios definidos, que esas herramientas pueden supervisar fácilmente. Esta configuración hace que los contenedores sean más resistentes a los riesgos porque se aísla la manipulación en estas ubicaciones específicas. Se pueden separar fácilmente del resto de la aplicación.

Consideraciones de diseño

AKS tiene varias interfaces para otros servicios de Azure, como Microsoft Entra ID, Azure Storage y Azure Virtual Network. El uso de estos servicios requiere especial atención durante la fase de planificación. AKS también agrega complejidad adicional que requiere que considere la posibilidad de aplicar los mismos mecanismos y controles de cumplimiento y gobernanza de seguridad que en el resto del panorama de la infraestructura.

Estas son otras consideraciones de diseño para la gobernanza y el cumplimiento de la seguridad de AKS:

• Si crea un clúster de AKS en una suscripción implementada según las prácticas recomendadas para zonas de aterrizaje a escala empresarial, familiarícese con las políticas de Azure que heredarán los clústeres. Para más información, consulte Directivas incluidas en implementaciones de referencia de zonas de aterrizaje de Azure.
• Decida si el plano de control del clúster debe ser accesible a través de Internet (se recomiendan restricciones de IP), que es el valor predeterminado o solo desde dentro de la red privada en Azure o en el entorno local como un clúster privado. Si su organización sigue los procedimientos recomendados para zonas de aterrizaje a escala empresarial, el grupo de administración Corp tiene una política de Azure asociada que obliga a que los clústeres sean privados. Para más información, consulte Directivas incluidas en implementaciones de referencia de zonas de aterrizaje de Azure.
• Evalúe el uso del módulo de seguridad integrado de AppArmor Linux para limitar las acciones que pueden realizar los contenedores, como las funciones de lectura, escritura, ejecución o sistema, como el montaje de sistemas de archivos. Por ejemplo, todas las suscripciones tienen directivas de Azure que impiden que los pods de todos los clústeres de AKS creen contenedores con privilegios. Para más información, consulte Directivas incluidas en implementaciones de referencia de zonas de aterrizaje de Azure.
• Evalúe el uso seccomp de (informática segura) en el nivel de proceso para limitar las llamadas de proceso que pueden realizar los contenedores. Por ejemplo, el Azure Policy aplicado como parte de la implementación genérica de la zona de aterrizaje de escala empresarial en el grupo de administración de zonas de aterrizaje para evitar el escalado de privilegios de contenedor a la raíz usa seccomp a través de directivas de Azure para Kubernetes.
• Decida si el registro de contenedor es accesible a través de Internet o solo dentro de una red virtual específica. Deshabilitar el acceso a Internet en un registro de contenedor puede tener efectos negativos en otros sistemas que dependen de la conectividad pública para acceder a él. Algunos ejemplos son las canalizaciones de integración continua o Microsoft Defender para el examen de imágenes. Para más información, consulte Conexión privada a un registro de contenedor mediante Azure Private Link.
• Decida si el registro de contenedor privado se comparte entre varias zonas de aterrizaje o si implementa un registro de contenedor dedicado en cada suscripción de zona de aterrizaje.
• Considere la posibilidad de usar una solución de seguridad como Microsoft Defender para Kubernetes para la detección de amenazas.
• Considere la posibilidad de examinar las imágenes de contenedor para detectar vulnerabilidades.
• Considere la posibilidad de deshabilitar Microsoft Defender para servidores en la suscripción de AKS si no hay ninguna máquina virtual de AKS, para evitar costos innecesarios.

Recomendaciones de diseño

• Limite el acceso al archivo de configuración del clúster de Kubernetes mediante RBAC de Azure.
• Proteja el acceso del pod a los recursos. Proporcione el menor número de permisos y evite el uso de acceso root o la escalada de privilegios.
• Use Id. de carga de trabajo de Microsoft Entra con AKS y el Proveedor de Azure Key Vault para el controlador Secrets Store CSI para proteger secretos, certificados y cadenas de conexión.
• Use la actualización de la imagen de nodo de AKS para actualizar las imágenes de nodo del clúster de AKS si es posible, o kured para automatizar los reinicios del nodo después de aplicar las actualizaciones.
• Supervise y aplique la configuración mediante el complemento Azure Policy para Kubernetes. En las suscripciones implementadas según los procedimientos recomendados de zonas de aterrizaje a escala empresarial, esta configuración se realiza automáticamente a través de una instancia de Azure Policy implementada en el nivel de grupo de administración.
• Vea las recomendaciones de AKS en Microsoft Defender for Cloud.
• Use Microsoft Defender para contenedores, la solución nativa de la nube para mejorar, supervisar y mantener la seguridad de los clústeres, contenedores y sus aplicaciones.
• Implemente una instancia dedicada y privada de Azure Container Registry en cada suscripción de zona de aterrizaje.
• Usa Enlace Privado para el Registro de Contenedores para conectarlo a AKS.
• Examine las imágenes para detectar vulnerabilidades con la administración de vulnerabilidades de Microsoft Defender o cualquier otra solución de análisis de imágenes.

Importante

El examen de imágenes de Microsoft Defender for Cloud no es compatible con los puntos de conexión de Container Registry. Para más información, consulte Conexión privada a un registro de contenedor mediante Private Link.