Architektur von Microsoft Defender für Container

Abgeschlossen

Microsoft Defender für Container ist für jede Kubernetes-Umgebung unterschiedlich konzipiert, abhängig davon, in welcher Umgebung sie ausgeführt werden:

• Azure Kubernetes Service (AKS) - Der verwaltete Dienst von Microsoft für die Entwicklung, Bereitstellung und Verwaltung von containerisierten Anwendungen.
  
• Amazon Elastic Kubernetes Service (EKS) in einem verbundenen Amazon Web Services -Konto (AWS) - Der verwaltete Amazon-Dienst zum Ausführen von Kubernetes in AWS, ohne dass Sie Ihre eigene Kubernetes-Steuerungsebene oder -Knoten installieren, betreiben und verwalten müssen.
  
• Google Kubernetes Engine (GKE) in einem GCP-Projekt (Connected Google Cloud Platform): Die verwaltete Google-Umgebung zum Bereitstellen, Verwalten und Skalieren von Anwendungen mithilfe der GCP-Infrastruktur.
  
• Eine nicht verwaltete Kubernetes-Distribution (mit Azure Arc-fähigen Kubernetes) – CLOUD Native Computing Foundation (CSVF) zertifizierte Kubernetes-Cluster, die lokal oder auf IaaS gehostet werden.

Um Ihre Kubernetes-Container zu schützen, empfängt und analysiert Microsoft Defender für Container:

• Überwachungsprotokolle und Sicherheitsereignisse vom API-Server
• Clusterkonfigurationsinformationen von der Steuerungsebene
• Workloadkonfiguration von Azure Policy
• Sicherheitssignale und -ereignisse auf Knotenebene

Architektur für die einzelnen Kubernetes-Umgebungen

Architekturdiagramm von Defender für Cloud- und AKS-Cluster

Wenn Defender for Cloud einen in Azure Kubernetes Service gehosteten Cluster schützt, erfolgt die Sammlung von Überwachungsprotokolldaten ohne Agent, und die Daten werden automatisch über die Azure-Infrastruktur gesammelt, ohne dass zusätzliche Kosten anfallen oder Konfigurationsüberlegungen erforderlich sind. Diese Komponenten sind erforderlich, um den vollständigen Schutz von Microsoft Defender for Containers zu erhalten:

• Defender-Agent: Das DaemonSet, das auf jedem Knoten bereitgestellt wird, sammelt Signale von Hosts mit der Technologie *Extended Berkeley Packet Filter (eBPF) undbietet Laufzeitschutz. Der Agent wird bei einem Log Analytics-Arbeitsbereich registriert und als Datenpipeline verwendet. Die Überwachungsprotokolldaten werden jedoch nicht im Log Analytics-Arbeitsbereich gespeichert. Der Defender-Agent wird als AKS-Sicherheitsprofil bereitgestellt.

  • *eBPF-Hintergrund und Informationen*: Der Extended Berkeley Packet Filter (eBPF) ist ein leistungsfähiges und vielseitiges Framework innerhalb des Linux-Kernels zum programmgesteuerten Analysieren und Filtern von Netzwerkpaketensowie zum Ausführen verschiedener anderer Aufgaben auf Systemebene. Ursprünglich basierend auf dem in den 1990er Jahren eingeführten Berkeley Packet Filter (BPF) erweitert eBPF seine Funktionen, indem benutzerdefinierte Programme innerhalb des Kernelsausgeführt werden können, wodurch dynamische und effiziente Paketverarbeitung ermöglicht wird, ohne dass Änderungen am Kernel selbst erforderlich sind.
  • eBPF-Programme werden in einer eingeschränkten Teilmenge von C geschrieben und in den Kernel geladen, in dem sie in einer sicheren und sandkastenbasierten Umgebung ausgeführt werden. Dies ermöglicht eine breite Palette von netzwerkbezogenen Aufgaben, die direkt im Kernel ausgeführt werden können, z . B. Paketfilterung, Datenverkehrsüberwachung, Sicherheitserzwingungund sogar benutzerdefinierte Protokollanalyse.
  • Einer der wichtigsten Vorteile von eBPF ist seine Vielseitigkeit und Leistung. Durch die Ausführung innerhalb des Kernels können eBPF-Programme direkt auf Netzwerkpakete zugreifenunddiese bearbeiten, wodurch der Aufwand im Vergleich zu herkömmlichen Benutzerraumpaketverarbeitungsmethoden erheblich reduziert wird. Darüber hinaus können eBPF-Programme dynamisch geladen und an verschiedene Hooks innerhalb des Kernels angefügt werden, sodass die Reaktionsfähigkeit in Echtzeit und die Anpassungsfähigkeit an sich ändernde Netzwerkbedingungen ermöglicht wird.
  • eBPF ist aufgrund seiner Flexibilität und Effizienz in modernen Netzwerk- und Sicherheitsanwendungen immer beliebter geworden. Es wird häufig in Tools und Frameworks für Netzwerküberwachung, Angriffserkennung, Datenverkehrsanalyse und Leistungsoptimierungverwendet. Darüber hinaus erweitern sich seine Funktionen über das Netzwerk hinaus auf andere Bereiche der Systembeobachtbarkeit und -steuerung, wodurch es zu einem grundlegenden Baustein für eine vielzahl linuxbasierter Anwendungen und Dienste wird.

