Architektura usługi Defender for Containers

Ukończone

Usługa Defender for Containers jest zaprojektowana inaczej dla każdego środowiska Kubernetes, niezależnie od tego, czy działają w:

• Azure Kubernetes Service (AKS) — zarządzana usługa firmy Microsoft do tworzenia, wdrażania i zarządzania aplikacjami konteneryzowanymi.
  
• Amazon Elastic Kubernetes Service (EKS) na połączonym koncie usług Amazon Web Services (AWS) — zarządzana usługa Amazon do uruchamiania rozwiązania Kubernetes na platformie AWS bez konieczności instalowania, obsługi i obsługi własnej płaszczyzny sterowania lub węzłów platformy Kubernetes.
  
• Google Kubernetes Engine (GKE) w połączonym projekcie Google Cloud Platform (GCP) — zarządzane środowisko Google do wdrażania, zarządzania i skalowania aplikacji przy użyciu infrastruktury GCP.
  
• Niezarządzana dystrybucja Kubernetes (przy użyciu platformy Kubernetes z włączoną usługą Azure Arc) — certyfikowane klastry Kubernetes (Cloud Native Computing Foundation) hostowane lokalnie lub w usłudze IaaS.

Aby chronić kontenery Kubernetes, usługa Defender for Containers odbiera i analizuje:

• Dzienniki inspekcji i zdarzenia zabezpieczeń z serwera interfejsu API
• Informacje o konfiguracji klastra z płaszczyzny sterowania
• Konfiguracja obciążenia z usługi Azure Policy
• Sygnały zabezpieczeń i zdarzenia z poziomu węzła

Architektura dla każdego środowiska Kubernetes

Diagram architektury klastrów Defender dla Chmury i AKS

Gdy Defender dla Chmury chroni klaster hostowany w usłudze Azure Kubernetes Service, zbieranie danych dziennika inspekcji jest bez agenta i zbierane automatycznie za pośrednictwem infrastruktury platformy Azure bez dodatkowych kosztów ani zagadnień dotyczących konfiguracji. Są to wymagane składniki w celu uzyskania pełnej ochrony oferowanej przez usługę Microsoft Defender for Containers:

• Agent usługi Defender: zestaw DaemonSet wdrożony w każdym węźle, zbiera sygnały z hostów przy użyciu technologii *Rozszerzonego filtru pakietów Berkeley (eBPF) i zapewnia ochronę środowiska uruchomieniowego. Agent jest zarejestrowany w obszarze roboczym usługi Log Analytics i używany jako potok danych. Jednak dane dziennika inspekcji nie są przechowywane w obszarze roboczym usługi Log Analytics. Agent usługi Defender jest wdrażany jako profil zabezpieczeń usługi AKS.

  • *eBPF Background and Information*: Extended Berkeley Packet Filter (eBPF) to zaawansowana i wszechstronna struktura w jądrze systemu Linux do programowego analizowania i filtrowania pakietów sieciowych, a także wykonywania różnych innych zadań na poziomie systemu. Pierwotnie oparte na Berkeley Packet Filter (BPF) wprowadzone w 1990 roku, eBPF rozszerza swoje możliwości, umożliwiając uruchamianie programów zdefiniowanych przez użytkownika w jądrze, umożliwiając dynamiczne i wydajne przetwarzanie pakietów bez konieczności modyfikacji samego jądra.
  • Programy eBPF są zapisywane w ograniczonym podzestawie języka C i są ładowane do jądra, gdzie są wykonywane w bezpiecznym i piaskownicy środowiska. Dzięki temu można wykonywać wiele zadań związanych z siecią bezpośrednio w jądrze, takich jak filtrowanie pakietów, monitorowanie ruchu, wymuszanie zabezpieczeń, a nawet analizowanie niestandardowych protokołów.
  • Jedną z kluczowych zalet eBPF jest jego wszechstronność i wydajność. Wykonując w jądrze, programy eBPF mogą uzyskiwać bezpośredni dostęp do pakietów sieciowych i manipulować nimi, co znacznie zmniejsza obciążenie w porównaniu z tradycyjnymi metodami przetwarzania pakietów przestrzeni użytkownika. Ponadto programy eBPF można dynamicznie ładować i dołączać do różnych punktów zaczepienia w jądrze, co pozwala na czas odpowiedzi w czasie rzeczywistym i adaptację do zmieniających się warunków sieciowych.
  • EBPF stał się coraz bardziej popularny w nowoczesnych aplikacjach sieciowych i zabezpieczających ze względu na jego elastyczność i wydajność. Jest on szeroko używany w narzędziach i strukturach do monitorowania sieci, wykrywania włamań, analizy ruchu i dostrajania wydajności. Ponadto jego możliwości wykraczają poza sieć do innych obszarów obserwacji i kontroli systemu, dzięki czemu jest to podstawowy blok konstrukcyjny dla szerokiej gamy aplikacji i usług opartych na systemie Linux.

