Arquitectura de Defender para contenedores

Completado

Defender para contenedores está diseñado de forma diferente para cada entorno de Kubernetes con independencia de que se ejecuten en:

• Azure Kubernetes Service (AKS): servicio administrado por Microsoft para desarrollar, implementar y administrar aplicaciones contenedorizadas.
  
• Amazon Elastic Kubernetes Service (EKS) en una cuenta de Amazon Web Services (AWS) conectada: el servicio administrado de Amazon para ejecutar Kubernetes en AWS sin necesidad de instalar, operar y mantener sus propios nodos o plano de control de Kubernetes.
  
• Google Kubernetes Engine (GKE) en un proyecto de Google Cloud Platform (GCP) conectado: el entorno administrado de Google para implementar, administrar y escalar aplicaciones mediante la infraestructura de GCP.
  
• Una distribución de Kubernetes no administrada (mediante Kubernetes habilitado para Azure Arc): clústeres de Kubernetes certificados de Cloud Native Computing Foundation (CNCF) hospedados localmente o en IaaS.

Para proteger los contenedores de Kubernetes, Defender para contenedores recibe y analiza lo siguiente:

• Registros de auditoría y eventos de seguridad del servidor de API
• Información de configuración del clúster del plano de control
• Configuración de la carga de trabajo de Azure Policy
• Señales de seguridad y eventos desde el nivel de nodo

Arquitectura para cada entorno de Kubernetes

Diagrama de arquitectura de Defender for Cloud y clústeres de AKS

Cuando Defender for Cloud protege un clúster hospedado en Azure Kubernetes Service, la recopilación de datos de registro de auditoría es sin agente y se recopila automáticamente a través de la infraestructura de Azure sin ningún costo adicional ni consideraciones de configuración. Estos componentes son necesarios para recibir la protección completa que ofrece Microsoft Defender para contenedores:

• Agente de Defender: El DaemonSet que se implementa en cada nodo, recopila señales de los hosts mediante la *tecnología Extended Berkeley Packet Filter (eBPF)* (filtro de paquetes de Berkeley extendido) y proporciona protección en tiempo de ejecución. El agente se registra con un área de trabajo de Log Analytics y se usa como canalización de datos. Sin embargo, los datos del registro de auditoría no se almacenan en el área de trabajo de Log Analytics. El agente de Defender se implementa como un perfil de seguridad de AKS.

  • *Historia e información sobre eBPF*: El filtro de paquetes de Berkeley extendido (eBPF) es un marco eficaz y versátil dentro del kernel de Linux para analizar y filtrar paquetes de red mediante programación, así como realizar otras tareas de nivel de sistema. Originalmente basado en el filtro de paquetes de Berkeley (BPF) introducido en la década de 1990, eBPF amplía sus capacidades, ya que permite que los programas definidos por el usuario se ejecuten dentro del kernel, lo que facilita el procesamiento dinámico y eficaz de paquetes sin necesidad de modificaciones en el propio kernel.
  • Los programas eBPF se escriben en un subconjunto restringido de C y se cargan en el kernel, donde se ejecutan dentro de un entorno seguro y de espacio aislado. Esto permite realizar una amplia gama de tareas relacionadas con la red directamente dentro del kernel, como el filtrado de paquetes, la supervisión del tráfico, el cumplimiento de la seguridad e incluso el análisis de protocolos personalizados.
  • Una de las principales ventajas de eBPF es su versatilidad y rendimiento. Al ejecutarse dentro del kernel, los programas eBPF pueden acceder y manipular paquetes de red directamente, lo que reduce significativamente la sobrecarga en comparación con los métodos tradicionales de procesamiento de paquetes en el espacio del usuario. Además, los programas eBPF se pueden cargar dinámicamente y conectar a varios enlaces dentro del kernel, lo que permite responder en tiempo real y adaptarse a las condiciones de red cambiantes.
  • eBPF se ha vuelto cada vez más popular en las aplicaciones modernas de red y seguridad debido a su flexibilidad y eficiencia. Se usa ampliamente en herramientas y marcos para la supervisión de red, la detección de intrusiones, el análisis de tráfico y el ajuste del rendimiento. Además, sus funcionalidades se extienden más allá de las redes a otras áreas de observabilidad y control del sistema, lo que lo convierte en una pieza fundamental para una amplia gama de aplicaciones y servicios basados en Linux.