• Azure Policy für Kubernetes: Damit ist ein Pod gemeint, der den Open-Source-Gatekeeper v3 erweitert und sich als Webhook bei der Kubernetes-Zugangssteuerung registriert sowie das zentrale, konsistente Anwenden von Skalierungs- und Sicherheitsvorkehrungen in Ihren Clustern ermöglicht. Der Azure Policy für Kubernetes-Pod wird als AKS-Add-On bereitgestellt. Sie ist nur auf einem Knoten im Clusterinstalliert.

Details zu den Komponenten des Defender-Agents

Podname	Namespace	Variante	Kurze Beschreibung:	Capabilities	Ressourceneinschränkungen	Ausgang erforderlich
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Eine Gruppe von Containern, die sich auf das Sammeln von Inventur- und Sicherheitsereignissen aus der Kubernetes-Umgebung konzentrieren.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	Arbeitsspeicher: 296 Mi CPU: 360 m	Nein
microsoft-defender-collector-misc-*	kube-system	Bereitstellung	Eine Gruppe von Containern, die sich auf das Sammeln von Inventur- und Sicherheitsereignissen aus der Kubernetes-Umgebung konzentrieren und nicht an einen bestimmten Knoten gebunden sind.	–	Arbeitsspeicher: 64 Mi cpu: 60 m	Nein
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Veröffentlichen Sie die gesammelten Daten im Back-End-Dienst von Microsoft Defender für Container, in dem die Daten verarbeitet und analysiert werden.	–	Arbeitsspeicher: 200Mi cpu: 60 m	Https: 443

Wie funktioniert die Ermittlung ohne Agent für Kubernetes in Azure?

Der Ermittlungsprozess basiert auf Momentaufnahmen, die in Intervallen erstellt werden:

Wenn Sie die agentlose Ermittlung für die Kubernetes-Erweiterung aktivieren, tritt der folgende Prozess auf:

• Erstellen:

  • Wenn die Erweiterung von Defender CSPM aktiviert ist, erstellt Defender für Cloud eine Identität in Kundenumgebungen namens CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Wenn die Erweiterung aus Defender für Container aktiviert ist, erstellt Defender für Cloud eine Identität in Kundenumgebungen namens CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Zuweisen: Defender für Cloud weist dieser Identität im Abonnementbereich eine integrierte Rolle namens Kubernetes Agentless Operator zu. Die Rolle enthält die folgenden Berechtigungen:
  • AKS gelesen (Microsoft.ContainerService/managedClusters/read)
    
  • AKS Trusted Access mit den folgenden Berechtigungen:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Ermitteln: Mithilfe der systemseitig zugewiesenen Identität führt Defender for Cloud eine Ermittlung der AKS-Cluster in Ihrer Umgebung mithilfe von API-Aufrufen an den API-Server von AKS durch.

