Indietro

Prossima

Architettura di Defender per contenitori

Completato

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).

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

Architettura per ogni ambiente 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:

• Agente di Defender: Il DaemonSet distribuito in ogni nodo raccoglie i segnali dagli host usando la tecnologia *Extended Berkeley Packet Filter (eBPF) *e fornisce la protezione runtime. L'agente viene registrato con 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. L'agente di Defender viene distribuito come profilo di sicurezza del servizio Azure Kubernetes.

  • *Informazioni e contesto eBPF*: Extended Berkeley Packet Filter (eBPF) è un framework potente e versatile all'interno del kernel Linux per, a livello di programmazione, analizzare e filtrare i pacchetti di rete, nonché eseguire varie altre attività a livello di sistema. Originariamente basato sul Berkeley Packet Filter (BPF) introdotto negli anni '90, l'eBPF ne espande le funzionalità consentendo l'esecuzione di programmi definiti dall'utente all'interno del kernel, permettendo un'elaborazione dinamica ed efficiente dei pacchetti senza richiedere modifiche al kernel stesso.
  • I programmi eBPF vengono scritti in un sottoinsieme limitato di C e vengono caricati nel kernel, in cui vengono eseguiti in un ambiente sicuro e in modalità sandbox. Ciò consente di eseguire direttamente all'interno del kernel un'ampia gamma di attività correlate alla rete, come il filtraggio di pacchetti, il monitoraggio traffico, l'applicazione della sicurezzae persino l'analisi dei protocolli personalizzati.
  • Uno dei principali vantaggi dell'eBPF è la sua versatilità e prestazioni. Eseguendo all'interno del kernel, i programmi eBPF possono accedere e modificare direttamente i pacchetti di rete, ridurre significativamente il sovraccarico rispetto ai metodi tradizionali di elaborazione dei pacchetti nello spazio utente. Inoltre, i programmi eBPF possono essere caricati dinamicamente e collegati a vari hook all'interno del kernel, consentendo lavelocità di risposta in tempo reale e l'adattabilità alle mutevoli condizioni della rete.
  • eBPF è diventato sempre più popolare nelle applicazioni di rete e di sicurezza moderne grazie alla sua flessibilità ed efficienza. Viene ampiamente usato in strumenti e framework per il monitoraggio della rete, il rilevamento delle intrusioni, l'analisi del trafficoe l'ottimizzazione delle prestazioni. Inoltre, le sue funzionalità si estendono oltre la rete ad altre aree di osservabilità e controllo del sistema, rendendolo un blocco predefinito fondamentale per un'ampia gamma di applicazioni e servizi basati su Linux.

• Criteri di Azure per Kubernetes: Un pod che estende l'open-source Gatekeeper v3 e si registra come webhook per il controllo di ammissione di Kubernetes, rendendo possibile l'applicazione di imposizione e di misure di sicurezza su larga scala 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.

Dettagli del componente agente di 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

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 chiamata CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Se l'estensione è abilitata da Defender per contenitori,Defender per il cloud crea un'identità negli ambienti del cliente chiamata CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Assegnare: 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

• 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 clusterRoleBinding tra l'identità creata e il servizio Azure Kubernetes ClusterRole:trustedaccessrole:defender-containers:microsoft-defender-operator. ClusterRole è visibile tramite l'API e concede a Defender per il cloud l'autorizzazione di lettura del piano dati all'interno del cluster.

Ottenere l'accesso sicuro per le risorse di Azure nel servizio Azure Kubernetes usando Accesso attendibile (anteprima)

Molti servizi di Azure che si integrano con il servizio Azure Kubernetes devono accedere al server API Kubernetes. Per evitare di concedere a questi servizi l'accesso amministratore o rendere pubblici i cluster del servizio Azure Kubernetes per l'accesso alla rete, è possibile usare la funzionalità Accesso attendibile del servizio Azure Kubernetes.

Questa funzionalità consente ai servizi di accedere in modo sicuro al servizio Azure Kubernetes e a Kubernetes usando il back-end di Azure senza richiedere un endpoint privato. Anziché basarsi sulle identità dotate delle autorizzazioni di Microsoft Entra, questa funzionalità può usare l'identità gestita assegnata dal sistema per eseguire l'autenticazione con i servizi gestiti e le applicazioni da usare con i cluster del servizio Azure Kubernetes.

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto tecnico per un'operazione ottimale.

Nota

L'API Accesso attendibile è disponibile a livello generale. È disponibile il supporto della disponibilità generale per l'interfaccia della riga di comando di Azure, ma è ancora in anteprima e richiede l'uso dell'estensione aks-preview.

Panoramica della funzionalità Accesso attendibile

Accesso attendibile risolve gli scenari seguenti:

• Se un intervallo IP autorizzato è impostato o si trova in un cluster privato, i servizi di Azure potrebbero non essere in grado di accedere al server API Kubernetes, a meno che non si implementi un modello di accesso endpoint privato.
• Concedere a un amministratore del servizio di Azure l'accesso all'API Kubernetes non segue la procedura consigliata per l'accesso con privilegi minimi e può causare l'escalation dei privilegi o il rischio di perdita di credenziali. Ad esempio, potrebbe essere necessario implementare autorizzazioni con privilegi elevati da servizio a servizio, che non sono l'ideale per una verifica di controllo.

È possibile usare l'Accesso attendibile per concedere il consenso esplicito all'identità gestita assegnata dal sistema delle risorse consentite per accedere ai cluster servizio Azure Kubernetes usando una risorsa di Azure denominata associazione di ruoli. Le risorse di Azure accedono ai cluster servizio Azure Kubernetes tramite il gateway a livello di area del servizio Azure Kubernetes tramite l'autenticazione dell'identità gestita assegnata dal sistema. Le autorizzazioni Kubernetes appropriate vengono assegnate tramite una risorsa di Azure denominata ruolo. Tramite l'accesso attendibile, è possibile accedere a cluster del servizio Azure Kubernetes con diverse configurazioni, tra cui, a titolo esemplificativo, cluster privati, cluster con account locali disattivati, cluster Microsoft Entra e cluster con intervallo IP autorizzato.

Prerequisiti

• Un account Azure con una sottoscrizione attiva. Creare un account gratuitamente.

• Tipi di risorse che supportano l'identità gestita assegnata dal sistema.

  • Se si usa l'interfaccia della riga di comando di Azure, è necessaria l'estensione aks-preview versione 0.5.74 o successiva.

• Per informazioni sui ruoli da usare in scenari diversi, vedere gli articoli seguenti:

  • Accesso ad Azure Machine Learning ai cluster del servizio Azure Kubernetes con configurazioni speciali
  • Che cos'è il servizio di backup di Azure Kubernetes?
  • Attivare un comportamento del contenitore senza agente

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: una soluzione basata su agente, installata su 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:
• Agente di Defender: Il 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. L'agente viene registrato con 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. L'agente di Defender viene distribuito come estensione Kubernetes abilitata per Arc.
• Criteri di Azure per Kubernetes: Un pod che estende l'open-source Gatekeeper v3 e si registra come webhook per il controllo di ammissione di Kubernetes, rendendo possibile l'applicazione di imposizione e di misure di sicurezza su larga scala 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 Informazioni su Criteri di Azure per i cluster Kubernetes.
  

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 di Microsoft Defender per il cloud per ulteriori analisi.
• Kubernetes con abilitazione di Azure Arc - Kubernetes con abilitazione di Azure Arc: una soluzione basata su agente, installata su 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:
• Agente di Defender: Il DaemonSet che viene distribuito su ogni nodo, raccoglie i segnali dagli host usando la tecnologia eBPF e fornisce una protezione runtime. L'agente viene registrato con 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. L'agente di Defender viene distribuito come estensione Kubernetes abilitata per Arc.
• Criteri di Azure per Kubernetes: Un pod che estende l'open-source Gatekeeper v3 e si registra come webhook per il controllo di ammissione di Kubernetes, rendendo possibile l'applicazione di imposizione e di misure di sicurezza su larga scala 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.

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:

• Crea:

  • Defender per il cloud MDCContainersAgentlessDiscoveryK8sRole deve essere aggiunto ad aws-auth ConfigMap dei cluster EKS. Il nome può essere personalizzato.
    

• Assegna: Defender for Cloud assegna al ruolo MDCContainersAgentlessDiscoveryK8sRole le 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.

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 del log di controllo tramite un agente di raccolta senza agente e invia le informazioni raccolte al back-end di Microsoft Defender per il cloud per ulteriori analisi.
• Kubernetes con abilitazione di Azure Arc - Kubernetes con abilitazione di Azure Arc: una soluzione basata su agente, installata su 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:
• Agente di Defender: Il DaemonSet che viene distribuito su ogni nodo, raccoglie i segnali dagli host usando la tecnologia eBPF e fornisce una protezione runtime. L'agente viene registrato con 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. L'agente di Defender viene distribuito come estensione Kubernetes abilitata per Arc.
• Criteri di Azure per Kubernetes: Un pod che estende l'open-source Gatekeeper v3 e si registra come webhook per il controllo di ammissione di Kubernetes, rendendo possibile l'applicazione di imposizione e di misure di sicurezza su larga scala 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.

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:

• Crea:

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

• Assegnare: 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
  • Container.viewer del ruolo predefinito

• 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.

Continua