• Usługa Azure Policy dla platformy Kubernetes: zasobnik, który rozszerza usługę Gatekeeper w wersji 3 typu open source i rejestruje się jako element webhook do kontroli wpływu na platformę Kubernetes, umożliwiając stosowanie wymuszania na dużą skalę i zabezpieczenia w klastrach w sposób scentralizowany i spójny. Zasobnik usługi Azure Policy for Kubernetes jest wdrażany jako dodatek usługi AKS. Jest on instalowany tylko w jednym węźle w klastrze.

Szczegóły składnika agenta usługi Defender

Nazwa zasobnika	Przestrzeń nazw	Rodzaj	Krótki opis	Możliwości	Limity zasobów	Wymagany ruch wychodzący
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Zestaw kontenerów, które koncentrują się na zbieraniu spisu i zdarzeń zabezpieczeń ze środowiska Kubernetes.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	pamięć: 296Mi procesor: 360 m	Nie.
microsoft-defender-collector-misc-*	kube-system	Wdrożenie	Zestaw kontenerów, które koncentrują się na zbieraniu spisu i zdarzeń zabezpieczeń ze środowiska Kubernetes, które nie są powiązane z określonym węzłem.	Nie dotyczy	pamięć: 64Mi procesor: 60 m	Nie.
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Opublikuj zebrane dane w usłudze zaplecza usługi Microsoft Defender for Containers, w której dane będą przetwarzane i analizowane.	Nie dotyczy	pamięć: 200Mi procesor: 60 m	Https 443

Jak działa odnajdywanie bez agenta dla platformy Kubernetes na platformie Azure?

Proces odnajdywania jest oparty na migawkach wykonanych w odstępach czasu:

Po włączeniu odnajdywania bez agenta dla rozszerzenia Kubernetes następuje następujący proces:

• Utwórz:

  • Jeśli rozszerzenie jest włączone z poziomu CSPM w usłudze Defender, Defender dla Chmury tworzy tożsamość w środowiskach klienta o nazwie CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Jeśli rozszerzenie jest włączone z usługi Defender for Containers, Defender dla Chmury tworzy tożsamość w środowiskach klienta o nazwie CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Przypisz: Defender dla Chmury przypisuje wbudowaną rolę o nazwie Operator bez agenta Kubernetes do tej tożsamości w zakresie subskrypcji. Rola zawiera następujące uprawnienia:
  • Odczyt usługi AKS (Microsoft.ContainerService/managedClusters/read)
    
  • Dostęp zaufany usługi AKS z następującymi uprawnieniami:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Odnajdywanie: przy użyciu tożsamości przypisanej przez system Defender dla Chmury wykonuje odnajdywanie klastrów usługi AKS w środowisku przy użyciu wywołań interfejsu API do serwera interfejsu API usługi AKS.