• Bind: Bei der Ermittlung eines AKS-Clusters führt Defender for Cloud einen AKS-Bindungsvorgang durch Erstellen einer ClusterRoleBinding zwischen der erstellten Identität und dem Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator aus. ClusterRole ist über DIE API sichtbar und gibt Defender für Cloud-Datenebene Leseberechtigungen innerhalb des Clusters.

Erhalten Sie sicheren Zugriff auf Azure-Ressourcen im Azure Kubernetes Service mithilfe von vertrauenswürdigem Zugriff (Vorschau)

Viele Azure-Dienste, die in Azure Kubernetes Service (AKS) integriert sind, benötigen Zugriff auf den Kubernetes-API-Server. Damit diesen Diensten kein Administratorzugriff gewährt werden muss und Ihre AKS-Cluster nicht für Netzwerkzugriff öffentlich gemacht werden müssen, können Sie das AKS-Feature „Vertrauenswürdiger Zugriff“ verwenden.

Dieses Feature bietet Diensten sicheren Zugriff auf AKS und Kubernetes mithilfe des Azure-Back-Ends, ohne dass ein privater Endpunkt erforderlich ist. Anstatt auf Identitäten mit Microsoft Entra-Berechtigungen zurückzugreifen, kann dieses Feature Ihre systemseitig zugewiesene verwaltete Identität verwenden, um sich bei den verwalteten Diensten und Anwendungen zu authentifizieren, die Sie mit Ihren AKS-Clustern verwenden möchten.

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt.

Hinweis

Die API für vertrauenswürdigen Zugriff ist allgemein verfügbar. Wir bieten zwar GA-Support (General Availability, allgemeine Verfügbarkeit) für die Azure CLI, sie befindet sich aber weiterhin in der Vorschauphase und erfordert die Verwendung der Erweiterung „aks-preview“.

Übersicht über die Funktion „Vertrauenswürdiger Zugriff“

Vertrauenswürdiger Zugriff kann in folgenden Szenarien hilfreich sein:

• Wenn ein autorisierter IP-Adressbereich festgelegt ist oder sich in einem privaten Cluster befindet, muss ggf. ein Zugriffsmodell für private Endpunkte implementiert werden, damit Azure-Dienste auf den Kubernetes-API-Server zugreifen können.
• Die Gewährung von Administratorzugriff auf die Kubernetes-API für einen Azure-Dienst entspricht nicht der bewährten Methode für Zugriff mit geringsten Rechten und kann eine Rechteausweitung oder die Offenlegung von Anmeldeinformationen zur Folge haben. Beispielsweise müssen Sie möglicherweise Dienst-zu-Dienst-Berechtigungen mit umfangreichen Rechten implementieren, was bei Überprüfungen nicht ideal ist.

Mithilfe des vertrauenswürdigen Zugriffs können Sie Ihrer systemseitig zugewiesenen verwalteten Identität von zulässigen Ressourcen mithilfe einer als Rollenbindung bezeichneten Azure-Ressource explizit Zugriff auf Ihre AKS-Cluster gewähren. Ihre Azure-Ressourcen greifen über das regionale AKS-Gateway mittels Authentifizierung über systemseitig zugewiesenen verwalteten Identitäten auf AKS-Cluster zu. Die entsprechenden Kubernetes-Berechtigungen werden über eine als Rolle bezeichnete Azure-Ressource zugewiesen. Über vertrauenswürdigen Zugriff können Sie auf AKS-Cluster mit verschiedenen Konfigurationen zugreifen. Hierzu zählen unter anderem private Cluster, Cluster mit deaktivierten lokalen Konten, Microsoft Entra-Cluster und autorisierte IP-Adressbereichscluster.

Voraussetzungen

• Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.

• Ressourcentypen, die systemseitig zugewiesene verwaltete Identitäten unterstützen.

  • Wenn Sie die Azure CLI verwenden, ist die aks-Preview-Erweiterung Version 0.5.74 oder höher erforderlich.

• Weitere Informationen dazu, welche Rollen in verschiedenen Szenarien verwendet werden sollten, finden Sie in den folgenden Artikeln:

  • AzureML-Zugriff auf AKS-Cluster mit speziellen Konfigurationen
  • Was ist die Azure Kubernetes Service-Sicherung?
  • Containerstatus ohne Agent in Defender CSPM

Architekturdiagramm von Defender für Cloud- und Arc-fähigen Kubernetes-Clustern

Diese Komponenten sind erforderlich, um den vollständigen Schutz von Microsoft Defender für Container zu erhalten:

• Azure Arc-fähige Kubernetes – Azure Arc-fähige Kubernetes – Eine agentbasierte Lösung, die auf einem Knoten im Cluster installiert ist und Ihre Cluster mit Defender for Cloud verbindet. Defender for Cloud kann dann die folgenden beiden Agents als Arc-Erweiterungen bereitstellen:
• Defender-Agent: Das DaemonSet, das auf jedem Knoten bereitgestellt wird, sammelt Hostsignale mithilfe von eBPF-Technologie und Kubernetes-Überwachungsprotokollen, um Laufzeitschutz bereitzustellen. Der Agent wird bei einem Log Analytics-Arbeitsbereich registriert und als Datenpipeline verwendet. Die Überwachungsprotokolldaten werden jedoch nicht im Log Analytics-Arbeitsbereich gespeichert. Der Defender-Agent wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt.
• Azure-Richtlinie für Kubernetes: Ein Pod, der den Open-Source Gatekeeper v3 erweitert und sich als Web-Hook bei Kubernetes-Zulassungskontrolle registriert, sodass es möglich ist, skalierte Erzwingungen anzuwenden und Sicherheitsvorkehrungen auf Ihre Cluster in einer zentralen, konsistenten Weise anzuwenden. Der Azure Policy für Kubernetes-Pod wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt. Sie ist nur auf einem Knoten im Cluster installiert. Weitere Informationen finden Sie unter Schützen Ihrer Kubernetes-Workloads und Grundlegendes zu Azure Policy für Kubernetes-Cluster.
  

Architekturdiagramm von Defender für Cloud- und AKS-Cluster

Wenn Defender for Cloud einen in Elastic Kubernetes Service gehosteten Cluster schützt, erfolgt die Erfassung von Überwachungsprotokolldaten ohne Agent. Diese Komponenten sind erforderlich, um den vollständigen Schutz von Microsoft Defender for Containers zu erhalten:

• Kubernetes-Überwachungsprotokolle – CloudWatch des AWS-Kontos ermöglicht und sammelt Überwachungsprotokolldaten über einen agentlosen Sammler und sendet die gesammelten Informationen zur weiteren Analyse an das Microsoft Defender for Cloud-Back-End.
• Azure Arc-fähige Kubernetes – Azure Arc-fähige Kubernetes – Eine agentbasierte Lösung, die auf einem Knoten im Cluster installiert ist und Ihre Cluster mit Defender for Cloud verbindet. Defender for Cloud kann dann die folgenden beiden Agents als Arc-Erweiterungen bereitstellen:
• Defender-Agent: Das DaemonSet, das auf jedem Knoten bereitgestellt wird, sammelt Signale von Hosts mithilfe der eBPF-Technologie und bietet Laufzeitschutz. Der Agent wird bei einem Log Analytics-Arbeitsbereich registriert und als Datenpipeline verwendet. Die Überwachungsprotokolldaten werden jedoch nicht im Log Analytics-Arbeitsbereich gespeichert. Der Defender-Agent wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt.
• Azure-Richtlinie für Kubernetes: Ein Pod, der den Open-Source Gatekeeper v3 erweitert und sich als Web-Hook bei Kubernetes-Zulassungskontrolle registriert, sodass es möglich ist, skalierte Erzwingungen anzuwenden und Sicherheitsvorkehrungen auf Ihre Cluster in einer zentralen, konsistenten Weise anzuwenden. Der Azure Policy für Kubernetes-Pod wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt. Sie ist nur auf einem Knoten im Cluster installiert.

