Compartir a través de

Seguridad de AKS

  • Artículo

En este artículo se explican diversos aspectos de la gobernanza de seguridad de Azure Kubernetes Service (AKS) que se deben considerar antes de implementar una solución.

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

Superficies de ataque

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

  • Build
  • Registro
  • Clúster
  • Nodo
  • Application

Para cada categoría, se analizan los principales riesgos que se deben tener en cuenta y las contramedidas de esos riesgos.

Seguridad

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

Riesgos principales

Una configuración de imagen deficiente puede provocar vulnerabilidades de seguridad hacia abajo 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 permitidas al sistema a aquellas necesarias para el funcionamiento seguro de los contenedores puede aumentar el riesgo de un contenedor en peligro.

Otra vulnerabilidad podría ser 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 se hayan sometido a un riguroso examen en busca de vulnerabilidades o que no estén correctamente configurados. 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 al día 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 empiecen a dejarse notar luego en la canalización. No se trata de poner toda la propiedad en los desarrolladores, sino de compartir la propiedad con las operaciones. 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 tenga una o diez vulnerabilidades críticas. Un enfoque mejor podría ser examinar la siguiente capa de nivel inferior. 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 vulnerabilidades.

Junto con la evaluación de vulnerabilidades, se encuentra la evaluación de cumplimiento. Por ejemplo, permitir que una imagen se ejecute como raíz o exponer SSH interrumpe la posición 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 mediante la introducción de la corrección de seguridad, pero puede mejorar la posición de seguridad general de la empresa alineada.

El uso de una herramienta que permita 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 conducir a 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 en todo el ciclo de vida de las imágenes, desde el principio del proceso de compilación hasta el registro en el entorno de ejecución.
  • Visibilidad sobre las vulnerabilidades en todas las capas de la imagen, incluida la capa base de la imagen, los marcos de trabajo de la aplicación 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 sobre:

  • La desviación del control respecto a la compilación.
  • La prevención de inserción o extracción de imágenes contaminadas.
  • La firma de imágenes.

Riesgos principales

Las imágenes suelen contener información de propiedad, incluido el código fuente de una organización. Si las conexiones a los registros no son debidamente seguras, el contenido de una imagen podría plantear riesgos de confidencialidad tan graves como cualquier otra forma de datos transmitidos dentro de su 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 contener recursos propietarios confidenciales en las imágenes.

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

Contramedidas de riesgo

Configurar procesos de implementación para tener la seguridad de que las herramientas de desarrollo, las redes y los entornos de ejecución de contenedor estén conectados a los 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:

  • Eliminar imágenes vulnerables y no seguras que ya no se deben usar de los registros de contenedor.
  • Aplicar el acceso a imágenes mediante nombres inmutables que especifiquen versiones específicas de las imágenes que se usarán. Se 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 actualización. 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 el 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 directivas de acceso de nivel de línea 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 que ahora se consideran 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 ofrece un registro, con proyectos de código abierto y productos de proveedores que están disponibles para el hospedaje local o privado dentro de los proveedores de nube. El contenido se promueve dentro de Registros y entre ellos desde su compilación inicial hasta su implementación de producción.

¿Cómo puede garantizar que la integridad del contenido que entró en el registro es la misma que sale de él? La adopción de una solución de firma de imágenes garantiza que las implementaciones solo vienen de registros de confianza y que implementan contenidos de confianza.

Seguridad de clúster

La seguridad del clúster trata sobre:

  • Autenticación y autorización.
  • Seguridad de red.
  • La administración de cumplimiento y vulnerabilidad.

Riesgos principales

En ocasiones, un único clúster de Kubernetes podría usarse 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, usuarios malintencionados o descuidados podrían poner en peligro las cargas de trabajo a las que tienen acceso y otros recursos del clúster.

Otra vulnerabilidad de seguridad puede producirse cuando el propio directorio de usuarios 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 tienen privilegios elevados, y con mayor frecuencia son huérfanas, aumentan las posibilidades de que una cuenta se vea comprometida.

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

Lod filtros de red tradicionales podrían tener una "ceguera de seguridad" debido a una superposición 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 provisiones especiales para supervisar los clústeres de Kubernetes.