• Azure Policy para Kubernetes: Un pod que extiende Gatekeeper v3 de código abierto y se registra como un webhook en el control de admisión de Kubernetes, lo que permite exigir cumplimiento y aplicar medidas de seguridad en los clústeres y a escala, de una manera centralizada y coherente. El Azure Policy para el pod de Kubernetes se implementa como un complemento de AKS. Solo se instala en un nodo del clúster.

Detalles del componente de agente de Defender

Nombre del pod	Espacio de nombres	Variante	Descripción corta	Capabilities	Límites de recursos	Salida requerida
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Conjunto de contenedores que se centran en la recopilación de eventos de inventario y seguridad del entorno de Kubernetes.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	memoria: 296Mi cpu: 360m	No
microsoft-defender-collector-misc-*	kube-system	Implementación	Conjunto de contenedores que se centran en la recopilación de eventos de inventario y seguridad del entorno de Kubernetes que no están enlazados al nodo específico.	N/D	memory: 64Mi cpu: 60m	No
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Publique los datos recopilados en el servicio back-end de Microsoft Defender para contenedores, donde se procesarán y analizarán los datos.	N/D	memory: 200Mi cpu: 60m	Https 443

¿Cómo funciona la detección sin agente para Kubernetes en Azure?

El proceso de detección se basa en instantáneas tomadas en intervalos:

Al habilitar la detección sin agente para la extensión de Kubernetes, se produce el siguiente proceso:

• Crear:

  • Si la extensión está habilitada desde Defender CSPM, Defender for Cloud crea una identidad en entornos de cliente denominados CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Si la extensión está habilitada desde Defender para contenedores, Defender for Cloud crea una identidad en entornos de cliente denominados CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Asignación: Defender for Cloud asigna un rol integrado llamado Operador sin agente de Kubernetes a esa identidad en el ámbito de suscripción. El rol contiene los siguientes permisos
  • Lectura de AKS (Microsoft.ContainerService/managedClusters/read)
    
  • Acceso de confianza de AKS con los siguientes permisos:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Descubrir: mediante la identidad asignada por el sistema, Defender for Cloud realiza un descubrimiento de los clústeres AKS en su entorno por medio de llamadas API al servidor API de AKS.

• Enlazar: Tras la detección de un clúster de AKS, Defender for Cloud realiza una operación de enlace de AKS mediante la creación de un ClusterRoleBinding entre la identidad creada y el ClusterRole de Kubernetes aks:trustedaccessrole:defender-containers:microsoft-defender-operator. El ClusterRole es visible a través de la API y otorga a Defender for Cloud permiso de lectura del plano de datos dentro del clúster.

Obtención de acceso seguro a los recursos de Azure en Azure Kubernetes Service mediante el Acceso de confianza (versión preliminar)

Muchos servicios de Azure que se integran en Azure Kubernetes Service (AKS) necesitan acceso al servidor de API de Kubernetes. Para no conceder a estos servicios acceso de administrador ni hacer que los clústeres de AKS sean públicos para el acceso a la red, puede usar la característica Acceso de confianza de AKS.

Esta característica proporciona a los servicios acceso seguro a AKS y Kubernetes mediante el back-end de Azure sin necesidad de un punto de conexión privado. En lugar de utilizar las identidades con permisos de Microsoft Entra, esta característica puede usar su identidad administrada asignada por el sistema para autenticarse en los servicios administrados y las aplicaciones que dese usar con los clústeres de AKS.

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible.

Nota:

La API de Acceso de confianza está disponible con carácter general. Ofrecemos compatibilidad con disponibilidad general para la CLI de Azure, pero aún está en versión preliminar y requiere el uso de la extensión aks-preview.

IInformación general sobre la característica Acceso de confianza

Acceso de confianza aborda los escenarios siguientes:

