Architettura di Defender per contenitori

Defender per contenitori è progettato in modo diverso per ogni ambiente Kubernetes, indipendentemente dal fatto che si tratti di servizi eseguiti in:

• Servizio Azure Kubernetes: servizio gestito da Microsoft per lo sviluppo, la distribuzione e la gestione di applicazioni in contenitori.

• Amazon Elastic Kubernetes Service (EKS) in un account Amazon Web Services (AWS) connesso: il servizio gestito di Amazon per l'esecuzione di Kubernetes in AWS senza dover installare, eseguire e gestire un piano di controllo o nodi Kubernetes personalizzati.

• Google Kubernetes Engine (GKE) in un progetto GCP (Google Cloud Platform) connesso, l'ambiente gestito da Google per la distribuzione, la gestione e il ridimensionamento delle applicazioni tramite l'infrastruttura GCP.

• Una distribuzione Kubernetes non gestita (con Kubernetes con abilitazione di Azure Arc): cluster Kubernetes certificati CNCF (Cloud Native Computing Foundation) ospitati in locale o in un'infrastruttura distribuita come servizio (IaaS).

Nota

Il supporto di Defender per contenitori per i cluster Kubernetes abilitati per Arc (AWS EKS e GCP GKE) è una funzionalità di anteprima.

Per proteggere i contenitori Kubernetes, Defender per contenitori riceve e analizza:

• Log di controllo ed eventi di sicurezza dal server API
• Informazioni di configurazione del cluster dal piano di controllo
• Configurazione del carico di lavoro da Criteri di Azure
• Segnali di sicurezza ed eventi dal livello del nodo

Per altre informazioni sui dettagli di implementazione, ad esempio sistemi operativi supportati, disponibilità delle funzionalità, proxy in uscita, vedere Disponibilità delle funzionalità di Defender per contenitori.

Architettura per ogni ambiente Kubernetes

Azure (servizio Azure Kubernetes)

Diagramma dell'architettura dei cluster Defender per il cloud e servizio Azure Kubernetes

Quando Defender per il cloud protegge un cluster ospitato in servizio Azure Kubernetes, la raccolta dei dati di log di controllo è senza agente e viene raccolta automaticamente tramite l'infrastruttura di Azure senza costi aggiuntivi o considerazioni sulla configurazione. Questi sono i componenti necessari per ricevere la protezione completa offerta da Microsoft Defender per contenitori:

• Sensore defender: DaemonSet distribuito in ogni nodo, raccoglie i segnali dagli host usando la tecnologia eBPF e fornisce la protezione di runtime. Il sensore viene registrato in un'area di lavoro Log Analytics e usato come pipeline di dati. Tuttavia, i dati del log di controllo non vengono archiviati nell'area di lavoro Log Analytics. Il sensore defender viene distribuito come profilo di sicurezza del servizio Azure Kubernetes.
• Criteri di Azure per Kubernetes: un pod che estende gatekeeper v3 open source e si registra come web hook al controllo di ammissione Kubernetes che consente di applicare le imposizione su larga scala e le misure di sicurezza nei cluster in modo centralizzato e coerente. Il pod di Criteri di Azure per Kubernetes viene distribuito come componente aggiuntivo del servizio Azure Kubernetes. È installato solo in un nodo del cluster. Per altre informazioni, vedere Proteggere i carichi di lavoro Kubernetes e Comprendere Criteri di Azure per i cluster Kubernetes.

Dettagli del componente del sensore Defender

Nome pod	Spazio dei nomi	Tipologia	Breve descrizione	Capabilities	Limiti delle risorse	Uscita obbligatoria
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Set di contenitori incentrati sulla raccolta di eventi di inventario e sicurezza dall'ambiente Kubernetes.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	memoria: 296Mi cpu: 360m	No
microsoft-defender-collector-misc-*	kube-system	Distribuzione	Set di contenitori incentrati sulla raccolta di eventi di inventario e sicurezza dall'ambiente Kubernetes che non sono associati a un nodo specifico.	N/D	memoria: 64Mi cpu: 60m	No
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Pubblicare i dati raccolti nel servizio back-end di Microsoft Defender per contenitori, in cui i dati verranno elaborati e analizzati.	N/D	memoria: 200Mi cpu: 60m	Https 443 Altre informazioni sui prerequisiti di accesso in uscita

* I limiti delle risorse non sono configurabili; Altre informazioni sui limiti delle risorse kubernetes.

Come funziona l'individuazione senza agente per Kubernetes in Azure?

Il processo di individuazione si basa sugli snapshot creati a intervalli:

Quando si abilita l'individuazione senza agente per l'estensione Kubernetes, si verifica il processo seguente:

• Creazione:

  • Se l'estensione è abilitata da Defender CSPM, Defender per il cloud crea un'identità negli ambienti dei clienti denominata CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
  • Se l'estensione è abilitata da Defender per contenitori, Defender per il cloud crea un'identità negli ambienti dei clienti denominati CloudPosture/securityOperator/DefenderForContainersSecurityOperator.

• Assegna: Defender per il cloud assegna un ruolo predefinito denominato Operatore senza agente Kubernetes a tale identità nell'ambito della sottoscrizione. Il ruolo contiene le autorizzazioni seguenti:

  • Lettura del servizio Azure Kubernetes (Microsoft.ContainerService/managedClusters/read)
  • Servizio Azure Kubernetes Accesso attendibile con le autorizzazioni seguenti:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

  Altre informazioni sull'accesso attendibile del servizio Azure Kubernetes.

• Individuare: Usando l'identità assegnata dal sistema, Defender per il cloud esegue un'individuazione dei cluster del servizio Azure Kubernetes nell'ambiente usando le chiamate API al server API del servizio Azure Kubernetes.

• Bind: dopo l'individuazione di un cluster del servizio Azure Kubernetes, Defender per il cloud esegue un'operazione di associazione del servizio Azure Kubernetes creando un oggetto ClusterRoleBinding tra l'identità creata e il servizio Azure Kubernetes ClusterRoleaks:trustedaccessrole:defender-containers:microsoft-defender-operator. è visibile tramite l'API ClusterRole e fornisce Defender per il cloud'autorizzazione di lettura del piano dati all'interno del cluster.

Nota

Lo snapshot copiato rimane nella stessa area del cluster.

Locale/IaaS (Arc)

Diagramma dell'architettura dei cluster Kubernetes abilitati per Defender per il cloud e Arc

Questi componenti sono necessari per ricevere la protezione completa offerta da Microsoft Defender per contenitori:

• Kubernetes con abilitazione di Azure Arc - Kubernetes con abilitazione di Azure Arc: soluzione basata su sensori, installata in un nodo del cluster, che connette i cluster a Defender per il cloud. Defender per il cloud è quindi in grado di distribuire i due agenti seguenti come Estensioni Arc:

• Sensore defender: DaemonSet distribuito in ogni nodo, raccoglie i segnali host usando la tecnologia eBPF e i log di controllo kubernetes per fornire la protezione di runtime. Il sensore viene registrato in un'area di lavoro Log Analytics e usato come pipeline di dati. Tuttavia, i dati del log di controllo non vengono archiviati nell'area di lavoro Log Analytics. Il sensore Defender viene distribuito come estensione Kubernetes abilitata per Arc.

• Criteri di Azure per Kubernetes: un pod che estende gatekeeper v3 open source e si registra come web hook al controllo di ammissione Kubernetes che consente di applicare le imposizione su larga scala e le misure di sicurezza nei cluster in modo centralizzato e coerente. È installato solo in un nodo del cluster. Per altre informazioni, vedere Proteggere i carichi di lavoro Kubernetes e Comprendere Criteri di Azure per i cluster Kubernetes.

Nota

Il supporto di Defender per contenitori per i cluster Kubernetes abilitati per Arc è una funzionalità di anteprima.

AWS (EKS)

Diagramma dell'architettura dei cluster Defender per il cloud ed EKS

Quando Defender per il cloud protegge un cluster ospitato in Elastic Kubernetes Service, la raccolta di dati del log di controllo è senza agente. Questi sono i componenti necessari per ricevere la protezione completa offerta da Microsoft Defender per contenitori:

• Log di controllo di Kubernetes: CloudWatch dell'account AWS abilita e raccoglie i dati del log di controllo tramite un agente di raccolta senza agente e invia le informazioni raccolte al back-end Microsoft Defender per il cloud per ulteriori analisi.
• Kubernetes con abilitazione di Azure Arc - Kubernetes con abilitazione di Azure Arc: soluzione basata su sensori, installata in un nodo del cluster, che connette i cluster a Defender per il cloud. Defender per il cloud è quindi in grado di distribuire i due agenti seguenti come Estensioni Arc:
• Sensore defender: DaemonSet distribuito in ogni nodo, raccoglie i segnali dagli host usando la tecnologia eBPF e fornisce la protezione di runtime. Il sensore viene registrato in un'area di lavoro Log Analytics e usato come pipeline di dati. Tuttavia, i dati del log di controllo non vengono archiviati nell'area di lavoro Log Analytics. Il sensore Defender viene distribuito come estensione Kubernetes abilitata per Arc.
• Criteri di Azure per Kubernetes: un pod che estende gatekeeper v3 open source e si registra come web hook al controllo di ammissione Kubernetes che consente di applicare le imposizione su larga scala e le misure di sicurezza nei cluster in modo centralizzato e coerente. Il pod di Criteri di Azure per Kubernetes viene distribuito come estensione Kubernetes abilitata ad Arc. È installato solo in un nodo del cluster. Per altre informazioni, vedere Proteggere i carichi di lavoro Kubernetes e Comprendere Criteri di Azure per i cluster Kubernetes.

Come funziona l'individuazione senza agente per Kubernetes in AWS?

Il processo di individuazione si basa sugli snapshot creati a intervalli:

Quando si abilita l'individuazione senza agente per l'estensione Kubernetes, si verifica il processo seguente:

• Creazione:

  • Il ruolo Defender per il cloud MDCContainersAgentlessDiscoveryK8sRole deve essere aggiunto al file ConfigMap aws-auth dei cluster del servizio Azure Kubernetes. Il nome può essere personalizzato.

• Assegna: Defender per il cloud assegna il ruolo MDCContainersAgentlessDiscoveryK8sRole alle autorizzazioni seguenti:

  • eks:UpdateClusterConfig
  • eks:DescribeCluster

• Individuare: Usando l'identità assegnata dal sistema, Defender per il cloud esegue un'individuazione dei cluster del servizio Azure Kubernetes nell'ambiente usando le chiamate API al server API di EKS.

Nota

Lo snapshot copiato rimane nella stessa area del cluster.

GCP (GKE)

Diagramma dell'architettura dei cluster Defender per il cloud e GKE

Quando Defender per il cloud protegge un cluster ospitato in Google Kubernetes Engine, la raccolta dei dati del log di controllo è senza agente. Questi sono i componenti necessari per ricevere la protezione completa offerta da Microsoft Defender per contenitori:

• Log di controllo di Kubernetes: GCP Cloud Logging abilita e raccoglie i dati dei log di controllo tramite un agente di raccolta senza agente e invia le informazioni raccolte al back-end Microsoft Defender per il cloud per ulteriori analisi.

• Kubernetes con abilitazione di Azure Arc - Kubernetes con abilitazione di Azure Arc: soluzione basata su sensori installata in un nodo del cluster, che consente ai cluster di connettersi a Defender per il cloud. Defender per il cloud è quindi in grado di distribuire i due agenti seguenti come Estensioni Arc:

• Sensore defender: DaemonSet distribuito in ogni nodo, raccoglie i segnali dagli host usando la tecnologia eBPF e fornisce la protezione di runtime. Il sensore viene registrato in un'area di lavoro Log Analytics e usato come pipeline di dati. Tuttavia, i dati del log di controllo non vengono archiviati nell'area di lavoro Log Analytics.

• Criteri di Azure per Kubernetes: un pod che estende gatekeeper v3 open source e si registra come web hook al controllo di ammissione Kubernetes che consente di applicare le imposizione su larga scala e le misure di sicurezza nei cluster in modo centralizzato e coerente. Il pod di Criteri di Azure per Kubernetes viene distribuito come estensione Kubernetes abilitata ad Arc. Deve essere installato solo in un nodo del cluster. Per altre informazioni, vedere Proteggere i carichi di lavoro Kubernetes e Comprendere Criteri di Azure per i cluster Kubernetes.

Come funziona l'individuazione senza agente per Kubernetes in GCP?

Il processo di individuazione si basa sugli snapshot creati a intervalli:

Quando si abilita l'individuazione senza agente per l'estensione Kubernetes, si verifica il processo seguente:

• Creazione:

  • Viene creato l'account del servizio mdc-containers-k8s-operator . Il nome può essere personalizzato.

• Assegna: Defender per il cloud collega i ruoli seguenti all'account del servizio mdc-containers-k8s-operator:

  • Ruolo personalizzato MDCGkeClusterWriteRole, che dispone dell'autorizzazione container.clusters.update
  • Ruolo predefinito container.viewer

• Individuare: Usando l'identità assegnata dal sistema, Defender per il cloud esegue un'individuazione dei cluster GKE nell'ambiente usando le chiamate API al server API di GKE.

Nota

Lo snapshot copiato rimane nella stessa area del cluster.

Passaggi successivi

In questa panoramica è stata illustrata l'architettura della sicurezza dei contenitori in Microsoft Defender per il cloud. Per abilitare il piano, vedere:

Abilitare Defender per contenitori