El tráfico de diferentes aplicaciones que comparten el mismo clúster puede tener niveles de confidencialidad diferentes, por ejemplo, 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 poner en riesgo los datos confidenciales. Por ejemplo, un atacante podría usar la red compartida expuesta a Internet para atacar a las aplicaciones internas.

Proteja los componentes que ejecutan el propio clúster de vulnerabilidades y problemas de cumplimiento. Asegúrese de que ejecuta 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. Solo conceda acceso a los usuarios 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 tener acceso— a contenedores en producción. Las cuentas de usuario con acceso a todo el clúster deben controlarse correctamente y usarse con moderación.

Use métodos de autenticación segura, como la autenticación multifactor, para proteger el acceso a estas cuentas. Un directorio de usuarios de la organización debe usarse para administrar clústeres a través del inicio de sesión único en lugar de 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 que los contenedores accedan correctamente a los datos independientemente del host en el que se ejecuten los contenedores. Estas herramientas de cifrado deben evitar 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 podría ser posible, pero definir las redes por niveles de sensibilidad podría ser suficiente. Por ejemplo, deberían implementarse, como mínimo, redes virtuales para las aplicaciones orientadas al cliente separadas de las que atienden a las aplicaciones internas con tráfico confidencial.

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 dentro del mismo nodo que aquellas con menor confidencialidad. 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 los contenedores de esta manera, es mucho más difícil que un atacante que tenga acceso a un segmento obtenga acceso a otros. Esta configuración tambié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 confidencialidad.

Los clústeres de Kubernetes deben configurarse para:

  • Proporcionar un entorno seguro para las aplicaciones que se ejecutan en ellos.
  • Asegurarse 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.
  • Proporcionar información actual y precisa sobre el estado del clúster, incluidas las redes y los nodos que contiene.

Debe ser fácil que un nodo en peligro se aísle y se quite del clúster sin que ello afecte al rendimiento del clúster. AKS lo simplifica.

Defina los estándares de configuración del runtime del contenedor para garantizar automáticamente el cumplimiento. Hay muchas directivas en Azure que simplifican 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 están abordando las vulnerabilidades de los componentes de Kubernetes. Use entornos independientes para desarrollo, prueba y producción, cada uno con sus propios controles y 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 trata sobre:

  • Protección en tiempo de ejecución.
  • La administración de cumplimiento y vulnerabilidad.

Riesgos principales

Un nodo de trabajo tiene acceso con privilegios a todos los componentes del nodo. Los atacantes pueden usar cualquier servicio accesible de red como punto de entrada, por lo que proporcionar acceso al host desde varios puntos puede aumentar gravemente su superficie de ataque. Cuanto mayor sea la superficie de ataque, más posibilidades hay 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 ataques más pequeña porque no contienen bibliotecas que permitan a los sistemas operativos normales ejecutar directamente bases de datos y servidores web. El uso de un kernel compartido da como resultado una superficie de ataques mayor para los contenedores que se ejecutan en el mismo entorno que los de máquinas virtuales independientes. Esto es así 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 están hospedando. AKS protege a los usuarios garantizando que estas vulnerabilidades se solucionen mediante actualizaciones periódicas del sistema operativo en los nodos que se ejecutan en AKS, y que se mantenga 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 aplicaciones más allá de aquellas a las que debería tener acceso.

Además, los contenedores malintencionados podrían provocar la alteración 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 a los nodos limitando el acceso SSH.

El uso del sistema operativo específico del contenedor en los nodos de AKS normalmente reduce las superficies de ataque, ya que se deshabilitan otros servicios y funcionalidades. 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 del clúster durante la noche. Si una actualización de seguridad del sistema operativo de Linux requiere un reinicio del host, no se realizará automáticamente. AKS proporciona mecanismos de reinicio para aplicar esas revisiones específicas.

Microsoft Defender para servidores no es aplicable a nodos AKS de Linux y Windows, porque Microsoft administra sus sistemas operativos. Si no hay otras máquinas virtuales en la suscripción en la que está implementado AKS, puede deshabilitar Microsoft Defender para servidores de forma segura.

Si se ha implementado el entorno, incluidas las directivas de Azure recomendadas de 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 las aplicaciones trata sobre:

  • Protección en tiempo de ejecución.
  • La administración de cumplimiento y vulnerabilidad.

Riesgos principales