• Powiązanie: po odnalezieniu klastra usługi AKS Defender dla Chmury wykonuje operację powiązania usługi AKS, tworząc klasterRoleBinding między utworzoną tożsamością a klastrem Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. Element ClusterRole jest widoczny za pośrednictwem interfejsu API i daje Defender dla Chmury uprawnienia do odczytu płaszczyzny danych w klastrze.

Uzyskiwanie bezpiecznego dostępu do zasobów platformy Azure w usłudze Azure Kubernetes Service przy użyciu zaufanego dostępu (wersja zapoznawcza)

Wiele usług platformy Azure, które integrują się z usługą Azure Kubernetes Service (AKS), wymaga dostępu do serwera interfejsu API Kubernetes. Aby uniknąć przyznania tym usługom dostępu administratora lub upublicznieniu klastrów usługi AKS w celu uzyskania dostępu do sieci, możesz użyć funkcji zaufanego dostępu usługi AKS.

Ta funkcja zapewnia usługom bezpieczny dostęp do usług AKS i Kubernetes przy użyciu zaplecza platformy Azure bez konieczności używania prywatnego punktu końcowego. Zamiast polegać na tożsamościach, które mają uprawnienia firmy Microsoft Entra, ta funkcja może używać przypisanej przez system tożsamości zarządzanej do uwierzytelniania za pomocą usług zarządzanych i aplikacji, które mają być używane z klastrami usługi AKS.

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów.

Uwaga

Interfejs API zaufanego dostępu jest ogólnie dostępny. Udostępniamy ogólną obsługę interfejsu wiersza polecenia platformy Azure, ale jest ona nadal dostępna w wersji zapoznawczej i wymaga użycia rozszerzenia aks-preview.

Omówienie funkcji zaufanego dostępu

Zaufany dostęp dotyczy następujących scenariuszy:

• Jeśli autoryzowany zakres adresów IP jest ustawiony lub w klastrze prywatnym, usługi platformy Azure mogą nie być w stanie uzyskać dostępu do serwera interfejsu API Kubernetes, chyba że zaimplementowano model dostępu do prywatnego punktu końcowego.
• Udzielenie administratorowi usługi platformy Azure dostępu do interfejsu API platformy Kubernetes nie jest zgodne z najlepszymi rozwiązaniami dotyczącymi najniższych uprawnień i może prowadzić do eskalacji uprawnień lub ryzyka wycieku poświadczeń. Na przykład może być konieczne zaimplementowanie uprawnień usługi z wysokimi uprawnieniami uprzywilejowanych i nie są one idealne w przeglądzie inspekcji.

Za pomocą zaufanego dostępu możesz wyrazić jawną zgodę na tożsamość zarządzaną przypisaną przez system dozwolonych zasobów w celu uzyskania dostępu do klastrów usługi AKS przy użyciu zasobu platformy Azure nazywanego powiązaniem roli. Zasoby platformy Azure uzyskują dostęp do klastrów usługi AKS za pośrednictwem bramy regionalnej usługi AKS za pośrednictwem uwierzytelniania tożsamości zarządzanej przypisanej przez system. Odpowiednie uprawnienia platformy Kubernetes są przypisywane za pośrednictwem zasobu platformy Azure nazywanego rolą. Za pomocą zaufanego dostępu można uzyskiwać dostęp do klastrów usługi AKS z różnymi konfiguracjami, w tym między innymi z klastrami prywatnymi, klastrami, które mają wyłączone konta lokalne, klastrami Firmy Microsoft Entra i autoryzowanymi klastrami zakresów adresów IP.

Wymagania wstępne

• Konto platformy Azure z aktywną subskrypcją. Utwórz konto bezpłatnie.

• Typy zasobów, które obsługują tożsamość zarządzaną przypisaną przez system.

  • Jeśli używasz interfejsu wiersza polecenia platformy Azure, wymagane jest rozszerzenie aks-preview w wersji 0.5.74 lub nowszej.

• Aby dowiedzieć się, jakie role mają być używane w różnych scenariuszach, zobacz następujące artykuły:

  • Dostęp usługi Azure Machine Learning do klastrów usługi AKS przy użyciu specjalnych konfiguracji
  • Co to jest kopia zapasowa usługi Azure Kubernetes Service?
  • Włączanie stanu kontenera bez agenta