Wie funktioniert agentless Discovery für Kubernetes in AWS?

Der Ermittlungsprozess basiert auf Momentaufnahmen, die in Intervallen erstellt werden:

Wenn Sie die Erweiterung Agentlose Ermittlung für Kubernetes aktivieren, wird der folgende Prozess ausgeführt:

• Erstellen:

  • Die Defender for Cloud-Rolle MDCContainersAgentlessDiscoveryK8sRole muss der aws-auth ConfigMap der EKS-Cluster hinzugefügt werden. Der Name kann angepasst werden.
    

• Zuweisen: Defender für Cloud weist die Rolle „MDCContainersAgentlessDiscoveryK8sRole“ den folgenden Berechtigungen zu:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Ermitteln: Mithilfe der systemseitig zugewiesenen Identität führt Defender for Cloud eine Ermittlung der EKS-Cluster in Ihrer Umgebung mithilfe von API-Aufrufen an den API-Server von EKS durch.

Architekturdiagramm von Defender für Cloud und GKE-Clustern

Wenn Defender for Cloud einen in Google Kubernetes Engine gehosteten Cluster schützt, erfolgt die Erfassung von Überwachungsprotokolldaten ohne Agent. Diese Komponenten sind erforderlich, um den vollständigen Schutz von Microsoft Defender for Containers zu erhalten:

• Kubernetes-Überwachungsprotokolle – GCP Cloud Logging ermöglicht und sammelt Überwachungsprotokolldaten über einen agentlosen Sammler und sendet die gesammelten Informationen zur weiteren Analyse an das Microsoft Defender für Cloud-Back-End.
• Azure Arc-fähige Kubernetes – Azure Arc-fähige Kubernetes – Eine agentbasierte Lösung, die auf einem Knoten im Cluster installiert ist und Ihre Cluster mit Defender for Cloud verbindet. Defender for Cloud kann dann die folgenden beiden Agents als Arc-Erweiterungen bereitstellen:
• Defender-Agent: Das DaemonSet, das auf jedem Knoten bereitgestellt wird, sammelt Signale von Hosts mithilfe der eBPF-Technologie und bietet Laufzeitschutz. Der Agent wird bei einem Log Analytics-Arbeitsbereich registriert und als Datenpipeline verwendet. Die Überwachungsprotokolldaten werden jedoch nicht im Log Analytics-Arbeitsbereich gespeichert. Der Defender-Agent wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt.
• Azure-Richtlinie für Kubernetes: Ein Pod, der den Open-Source Gatekeeper v3 erweitert und sich als Web-Hook bei Kubernetes-Zulassungskontrolle registriert, sodass es möglich ist, skalierte Erzwingungen anzuwenden und Sicherheitsvorkehrungen auf Ihre Cluster in einer zentralen, konsistenten Weise anzuwenden. Der Azure Policy für Kubernetes-Pod wird als Arc-fähige Kubernetes-Erweiterung bereitgestellt. Es muss nur auf einem Knoten im Cluster installiert werden.

Wie funktioniert die Ermittlung ohne Agent für Kubernetes in GCP?

Der Ermittlungsprozess basiert auf Momentaufnahmen, die in Intervallen erstellt werden:

Wenn Sie die Erweiterung Agentlose Ermittlung für Kubernetes aktivieren, wird der folgende Prozess ausgeführt:

• Erstellen:

  • Das Dienstkonto mdc-containers-k8s-operator wird erstellt. Der Name kann angepasst werden.

• Zuweisen: Defender for Cloud fügt die folgenden Rollen an das Dienstkonto mdc-containers-k8s-operator an:

  • Die benutzerdefinierte Rolle MDCGkeClusterWriteRole, die über die Berechtigung "container.clusters.update" verfügt
  • Der integrierte Rollencontainer.viewer

• Ermitteln: Mithilfe der systemseitig zugewiesenen Identität führt Defender for Cloud eine Ermittlung der GKE-Cluster in Ihrer Umgebung mithilfe von API-Aufrufen an den API-Server von GKE durch.