• Si se establece un intervalo de IP autorizadas en un clúster privado, es posible que los servicios de Azure no puedan acceder al servidor de API Kubernetes, a menos que se implemente un modelo de acceso mediante punto de conexión privado.
• Proporcionar acceso de administrador a un servicio de Azure a API Kubernetes no sigue el procedimiento recomendado de acceso con privilegios mínimos, lo que podría provocar la elevación de privilegios o el riesgo de pérdida de credenciales. Por ejemplo, puede que tenga que implementar permisos de servicio a servicio con privilegios elevados, algo que no es lo más apropiado en las revisiones de auditoría.

Puede usar Acceso de confianza para dar consentimiento explícito a su identidad administrada asignada por el sistema de los recursos permitidos para acceder a los clústeres de AKS mediante un recurso de Azure denominado enlace de roles. Los recursos de Azure acceden a los clústeres de AKS a través de la puerta de enlace regional de AKS por medio de la autenticación de identidades administradas asignadas por el sistema. Los permisos de Kubernetes adecuados se asignan mediante un recurso de Azure denominado rol. Acceso de confianza le permite acceder a los clústeres de AKS con diferentes configuraciones, incluidos, entre otros, los clústeres privados, los que tienen cuentas locales desactivadas, los de Microsoft Entra o los de intervalos de IP autorizadas.

Requisitos previos

• Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.

• Tipos de recursos que admiten la identidad administrada asignada por el sistema.

  • Si usa la CLI de Azure, se requiere la versión 0.5.74 o posterior de la extensión aks-preview.

• Para obtener información sobre los roles que se van a usar en diferentes escenarios, consulte estos artículos:

  • Acceso de Azure Machine Learning a clústeres de AKS con configuraciones especiales
  • ¿Qué es la copia de seguridad de Azure Kubernetes Service?
  • Activación de posiciones de contenedores sin agente

Diagrama de arquitectura de Defender for Cloud y clústeres de Kubernetes habilitados para Arc

Estos componentes son necesarios para recibir la protección completa que ofrece Microsoft Defender para contenedores:

• Kubernetes habilitado para Azure Arc: Kubernetes habilitado para Azure Arc: una solución basada en agente, instalada en un nodo del clúster, que conecta los clústeres a Defender for Cloud. Después, Defender for Cloud puede implementar los dos agentes siguientes como extensiones de Arc:
• Agente de Defender: El DaemonSet que se implementa en cada nodo recopila señales de host mediante la tecnología eBPF y los registros de auditoría de Kubernetes para proporcionar protección en tiempo de ejecución. El agente se registra con un área de trabajo de Log Analytics y se usa como canalización de datos. Sin embargo, los datos del registro de auditoría no se almacenan en el área de trabajo de Log Analytics. El agente de Defender se implementa como una extensión de Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Un pod que amplía el Gatekeeper v3 de código abierto y se registra como un webhook en el control de admisión de Kubernetes, lo que permite aplicar cumplimiento a gran escala y medidas de seguridad en los clústeres de una manera centralizada y coherente. Se implementa Azure Policy para el pod de Kubernetes como una extensión de Kubernetes habilitada para Arc. Solo se instala en un nodo del clúster. Para más información, consulte Protección de las cargas de trabajo de Kubernetes y Descripción de Azure Policy para clústeres de Kubernetes.
  

Diagrama de arquitectura de Defender for Cloud y clústeres de EKS

Cuando Defender for Cloud protege un clúster hospedado en Elastic Kubernetes Service, la recopilación de datos de registro de auditoría es sin agente. Estos componentes son necesarios para recibir la protección completa que ofrece Microsoft Defender para contenedores:

