Architektura Defenderu pro kontejnery

Dokončeno

Defender for Containers je pro každé prostředí Kubernetes navržený jinak, ať už běží:

• Azure Kubernetes Service (AKS) – spravovaná služba Microsoftu pro vývoj, nasazování a správu kontejnerizovaných aplikací.
  
• Amazon Elastic Kubernetes Service (EKS) v připojeném účtu Amazon Web Services (AWS) – spravovaná služba Amazonu pro spouštění Kubernetes na AWS bez nutnosti instalovat, provozovat a udržovat vlastní řídicí rovinu nebo uzly Kubernetes.
  
• Google Kubernetes Engine (GKE) v připojeném projektu Google Cloud Platform (GCP) – spravované prostředí Google pro nasazování, správu a škálování aplikací pomocí infrastruktury GCP.
  
• Nespravovaná distribuce Kubernetes (pomocí Kubernetes s podporou Azure Arc) – Cloud Native Computing Foundation (CNCF) certifikovaných clusterů Kubernetes hostovaných místně nebo v IaaS.

Pokud chcete chránit kontejnery Kubernetes, Defender for Containers přijímá a analyzuje:

• Protokoly auditu a události zabezpečení ze serveru rozhraní API
• Informace o konfiguraci clusteru z řídicí roviny
• Konfigurace úloh ze služby Azure Policy
• Signály zabezpečení a události na úrovni uzlu

Architektura pro každé prostředí Kubernetes

Diagram architektury clusterů Defenderu pro cloud a AKS

Když Defender pro cloud chrání cluster hostovaný ve službě Azure Kubernetes Service, shromažďování dat protokolu auditu je bez agentů a shromažďuje se automaticky prostřednictvím infrastruktury Azure bez dalších nákladů ani konfigurace. Jedná se o požadované komponenty pro získání úplné ochrany, kterou nabízí Microsoft Defender for Containers:

• Agent Defender: Démon DaemonSet, který je nasazený na každém uzlu, shromažďuje signály od hostitelů pomocí technologie *Extended Berkeley Packet Filter (eBPF) a poskytuje ochranu za běhu. Agent je zaregistrovaný v pracovním prostoru služby Log Analytics a používá se jako datový kanál. Data protokolu auditu ale nejsou uložená v pracovním prostoru služby Log Analytics. Agent Defenderu se nasadí jako profil zabezpečení AKS.

  • *eBPF Background and Information*: Extended Berkeley Packet Filter (eBPF) je výkonná a všestranná architektura v rámci jádra Linuxu pro programovou analýzu a filtrování síťových paketů a provádění různých dalších úloh na úrovni systému. Původně založený na filtru paketů Berkeley (BPF) zavedený v 1990s, eBPF rozšiřuje své schopnosti tím, že umožňuje uživatelem definované programy spouštět v rámci jádra, což umožňuje dynamické a efektivní zpracování paketů bez nutnosti úprav samotného jádra.
  • Programy eBPF jsou napsané v omezené podmnožině jazyka C a jsou načteny do jádra, kde se spouštějí v zabezpečeném prostředí a v izolovaném prostoru (sandbox). To umožňuje provádět celou řadu úloh souvisejících se sítí přímo v jádru, jako je filtrování paketů, monitorování provozu, vynucení zabezpečení a dokonce analýza vlastních protokolů.
  • Jednou z klíčových výhod eBPF je její všestrannost a výkon. Při provádění v rámci jádra můžou programy eBPF přistupovat k síťovým paketům a manipulovat s nimi přímo, což výrazně snižuje režii v porovnání s tradičními metodami zpracování paketů v uživatelském prostoru. Kromě toho lze programy eBPF dynamicky načítat a připojovat k různým hákům v jádru, což umožňuje odezvu v reálném čase a přizpůsobitelnost měnící se síťové podmínky.
  • EBPF se díky své flexibilitě a efektivitě stala stále oblíbenější v moderních síťových a bezpečnostních aplikacích. Běžně se používá v nástrojích a architekturách pro monitorování sítě, detekci neoprávněných vniknutí, analýzu provozu a ladění výkonu. Kromě toho její možnosti přesahují sítě do jiných oblastí pozorovatelnosti a kontroly systému, což z něj dělá základní stavební blok pro širokou škálu linuxových aplikací a služeb.