Diagram architektury klastrów Kubernetes z obsługą Defender dla Chmury i z obsługą usługi Arc

Te składniki są wymagane w celu uzyskania pełnej ochrony oferowanej przez usługę Microsoft Defender for Containers:

• Kubernetes z obsługą usługi Azure Arc — platforma Kubernetes z obsługą usługi Azure Arc — rozwiązanie oparte na agencie zainstalowane w jednym węźle w klastrze, które łączy klastry z Defender dla Chmury. Defender dla Chmury następnie można wdrożyć następujących dwóch agentów jako rozszerzenia usługi Arc:
• Agent usługi Defender: zestaw DaemonSet wdrożony w każdym węźle zbiera sygnały hosta przy użyciu technologii eBPF i dzienników inspekcji platformy Kubernetes w celu zapewnienia ochrony środowiska uruchomieniowego. Agent jest zarejestrowany w obszarze roboczym usługi Log Analytics i używany jako potok danych. Jednak dane dziennika inspekcji nie są przechowywane w obszarze roboczym usługi Log Analytics. Agent usługi Defender jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc.
• Usługa Azure Policy dla platformy Kubernetes: zasobnik, który rozszerza usługę Gatekeeper w wersji 3 typu open source i rejestruje się jako element webhook do kontroli wpływu na platformę Kubernetes, umożliwiając stosowanie wymuszania na dużą skalę i zabezpieczenia w klastrach w sposób scentralizowany i spójny. Zasobnik usługi Azure Policy dla platformy Kubernetes jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc. Jest on instalowany tylko w jednym węźle w klastrze. Aby uzyskać więcej informacji, zobacz Protect your Kubernetes workloads (Ochrona obciążeń Kubernetes) i Understand Azure Policy for Kubernetes clusters (Ochrona obciążeń platformy Kubernetes) i Understand Azure Policy for Kubernetes clusters (Omówienie usługi Azure Policy dla klastrów Kubernetes).
  

Diagram architektury klastrów Defender dla Chmury i EKS

Gdy Defender dla Chmury chroni klaster hostowany w usłudze Elastic Kubernetes Service, zbieranie danych dziennika inspekcji jest bez agenta. Są to wymagane składniki w celu uzyskania pełnej ochrony oferowanej przez usługę Microsoft Defender for Containers:

• Dzienniki inspekcji platformy Kubernetes — usługa CloudWatch konta platformy AWS umożliwia i zbiera dane dziennika inspekcji za pośrednictwem modułu zbierającego bez agenta i wysyła zebrane informacje do zaplecza platformy Microsoft Defender dla Chmury w celu dalszej analizy.
• Kubernetes z obsługą usługi Azure Arc — platforma Kubernetes z obsługą usługi Azure Arc — rozwiązanie oparte na agencie zainstalowane w jednym węźle w klastrze, które łączy klastry z Defender dla Chmury. Defender dla Chmury następnie można wdrożyć następujących dwóch agentów jako rozszerzenia usługi Arc:
• Agent usługi Defender: zestaw DaemonSet wdrożony w każdym węźle, zbiera sygnały z hostów przy użyciu technologii eBPF i zapewnia ochronę środowiska uruchomieniowego. Agent jest zarejestrowany w obszarze roboczym usługi Log Analytics i używany jako potok danych. Jednak dane dziennika inspekcji nie są przechowywane w obszarze roboczym usługi Log Analytics. Agent usługi Defender jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc.
• Usługa Azure Policy dla platformy Kubernetes: zasobnik, który rozszerza usługę Gatekeeper w wersji 3 typu open source i rejestruje się jako element webhook do kontroli wpływu na platformę Kubernetes, umożliwiając stosowanie wymuszania na dużą skalę i zabezpieczenia w klastrach w sposób scentralizowany i spójny. Zasobnik usługi Azure Policy dla platformy Kubernetes jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc. Jest on instalowany tylko w jednym węźle w klastrze.

Jak działa odnajdywanie bez agenta dla platformy Kubernetes na platformie AWS?

Proces odnajdywania jest oparty na migawkach wykonanych w odstępach czasu:

Po włączeniu odnajdywania bez agenta dla rozszerzenia Kubernetes następuje następujący proces:

• Utwórz:

  • Rola Defender dla Chmury MDCContainersAgentlessDiscoveryK8sRole musi zostać dodana do mapy konfiguracji aws-auth klastrów EKS. Nazwę można dostosować.
    

• Przypisz: Defender dla Chmury przypisuje rolę MDCContainersAgentlessDiscoveryK8sRole następującymi uprawnieniami:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Odnajdywanie: przy użyciu tożsamości przypisanej przez system Defender dla Chmury wykonuje odnajdywanie klastrów EKS w środowisku przy użyciu wywołań interfejsu API do serwera eks interfejsu API.

Diagram architektury klastrów Defender dla Chmury i GKE

Gdy Defender dla Chmury chroni klaster hostowany w aucie Google Kubernetes Engine, zbieranie danych dziennika inspekcji jest bez agenta. Są to wymagane składniki w celu uzyskania pełnej ochrony oferowanej przez usługę Microsoft Defender for Containers:

• Dzienniki inspekcji platformy Kubernetes — funkcja rejestrowania chmury GCP umożliwia i zbiera dane dziennika inspekcji za pośrednictwem modułu zbierającego bez agenta i wysyła zebrane informacje do zaplecza Microsoft Defender dla Chmury w celu dalszej analizy.
• Kubernetes z obsługą usługi Azure Arc — platforma Kubernetes z obsługą usługi Azure Arc — rozwiązanie oparte na agencie zainstalowane w jednym węźle w klastrze, które łączy klastry z Defender dla Chmury. Defender dla Chmury następnie można wdrożyć następujących dwóch agentów jako rozszerzenia usługi Arc:
• Agent usługi Defender: zestaw DaemonSet wdrożony w każdym węźle, zbiera sygnały z hostów przy użyciu technologii eBPF i zapewnia ochronę środowiska uruchomieniowego. Agent jest zarejestrowany w obszarze roboczym usługi Log Analytics i używany jako potok danych. Jednak dane dziennika inspekcji nie są przechowywane w obszarze roboczym usługi Log Analytics. Agent usługi Defender jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc.
• Usługa Azure Policy dla platformy Kubernetes: zasobnik, który rozszerza usługę Gatekeeper w wersji 3 typu open source i rejestruje się jako element webhook do kontroli wpływu na platformę Kubernetes, umożliwiając stosowanie wymuszania na dużą skalę i zabezpieczenia w klastrach w sposób scentralizowany i spójny. Zasobnik usługi Azure Policy dla platformy Kubernetes jest wdrażany jako rozszerzenie Kubernetes z obsługą usługi Arc. Należy go zainstalować tylko w jednym węźle w klastrze.

Jak działa odnajdywanie bez agenta dla platformy Kubernetes w GCP?

Proces odnajdywania jest oparty na migawkach wykonanych w odstępach czasu:

Po włączeniu odnajdywania bez agenta dla rozszerzenia Kubernetes następuje następujący proces:

• Utwórz:

  • Konto usługi mdc-containers-k8s-operator jest tworzone. Nazwę można dostosować.

• Przypisz: Defender dla Chmury dołącza następujące role do konta usługi mdc-containers-k8s-operator:

  • Rola niestandardowa MDCGkeClusterWriteRole, która ma uprawnienie container.clusters.update
  • Wbudowana rola container.viewer

• Odnajdywanie: przy użyciu tożsamości przypisanej przez system Defender dla Chmury wykonuje odnajdywanie klastrów GKE w środowisku przy użyciu wywołań interfejsu API do serwera interfejsu API GKE.