• Registros de auditoría de Kubernetes: CloudWatch de la cuenta de AWS habilita y recopila datos de registro de auditoría a través de un recopilador sin agente y envía la información recopilada al back-end de Microsoft Defender for Cloud para su posterior análisis.
• Kubernetes habilitado para Azure Arc: Kubernetes habilitado para Azure Arc: una solución basada en agente, instalada en un nodo del clúster, que conecta los clústeres a Defender for Cloud. Después, Defender for Cloud puede implementar los dos agentes siguientes como extensiones de Arc:
• Agente de Defender: el DaemonSet que se implementa en cada nódulo que recopila señales de los hosts mediante tecnología eBPF y proporciona protección en tiempo de ejecución. El agente se registra con un área de trabajo de Log Analytics y se usa como canalización de datos. Sin embargo, los datos del registro de auditoría no se almacenan en el área de trabajo de Log Analytics. El agente de Defender se implementa como una extensión de Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Un pod que amplía el Gatekeeper v3 de código abierto y se registra como un webhook en el control de admisión de Kubernetes, lo que permite aplicar cumplimiento a gran escala y medidas de seguridad en los clústeres de una manera centralizada y coherente. Se implementa Azure Policy para el pod de Kubernetes como una extensión de Kubernetes habilitada para Arc. Solo se instala en un nodo del clúster.

¿Cómo funciona la detección sin agente para Kubernetes en AWS?

El proceso de detección se basa en instantáneas tomadas en intervalos:

Al habilitar la extensión Detección sin agente para Kubernetes, se producirá el siguiente proceso:

• Crear:

  • El rol de Defender for Cloud MDCContainersAgentlessDiscoveryK8sRole debe agregarse a aws-auth ConfigMap de los clústeres de EKS. El nombre se puede personalizar.
    

• Asignación: Defender for Cloud asigna al rol MDCContainersAgentlessDiscoveryK8sRole los permisos siguientes:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Descubrir: mediante la identidad asignada por el sistema, Defender for Cloud realiza un descubrimiento de los clústeres de EKS en su entorno por medio de llamadas API al servidor API de EKS.

Diagrama de arquitectura de Defender for Cloud y clústeres de GKE

Cuando Defender for Cloud protege un clúster hospedado en Google Kubernetes Engine, la recopilación de datos de registro de auditoría es sin agente. Estos componentes son necesarios para recibir la protección completa que ofrece Microsoft Defender para contenedores:

• Registros de auditoría de Kubernetes: GCP Cloud Logging habilita y recopila datos de registro de auditoría a través de un recopilador sin agente y envía la información recopilada al back-end de Microsoft Defender for Cloud para su posterior análisis.
• Kubernetes habilitado para Azure Arc: Kubernetes habilitado para Azure Arc: una solución basada en agente, instalada en un nodo del clúster, que conecta los clústeres a Defender for Cloud. Después, Defender for Cloud puede implementar los dos agentes siguientes como extensiones de Arc:
• Agente de Defender: el DaemonSet que se implementa en cada nódulo que recopila señales de los hosts mediante tecnología eBPF y proporciona protección en tiempo de ejecución. El agente se registra con un área de trabajo de Log Analytics y se usa como canalización de datos. Sin embargo, los datos del registro de auditoría no se almacenan en el área de trabajo de Log Analytics. El agente de Defender se implementa como una extensión de Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Un pod que amplía el Gatekeeper v3 de código abierto y se registra como un webhook en el control de admisión de Kubernetes, lo que permite aplicar cumplimiento a gran escala y medidas de seguridad en los clústeres de una manera centralizada y coherente. Se implementa Azure Policy para el pod de Kubernetes como una extensión de Kubernetes habilitada para Arc. Solo debe instalarse en un nodo del clúster.

¿Cómo funciona la detección sin agente para Kubernetes en GCP?

El proceso de detección se basa en instantáneas tomadas en intervalos:

Al habilitar la extensión Detección sin agente para Kubernetes, se producirá el siguiente proceso:

• Crear:

  • Se crea la cuenta de servicio mdc-containers-k8s-operator. El nombre se puede personalizar.

• Asignación: Defender for Cloud asocia los siguientes roles a la cuenta de servicio mdc-containers-k8s-operator:

  • El rol personalizado MDCGkeClusterWriteRole, que tiene el permiso container.clusters.update.
  • El rol integrado container.viewer

• Descubrir: mediante la identidad asignada por el sistema, Defender for Cloud realiza un descubrimiento de los clústeres de GKE en su entorno por medio de llamadas API al servidor API de GKE.