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.
Nota
La compatibilidad de Defender con contenedores con clústeres de Kubernetes habilitados para Arc (AWS EKS y GCP GKE) es una característica en versión preliminar.
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
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:
Sensor de Defender: El DaemonSet implementado 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 sensor 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 sensor de Defender se implementa como un perfil de seguridad de AKS.
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. 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.
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.
¿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 extensión Detección sin agente para Kubernetes, se producirá 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 AKS (Microsoft.ContainerService/managedClusters/read)
Acceso de confianza AKS con los siguientes permisos:
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 AKS, Defender for Cloud realiza una operación de enlace AKS creando 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.
Nota:
La instantánea copiada permanece en la misma región que el clúster.
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 sensor, 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:
Sensor 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 sensor 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 sensor de Defender se implementa como una extensión de Kubernetes habilitada para Arc.
La compatibilidad de Defender para contenedores con clústeres de Kubernetes habilitados para Arc es una característica en versión preliminar.
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:
Kubernetes habilitado para Azure Arc: Kubernetes habilitado para Azure Arc: una solución basada en sensor, 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:
Sensor de Defender: El DaemonSet implementado 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 sensor 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 sensor de Defender se implementa como una extensión de Kubernetes habilitada para Arc.
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. 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.
¿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.
Asignar: 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.
Nota:
La instantánea copiada permanece en la misma región que el clúster.
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: Registros de nube de GCP 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 sensor, instalada en un nodo del clúster, que permite a los clústeres conectarse a Defender for Cloud. Después, Defender for Cloud puede implementar los dos agentes siguientes como extensiones de Arc:
Sensor de Defender: El DaemonSet implementado 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 sensor 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.
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. 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. 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.
¿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.
Asignar: 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.
Nota:
La instantánea copiada permanece en la misma región que el clúster.
Pasos siguientes
En esta información general, ha obtenido información sobre la arquitectura de la seguridad de los contenedores en Microsoft Defender for Cloud. Para habilitar el plan, consulte: