Architettura di Defender per contenitori

Microsoft Defender per contenitori usa più percorsi di connettività per raccogliere segnali di sicurezza e fornire protezione tra registri contenitori e ambienti Kubernetes. La connettività necessaria dipende dalle funzionalità abilitate e dall'ambiente in cui vengono eseguiti i contenitori.

I dettagli di implementazione variano tra Servizio Azure Kubernetes (AKS), Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) e cluster Kubernetes abilitati per Arc.

Altre informazioni sui requisiti di rete, le autorizzazioni e le configurazioni supportate in Informazioni di riferimento su accesso e autorizzazioni di rete per Defender per contenitori.

Panoramica del modello di funzionalità

La tabella seguente illustra come vengono implementati i Defender chiave per le funzionalità dei contenitori e se richiedono componenti nel cluster:

Capability Senza agente Richiede componenti nel cluster interno
Valutazione della vulnerabilità delle immagini Yes NO
Valutazione del comportamento di Kubernetes Yes NO
Rilevamento delle minacce in fase di esecuzione NO Yes
Rilevamento delle minacce del Control plane Yes NO

Connessione ai registri contenitori

La valutazione della vulnerabilità dell'immagine viene attivata quando viene eseguito il push delle immagini nei registri supportati e periodicamente in base alla configurazione del Registro di sistema. Defender per il cloud analizza i metadati delle immagini e i livelli necessari per la valutazione della vulnerabilità. Negli scenari supportati, i risultati della valutazione della vulnerabilità possono essere pubblicati nel Registro di sistema senza modificare l'immagine del contenitore originale. Queste funzionalità non richiedono la distribuzione di componenti nei cluster Kubernetes.

Connessione ai cluster Kubernetes

Microsoft Defender per il cloud si connette all'endpoint dell'API Kubernetes per individuare i cluster, raccogliere i dati di configurazione ed eseguire l'analisi del comportamento e dei rischi. A seconda delle funzionalità abilitate e dell'ambiente, questa connettività può richiedere l'accesso in lettura ai metadati del cluster e, in alcuni scenari, operazioni di scrittura limitate per configurare le associazioni di accesso o le estensioni necessarie.

Dati di runtime inviati dai cluster Kubernetes

I cluster Kubernetes inviano i dati di sicurezza del runtime dai nodi di lavoro al back-end Microsoft Defender per il cloud. Questi dati vengono raccolti da Defender per i componenti dei contenitori in esecuzione nel cluster e inviati in uscita per l'analisi. Questo percorso di connettività supporta il rilevamento delle minacce di runtime e altre funzionalità basate su sensori.

Connessione alle API del provider di servizi cloud

Microsoft Defender per il cloud si connette alle API del provider di servizi cloud per individuare le risorse ed eseguire l'analisi della sicurezza come parte del processo di connessione dell'ambiente cloud. Questo percorso di connettività viene stabilito quando si connette l'ambiente cloud a Microsoft Defender per il cloud.

Log di controllo di Kubernetes inviati dall'infrastruttura cloud

L'infrastruttura cloud invia i log di controllo di Kubernetes a Microsoft Defender per il cloud per il rilevamento delle minacce e l'analisi della sicurezza del control plane. Il metodo usato per raccogliere e inviare log di controllo dipende dal provider di servizi cloud e dall'ambiente in cui vengono eseguiti i cluster Kubernetes.

Supporto per proxy e connettività privata

Defender per i contenitori supporta la connettività in uscita tramite proxy configurati e configurazioni di connettività privata.

Architettura per ogni ambiente Kubernetes

Componenti dell'architettura

Quando Defender per il cloud protegge un cluster ospitato in servizio Azure Kubernetes, raccoglie i dati del log di controllo kubernetes in modo nativo tramite l'infrastruttura Azure senza richiedere agenti o configurazioni aggiuntivi. Per ottenere la protezione completa offerta da Microsoft Defender per contenitori, sono necessari questi componenti:

  • Defender sensor: Un DaemonSet leggero distribuito nei nodi del servizio Azure Kubernetes che raccoglie dati di telemetria di runtime (eventi, processi e dati di rete) usando la tecnologia eBPF. Invia i dati di telemetria in modo sicuro a Defender per il cloud per la protezione dalle minacce in fase di esecuzione. ** Il sensore si registra a una workspace di Log Analytics e funge da pipeline di dati. Tuttavia, i dati del log di audit non vengono archiviati nell'area di lavoro Log Analytics. Il sensore Defender viene distribuito come profilo di sicurezza di AKS, integrato in modo nativo nel Provider di Risorse di AKS.

Annotazioni

Quando si configura il sensore Defender in un cluster del servizio Azure Kubernetes, viene attivato un processo di riconciliazione. Questo processo viene eseguito come parte del piano Defender per contenitori ed è un comportamento atteso.

  • Criteri di Azure per Kubernetes: un pod che estende il Gatekeeper v3 open source e si registra come un webhook al controllo ammissione di Kubernetes. Con questo pod è possibile applicare le imposizione e le 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 di AKS ed è necessario installarlo solo in un nodo del cluster. Offre l'opzione per applicare le regole di configurazione. Altre informazioni sulla protezione del carico di lavoro Kubernetes e Criteri di Azure per Kubernetes.
  • Integrazione ACR: scansione delle immagini attivata dal push e periodica per Registro Azure Container, che fornisce una valutazione delle vulnerabilità senza richiedere componenti aggiuntivi.
  • Agentless discovery: Offre visibilità sui cluster Kubernetes senza richiedere agenti, usando Azure funzionalità native per individuare e valutare le configurazioni del cluster.
  • Analisi senza agente per i computer: Snapshot periodici dei dischi dei nodi Kubernetes per un'analisi approfondita fuori banda della configurazione del sistema operativo e del file system. Questa funzionalità non richiede agenti installati o connettività di rete e non influisce sulle prestazioni del computer.
  • Microsoft integrazione XDR: si integra con la piattaforma estesa di rilevamento e risposta di Microsoft per operazioni di sicurezza unificata e risposta agli eventi imprevisti.

Diagramma dell’architettura generale dell'interazione tra Microsoft Defender per contenitori, il servizio Azure Kubernetes e Criteri di Azure.

Annotazioni

Questi componenti non richiedono connessioni in ingresso ai cluster e usano l'infrastruttura di sicurezza nativa di Azure. Tutti i componenti usano la connettività solo in uscita (non è necessario alcun accesso in ingresso).

Dettagli del componente del sensore Defender

Nome pod Namespace Tipo Breve descrizione Capacità Limiti delle risorse Uscita obbligatoria
microsoft-defender-collector-ds-* kube-system DaemonSet Raccoglie i dati di telemetria di runtime (eventi, processi e dati di rete Kubernetes) dai nodi usando la tecnologia eBPF e li invia in modo sicuro a Defender per il cloud. SYS_ADMIN,
SYS_RESOURCE,
SYS_PTRACE		 memoria: 296Mi

cpu: 360m		 NO
microsoft-defender-collector-misc-* kube-system Distribuzione Raccoglie gli eventi di inventario e sicurezza a livello di cluster che non sono associati a nodi specifici. Non disponibile memoria: 64Mi

CPU: 60m		 NO
microsoft-defender-publisher-ds-* kube-system DaemonSet Pubblica i dati di telemetria raccolti nel servizio back-end di Microsoft Defender per contenitori per l'elaborazione e l'analisi. Non disponibile memoria: 200Mi

CPU: 60m		 Https 443

Altre informazioni sui prerequisiti di accesso in uscita

* Non è possibile configurare i limiti delle risorse. Altre informazioni sui limiti delle risorse kubernetes.

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

Il processo di individuazione usa gli snapshot creati a intervalli:

Diagramma dell'architettura delle autorizzazioni.

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

  • Creare:
    • Se si abilita l'estensione da Defender CSPM, Defender per il cloud crea un'identità nell'ambiente denominato CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    • Se si abilita l'estensione da Defender per contenitori, Defender per il cloud crea un'identità nell'ambiente denominata CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Assign: Defender per il cloud assegna un ruolo predefinito denominato Kubernetes Agentless Operator a tale identità nell'ambito della sottoscrizione. Il ruolo contiene le autorizzazioni seguenti:
    • Lettura AKS (Microsoft.ContainerService/managedClusters/read)
    • Accesso attendibile in AKS con le autorizzazioni seguenti:
      • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
      • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
      • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete Altre informazioni su AKS Trusted Access.
  • Discover: Usando l'identità assegnata dal sistema, Defender per il cloud individua i cluster del servizio Azure Kubernetes nell'ambiente effettuando chiamate API al server API del servizio Azure Kubernetes.
  • Bind: Dopo aver individuato un cluster AKS, Defender per il cloud esegue un'operazione di binding con AKS creando un ClusterRoleBinding tra l'identità creata e il ruolo di accesso sicuro Kubernetes ClusterRoleaks: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.

Annotazioni

Lo snapshot copiato rimane nella stessa area del cluster.

Contenuti correlati

  • Last updated on