• Azure Policy pro Kubernetes: Pod, který rozšiřuje opensourcový Gatekeeper v3 a zaregistruje se jako webový háček na řízení přístupu Kubernetes, který umožňuje použít vynucení ve velkém měřítku a bezpečnostní opatření v clusterech centralizovaným a konzistentním způsobem. Pod Azure Policy pro Kubernetes se nasadí jako doplněk AKS. Je nainstalovaný jenom na jednom uzlu v clusteru.

Podrobnosti o komponentě agenta Defenderu

Název podu	Namespace	Kind	Krátký popis	Možnosti	Omezení prostředků	Požadováno výchozí přenos dat
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Sadakontejnerůch	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	paměť: 296Mi cpu: 360m	No
microsoft-defender-collector-misc-*	kube-system	Nasazení	Sada kontejnerů, které se zaměřují na shromažďování událostí inventáře a zabezpečení z prostředí Kubernetes, které nejsou vázané na konkrétní uzel.	–	paměť: 64Mi cpu: 60m	No
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Publikujte shromážděná data do back-endové služby Microsoft Defender for Containers, ve které se budou data zpracovávat a analyzovat.	–	paměť: 200Mi cpu: 60m	Https 443

Jak funguje zjišťování bez agentů pro Kubernetes v Azure?

Proces zjišťování vychází ze snímků pořízených v intervalech:

Když povolíte zjišťování bez agentů pro rozšíření Kubernetes, dojde k následujícímu procesu:

• Vytvořit:

  • Pokud je rozšíření v programu Defender CSPM povolené, vytvoří Defender pro cloud identitu v zákaznických prostředích s názvem CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Pokud je rozšíření povolené z Defenderu pro kontejnery, Vytvoří Defender pro cloud identitu v zákaznických prostředích s názvem CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Přiřazení: Defender pro cloud přiřadí této identitě v oboru předplatného předdefinované role označované jako operátor Kubernetes Agentless. Role obsahuje následující oprávnění:
  • Čtení AKS (Microsoft.ContainerService/managedClusters/read)
    
  • Důvěryhodný přístup AKS s následujícími oprávněními:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Zjišťování: Pomocí identity přiřazené systémem provede Defender for Cloud zjišťování clusterů AKS ve vašem prostředí pomocí volání rozhraní API na server AKS.

• Vazba: Při zjišťování clusteru AKS provede Defender pro cloud operaci vazby AKS vytvořením vazby clusteru mezi vytvořenou identitou a rolí clusteru Kubernetes aks:trustedaccessrole:defender-containers:microsoft-defender-defender-operator. Role clusteru je viditelná prostřednictvím rozhraní API a poskytuje Defenderu pro čtení roviny dat v cloudu v clusteru oprávnění.

Získání zabezpečeného přístupu k prostředkům Azure ve službě Azure Kubernetes Service pomocí důvěryhodného přístupu (Preview)

Řada služeb Azure, které se integrují se službou Azure Kubernetes Service (AKS), potřebují přístup k serveru rozhraní API Kubernetes. Abyste se vyhnuli udělení přístupu správcům těchto služeb nebo zpřístupnění clusterů AKS pro přístup k síti, můžete použít funkci důvěryhodného přístupu AKS.

Tato funkce poskytuje službám zabezpečený přístup k AKS a Kubernetes pomocí back-endu Azure bez nutnosti privátního koncového bodu. Místo toho, abyste se museli spoléhat na identity, které mají oprávnění Microsoft Entra, může tato funkce použít spravovanou identitu přiřazenou systémem k ověřování pomocí spravovaných služeb a aplikací, které chcete používat s clustery AKS.

Důležité

Funkce AKS ve verzi Preview jsou k dispozici na samoobslužné bázi. Verze Preview jsou poskytovány "tak, jak jsou" a "dostupné", a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Verze Preview AKS jsou částečně pokryty zákaznickou podporou na základě maximálního úsilí.

Poznámka:

Rozhraní API důvěryhodného přístupu je obecně dostupné. Poskytujeme podporu obecné dostupnosti (GA) pro Azure CLI, ale je stále ve verzi Preview a vyžaduje použití rozšíření aks-Preview.

Přehled funkcí důvěryhodného přístupu

Důvěryhodný přístup řeší následující scénáře:

• Pokud je autorizovaný rozsah IP adres nastavený nebo v privátním clusteru, nemusí mít služby Azure přístup k serveru rozhraní API Kubernetes, pokud neimplementujete model přístupu privátního koncového bodu.
• Poskytnutí přístupu správce služby Azure k rozhraní Kubernetes API nedodržuje osvědčený postup přístupu s nejnižšími oprávněními a může vést k eskalaci oprávnění nebo riziku úniku přihlašovacích údajů. Možná budete muset například implementovat oprávnění mezi službami s vysokou úrovní oprávnění a nejsou ideální v kontrole auditu.

Důvěryhodný přístup můžete použít k udělení výslovného souhlasu se spravovanou identitou přiřazenou systémem povolených prostředků pro přístup ke clusterům AKS pomocí prostředku Azure označovaného jako vazby role. Vaše prostředky Azure přistupují ke clusterům AKS prostřednictvím regionální brány AKS prostřednictvím ověřování spravované identity přiřazené systémem. Příslušná oprávnění Kubernetes se přiřazují prostřednictvím prostředku Azure označovaného jako role. Prostřednictvím důvěryhodného přístupu můžete přistupovat ke clusterům AKS s různými konfiguracemi, mezi které patří mimo jiné privátní clustery, clustery, které mají vypnuté místní účty, clustery Microsoft Entra a autorizované clustery rozsahu IP adres.

Požadavky

• Účet Azure s aktivním předplatným. Vytvoření účtu zdarma

• Typy prostředků, které podporují spravovanou identitu přiřazenou systémem

  • Pokud používáte Azure CLI, vyžaduje se rozšíření aks-Preview verze 0.5.74 nebo novější.

• Informace o rolích, které se mají použít v různých scénářích, najdete v těchto článcích:

  • Přístup ke clusterům AKS ve službě Azure Machine Learning se speciálními konfiguracemi
  • Co je zálohování služby Azure Kubernetes Service?
  • Zapnutí stavu kontejneru bez agentů

Diagram architektury clusterů Kubernetes s podporou služby Defender pro cloud a Arc

K získání úplné ochrany, kterou nabízí Microsoft Defender for Containers, se vyžadují tyto komponenty:

• Kubernetes s podporou Azure Arc – Kubernetes s podporou Azure Arc – řešení založené na agentech nainstalovaném na jednom uzlu v clusteru, které propojuje vaše clustery s defenderem pro cloud. Defender for Cloud pak dokáže nasadit následující dva agenty jako rozšíření Arc:
• Agent Defender: Démon DaemonSet, který je nasazený na každém uzlu, shromažďuje hostitelské signály pomocí technologie eBPF a protokolů auditu Kubernetes za účelem zajištění ochrany za běhu. Agent je zaregistrovaný v pracovním prostoru služby Log Analytics a používá se jako datový kanál. Data protokolu auditu ale nejsou uložená v pracovním prostoru služby Log Analytics. Agent Defenderu se nasadí jako rozšíření Kubernetes s podporou Arc.
• Azure Policy pro Kubernetes: Pod, který rozšiřuje opensourcový Gatekeeper v3 a zaregistruje se jako webový háček na řízení přístupu Kubernetes, který umožňuje použít vynucení ve velkém měřítku a bezpečnostní opatření v clusterech centralizovaným a konzistentním způsobem. Pod Azure Policy pro Kubernetes se nasadí jako rozšíření Kubernetes s podporou Arc. Je nainstalovaný jenom na jednom uzlu v clusteru. Další informace najdete v tématu Ochrana úloh Kubernetes a vysvětlení azure Policy pro clustery Kubernetes.
  

Diagram architektury clusterů Defender for Cloud a EKS

Když Defender pro cloud chrání cluster hostovaný ve službě Elastic Kubernetes Service, kolekce dat protokolu auditu je bez agentů. Jedná se o požadované komponenty pro získání úplné ochrany, kterou nabízí Microsoft Defender for Containers:

• Protokoly auditu Kubernetes – CloudWatch účtu AWS umožňuje a shromažďuje data protokolu auditu prostřednictvím kolektoru bez agentů a odesílá shromážděné informace do back-endu Microsoft Defenderu for Cloud za účelem další analýzy.
• Kubernetes s podporou Azure Arc – Kubernetes s podporou Azure Arc – řešení založené na agentech nainstalovaném na jednom uzlu v clusteru, které propojuje vaše clustery s defenderem pro cloud. Defender for Cloud pak dokáže nasadit následující dva agenty jako rozšíření Arc:
• Agent Defender: DaemonSet, který je nasazený na každém uzlu, shromažďuje signály od hostitelů pomocí technologie eBPF a poskytuje ochranu za běhu. Agent je zaregistrovaný v pracovním prostoru služby Log Analytics a používá se jako datový kanál. Data protokolu auditu ale nejsou uložená v pracovním prostoru služby Log Analytics. Agent Defenderu se nasadí jako rozšíření Kubernetes s podporou Arc.
• Azure Policy pro Kubernetes: Pod, který rozšiřuje opensourcový Gatekeeper v3 a zaregistruje se jako webový háček na řízení přístupu Kubernetes, který umožňuje použít vynucení ve velkém měřítku a bezpečnostní opatření v clusterech centralizovaným a konzistentním způsobem. Pod Azure Policy pro Kubernetes se nasadí jako rozšíření Kubernetes s podporou Arc. Je nainstalovaný jenom na jednom uzlu v clusteru.

Jak funguje zjišťování bez agentů pro Kubernetes v AWS?

Proces zjišťování vychází ze snímků pořízených v intervalech:

Když povolíte zjišťování bez agentů pro rozšíření Kubernetes, dojde k následujícímu procesu:

• Vytvořit:

  • Role Defender pro cloud MDCContainersAgentlessDiscoveryK8sRole musí být přidána do aws-auth ConfigMap clusterů EKS. Název lze přizpůsobit.
    

• Přiřadit: Defender pro cloud přiřadí roli MDCContainersAgentlessDiscoveryK8sRole následující oprávnění:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Zjišťování: Pomocí identity přiřazené systémem provede Defender for Cloud zjišťování clusterů EKS ve vašem prostředí pomocí volání rozhraní API na server EKS.

Diagram architektury clusterů Defender for Cloud a GKE

Když Defender for Cloud chrání cluster hostovaný v Google Kubernetes Engine, kolekce dat protokolu auditu je bez agentů. Jedná se o požadované komponenty pro získání úplné ochrany, kterou nabízí Microsoft Defender for Containers:

• Protokoly auditu Kubernetes – Protokolování cloudu GCP umožňuje a shromažďuje data protokolu auditu prostřednictvím kolektoru bez agentů a odesílá shromážděné informace do back-endu Microsoft Defenderu for Cloud za účelem další analýzy.
• Kubernetes s podporou Azure Arc – Kubernetes s podporou Azure Arc – řešení založené na agentech nainstalovaném na jednom uzlu v clusteru, které propojuje vaše clustery s defenderem pro cloud. Defender for Cloud pak dokáže nasadit následující dva agenty jako rozšíření Arc:
• Agent Defender: DaemonSet, který je nasazený na každém uzlu, shromažďuje signály od hostitelů pomocí technologie eBPF a poskytuje ochranu za běhu. Agent je zaregistrovaný v pracovním prostoru služby Log Analytics a používá se jako datový kanál. Data protokolu auditu ale nejsou uložená v pracovním prostoru služby Log Analytics. Agent Defenderu se nasadí jako rozšíření Kubernetes s podporou Arc.
• Azure Policy pro Kubernetes: Pod, který rozšiřuje opensourcový Gatekeeper v3 a zaregistruje se jako webový háček na řízení přístupu Kubernetes, který umožňuje použít vynucení ve velkém měřítku a bezpečnostní opatření v clusterech centralizovaným a konzistentním způsobem. Pod Azure Policy pro Kubernetes se nasadí jako rozšíření Kubernetes s podporou Arc. Stačí ho nainstalovat jenom na jeden uzel v clusteru.

Jak funguje zjišťování bez agentů pro Kubernetes v GCP?

Proces zjišťování vychází ze snímků pořízených v intervalech:

Když povolíte zjišťování bez agentů pro rozšíření Kubernetes, dojde k následujícímu procesu:

• Vytvořit:

  • Vytvoří se účet služby mdc-containers-k8s-operator. Název lze přizpůsobit.

• Přiřadit: Defender for Cloud připojí následující role k účtu služby mdc-containers-k8s-operator:

  • Vlastní role MDCGkeClusterWriteRole, která má oprávnění container.clusters.update
  • Integrovaný kontejner role.viewer

• Zjišťování: Pomocí identity přiřazené systémem provede Defender for Cloud zjišťování clusterů GKE ve vašem prostředí pomocí volání rozhraní API na server GKE.