Las imágenes son archivos que incluyen todos los componentes necesarios para ejecutar una aplicación. Cuando se usa la versión más reciente de estos componentes para crear imágenes, es posible que estén libres de vulnerabilidades conocidas en ese momento, pero estas pueden cambiar rápidamente.

Debe mantener actualizados estos archivos 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 insertar en una imagen, que luego se puede usar para atacar a otros contenedores o componentes del sistema. Los contenedores de terceros pueden ser un posible vector de ataque. Es posible que se conozcan detalles específicos sobre ellos y que puedan filtrar datos. Es posible que 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 en un sistema de archivos de imagen. Esta práctica puede provocar un riesgo para la seguridad, ya que 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 a la inserción SQL. Cuando existen estos problemas, la vulnerabilidad podría usarse 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 de 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 los contenedores para asegurarse de que los contenedores no puedan enviar tráfico a través de 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 red y seguridad de 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. Podrían colocar pods de diferentes niveles de confidencialidad 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 de acceso público para atacar contenedores que ejecutan procesos más confidenciales en el mismo host. También se puede usar un contenedor en riesgo para examinar la red y encontrar otras vulnerabilidades que el atacante pueda aprovechar.

Contramedidas de riesgo

Nunca almacene secretos en el código de la aplicación o en los sistemas de archivos. Los secretos nunca deben almacenarse en almacenes de claves y proporcionarse a los contenedores en el entorno de ejecución según sea necesario. AKS puede garantizar que solo los contenedores que necesitan acceso a determinadas claves tengan acceso a ellas y que estos secretos no se conserven 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 fácil asegurarse de que estos secretos se cifran tanto en el almacenamiento como en tránsito.

Evite el uso de imágenes y registros que no son de confianza y asegurarse de que solo las imágenes de conjuntos de confianza pueden ejecutarse en sus clústeres. Para un enfoque multicapa:

  • Controlar de forma centralizada qué imágenes y registros son de confianza.
  • Identificar discretamente cada imagen por firma criptográfica.
  • Poner en marcha directivas que garanticen que todos los hosts solo ejecuten imágenes que sean del conjunto aprobado.
  • Validar estas firmas antes de la ejecución.
  • Supervisar y actualizar estas imágenes y Registros a medida que cambien las vulnerabilidades y los requisitos de configuración.

Los perfiles de computación segura deben utilizarse para limitar los contenedores y asignarse en el entorno 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 capacidades. 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 automáticamente perfiles de aplicaciones mediante el aprendizaje de 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 los archivos de configuración y binarios protegidos.
  • 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 al riesgo, ya que estas ubicaciones específicas quedan aisladas de la manipulación. Se pueden separar fácilmente del resto de la aplicación.

Consideraciones de diseño

AKS tiene varias interfaces con 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 supone una complejidad adicional, lo que implica considerar si se deben aplicar los mismos mecanismos y controles de seguridad, gobernanza y cumplimiento que en el resto de la infraestructura.

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

  • Si crea un clúster de AKS en una suscripción implementada según los procedimientos recomendados de zona de aterrizaje a escala empresarial, familiarícese con las directivas de Azure que heredarán los clústeres. Para obtener 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 (recomendamos restricciones de IP), que es el valor predeterminado, o solo desde dentro de la red privada en Azure o localmente como un clúster privado. Si su organización sigue los procedimientos recomendados de zona de aterrizaje a escala empresarial, el grupo de administración Corp tiene asociada una estrategia Azure Policy que obliga a que los clústeres sean privados. Para obtener 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 AppArmor integrado de Linux para limitar las acciones que pueden realizar los contenedores, como leer, escribir, ejecutar o utilizar funciones del sistema, como montar 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 obtener más información, consulte Directivas incluidas en implementaciones de referencia de zonas de aterrizaje de Azure.
  • Evalúe el uso de seccomp (computación segura) en el nivel de proceso para limitar las llamadas de proceso que los contenedores pueden realizar. 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 se puede acceder al registro de contenedor a través de Internet o solo dentro de una red virtual específica. La deshabilitación del 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. Entre los ejemplos se incluyen 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 de Azure 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 en busca de vulnerabilidades.
  • Para evitar costos innecesarios, considere la posibilidad de deshabilitar Microsoft Defender para servidores en la suscripción de AKS si no hay máquinas virtuales que no sean de AKS.

Recomendaciones de diseño

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 de Azure mediante Azure Private Link.