Architectuur van Defender for Containers

Voltooid

Defender for Containers is voor elke Kubernetes-omgeving anders ontworpen, ongeacht of deze worden uitgevoerd:

• Azure Kubernetes Service (AKS): de beheerde service van Microsoft voor het ontwikkelen, implementeren en beheren van toepassingen in containers.
  
• Amazon Elastic Kubernetes Service (EKS) in een verbonden AWS-account (Amazon Web Services): de beheerde service van Amazon voor het uitvoeren van Kubernetes op AWS zonder dat u uw eigen Kubernetes-besturingsvlak of -knooppunten hoeft te installeren, te gebruiken en te onderhouden.
  
• Google Kubernetes Engine (GKE) in een verbonden GCP-project (Google Cloud Platform): de beheerde omgeving van Google voor het implementeren, beheren en schalen van toepassingen met behulp van GCP-infrastructuur.
  
• Een onbeheerde Kubernetes-distributie (met behulp van Kubernetes met Azure Arc) - CncF-gecertificeerde Kubernetes-clusters (Cloud Native Computing Foundation) die on-premises of op IaaS worden gehost.

Om uw Kubernetes-containers te beveiligen, ontvangt en analyseert Defender for Containers:

• Auditlogboeken en beveiligingsgebeurtenissen van de API-server
• Informatie over clusterconfiguratie vanuit het besturingsvlak
• Workloadconfiguratie van Azure Policy
• Beveiligingssignalen en gebeurtenissen van het knooppuntniveau

Architectuur voor elke Kubernetes-omgeving

Architectuurdiagram van Defender voor Cloud- en AKS-clusters

Wanneer Defender voor Cloud een cluster beveiligt dat wordt gehost in Azure Kubernetes Service, is de verzameling auditlogboekgegevens zonder agent en automatisch verzameld via de Azure-infrastructuur zonder extra kosten of configuratieoverwegingen. Dit zijn de vereiste onderdelen om de volledige beveiliging van Microsoft Defender for Containers te ontvangen:

• Defender-agent: De DaemonSet die op elk knooppunt wordt geïmplementeerd, verzamelt signalen van hosts met behulp van de technologie *Extended Berkeley Packet Filter (eBPF)* en biedt runtimebeveiliging. De agent is geregistreerd bij een Log Analytics-werkruimte en wordt gebruikt als gegevenspijplijn. De auditlogboekgegevens worden echter niet opgeslagen in de Log Analytics-werkruimte. De Defender-agent wordt geïmplementeerd als een AKS-beveiligingsprofiel.

  • *eBPF Background and Information*: Het Extended Berkeley Packet Filter (eBPF) is een krachtig en veelzijdig framework binnen de Linux-kernel voor programmatisch analyseren en filteren van netwerkpakketten, evenals het uitvoeren van verschillende andere taken op systeemniveau. Oorspronkelijk gebaseerd op het Berkeley Packet Filter (BPF) dat in de jaren '990 werd geïntroduceerd, breidt eBPF uit op de mogelijkheden door gebruikers gedefinieerde programma's toe te staan om in de kernel te worden uitgevoerd, waardoor dynamische en efficiënte pakketverwerking mogelijk is zonder dat de kernel zelf hoeft te worden gewijzigd.
  • eBPF-programma's worden geschreven in een beperkte subset van C en worden in de kernel geladen, waar ze worden uitgevoerd binnen een beveiligde en sandbox-omgeving. Hierdoor kan een breed scala aan netwerkgerelateerde taken rechtstreeks binnen de kernel worden uitgevoerd, zoals pakketfiltering, verkeersbewaking, beveiligings afdwinging en zelfs aangepaste protocolparsering.
  • Een van de belangrijkste voordelen van eBPF is zijn veelzijdigheid en prestaties. Door de kernel uit te voeren, kunnen eBPF-programma's rechtstreeks netwerkpakketten openen en bewerken, waardoor de overhead aanzienlijk wordt verminderd ten opzichte van traditionele verwerkingsmethoden voor gebruikersruimtepakketten. Daarnaast kunnen eBPF-programma's dynamisch worden geladen en gekoppeld aan verschillende haken binnen de kernel, waardoor realtime reactietijd en aanpassingsvermogen aan veranderende netwerkomstandigheden mogelijk zijn.
  • eBPF is steeds populairder geworden in moderne netwerk- en beveiligingstoepassingen vanwege de flexibiliteit en efficiëntie. Het wordt veel gebruikt in hulpprogramma's en frameworks voor netwerkbewaking, inbraakdetectie, verkeersanalyse en prestaties afstemmen. Bovendien zijn de mogelijkheden verder dan netwerken naar andere gebieden van waarneembaarheid en controle van het systeem, waardoor het een fundamentele bouwsteen is voor een breed scala aan Linux-toepassingen en -services.

• Azure Policy voor Kubernetes: een pod die de opensource Gatekeeper v3 uitbreidt en zich registreert als een webhook op Kubernetes-toegangsbeheer, zodat het mogelijk is om afdwinging op schaal toe te passen en beveiligingsmaatregelen op uw clusters op een gecentraliseerde, consistente manier te waarborgen. De Azure Policy voor Kubernetes-pod wordt geïmplementeerd als een AKS-invoegtoepassing. Het is slechts geïnstalleerd op één knooppunt in het cluster.

Details van defender-agentonderdeel

Podnaam	Naamruimte	Soort	Korte beschrijving	Mogelijkheden	Bronlimieten	Uitgaand verkeer vereist
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Een set containers die zich richten op het verzamelen van inventaris- en beveiligingsevenementen uit de Kubernetes-omgeving.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	geheugen: 296Mi cpu: 360m	Nee
microsoft-defender-collector-misc-*	kube-system	Implementatie	Een set containers die zich richten op het verzamelen van inventaris- en beveiligingsgebeurtenissen uit de Kubernetes-omgeving die niet zijn gebonden aan een specifiek knooppunt.	N.v.t.	geheugen: 64Mi cpu: 60 min.	Nee
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Publiceer de verzamelde gegevens naar de back-endservice van Microsoft Defender for Containers waar de gegevens worden verwerkt en geanalyseerd.	N.v.t.	geheugen: 200Mi cpu: 60 min.	Https 443

Hoe werkt detectie zonder agent voor Kubernetes in Azure?

Het detectieproces is gebaseerd op momentopnamen die met intervallen zijn gemaakt:

Wanneer u de detectie zonder agent inschakelt voor de Kubernetes-extensie, wordt het volgende proces uitgevoerd:

• Maken:

  • Als de extensie is ingeschakeld vanuit Defender CSPM, maakt Defender voor Cloud een identiteit in klantomgevingen met de naam CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Als de extensie is ingeschakeld vanuit Defender for Containers, maakt Defender voor Cloud een identiteit in klantomgevingen met de naam CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Toewijzen: Defender voor Cloud wijst een ingebouwde rol met de naam Kubernetes Agentless Operator toe aan die identiteit op abonnementsniveau. De rol bevat de volgende machtigingen:
  • AKS-lezen (Microsoft.ContainerService/managedClusters/read)
    
  • Vertrouwde AKS-toegang met de volgende machtigingen:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Detecteren: Met behulp van de door het systeem toegewezen identiteit voert Defender voor Cloud een detectie uit van de AKS-clusters in uw omgeving met behulp van API-aanroepen naar de API-server van AKS.

• Bind: Bij detectie van een AKS-cluster voert Defender voor Cloud een AKS-bindingsbewerking uit door een ClusterRoleBinding te maken tussen de gemaakte identiteit en de Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. ClusterRole is zichtbaar via API en geeft Defender voor Cloud leesmachtiging voor het gegevensvlak in het cluster.

Veilige toegang krijgen voor Azure-resources in Azure Kubernetes Service met behulp van vertrouwde toegang (preview)

Veel Azure-services die integreren met Azure Kubernetes Service (AKS) hebben toegang nodig tot de Kubernetes API-server. U kunt de functie Vertrouwde toegang tot AKS gebruiken om te voorkomen dat deze services beheerderstoegang verlenen of uw AKS-clusters openbaar maken voor netwerktoegang.

Deze functie biedt services veilige toegang tot AKS en Kubernetes met behulp van de Azure-back-end zonder dat hiervoor een privé-eindpunt nodig is. In plaats van te vertrouwen op identiteiten met Microsoft Entra-machtigingen, kan deze functie uw door het systeem toegewezen beheerde identiteit gebruiken om te verifiëren met de beheerde services en toepassingen die u wilt gebruiken met uw AKS-clusters.

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort.

Notitie

De Trusted Access-API is algemeen beschikbaar. We bieden algemene beschikbaarheidsondersteuning voor de Azure CLI, maar deze is nog in preview en vereist het gebruik van de aks-preview-extensie.

Overzicht van vertrouwde toegangsfuncties

Vertrouwde toegang heeft betrekking op de volgende scenario's:

• Als een geautoriseerd IP-bereik is ingesteld of zich in een privécluster bevindt, hebben Azure-services mogelijk geen toegang tot de Kubernetes-API-server, tenzij u een toegangsmodel voor privé-eindpunten implementeert.
• Het verlenen van toegang door een Azure-servicebeheerder tot de Kubernetes-API volgt niet de best practice voor toegang met minimale bevoegdheden en kan leiden tot escalatie van bevoegdheden of het risico op lekken van referenties. U moet bijvoorbeeld machtigingen voor service-naar-service met hoge bevoegdheden implementeren en ze zijn niet ideaal in een controlebeoordeling.

U kunt Vertrouwde toegang gebruiken om expliciet toestemming te geven voor uw door het systeem toegewezen beheerde identiteit van toegestane resources voor toegang tot uw AKS-clusters met behulp van een Azure-resource die een rolbinding wordt genoemd. Uw Azure-resources hebben toegang tot AKS-clusters via de regionale AKS-gateway via door het systeem toegewezen beheerde identiteitverificatie. De juiste Kubernetes-machtigingen worden toegewezen via een Azure-resource die een rol wordt genoemd. Via Vertrouwde toegang hebt u toegang tot AKS-clusters met verschillende configuraties, waaronder maar niet beperkt tot privéclusters, clusters waarvoor lokale accounts zijn uitgeschakeld, Microsoft Entra-clusters en geautoriseerde IP-bereikclusters.

Vereisten

• Een Azure-account met een actief abonnement. Gratis een account maken

• Resourcetypen die door het systeem toegewezen beheerde identiteit ondersteunen.

  • Als u de Azure CLI gebruikt, is de aks-preview-extensie versie 0.5.74 of hoger vereist.

• Zie de volgende artikelen voor meer informatie over welke rollen in verschillende scenario's moeten worden gebruikt:

  • Azure Machine Learning-toegang tot AKS-clusters met speciale configuraties
  • Wat is Azure Kubernetes Service backup?
  • Een containerpostuur zonder agent inschakelen

Architectuurdiagram van kubernetes-clusters met Defender voor Cloud en Kubernetes met Arc

Deze onderdelen zijn vereist om de volledige beveiliging te ontvangen die wordt geboden door Microsoft Defender for Containers:

• Kubernetes met Azure Arc - Kubernetes met Azure Arc: een oplossing op basis van agents, geïnstalleerd op één knooppunt in het cluster, die uw clusters verbindt met Defender voor Cloud. Defender voor Cloud vervolgens de volgende twee agents als Arc-extensies kunt implementeren:
• Defender-agent: De DaemonSet die op elk knooppunt wordt geïmplementeerd, verzamelt hostsignalen met behulp van eBPF-technologie en Kubernetes-auditlogboeken om runtimebeveiliging te bieden. De agent is geregistreerd bij een Log Analytics-werkruimte en wordt gebruikt als gegevenspijplijn. De auditlogboekgegevens worden echter niet opgeslagen in de Log Analytics-werkruimte. De Defender-agent wordt geïmplementeerd als een Kubernetes-extensie met Arc.
• Azure Policy voor Kubernetes: een pod die de opensource Gatekeeper v3 uitbreidt en zich registreert als een webhook op Kubernetes-toegangsbeheer, zodat het mogelijk is om afdwinging op schaal toe te passen en beveiligingsmaatregelen op uw clusters op een gecentraliseerde, consistente manier te waarborgen. De Azure Policy voor Kubernetes-pod wordt geïmplementeerd als een Kubernetes-extensie met Arc. Het is slechts geïnstalleerd op één knooppunt in het cluster. Zie Uw Kubernetes-workloads beveiligen en Inzicht in Azure Policy voor Kubernetes-clusters voor meer informatie.
  

Architectuurdiagram van Defender voor Cloud- en EKS-clusters

Wanneer Defender voor Cloud een cluster beveiligt dat wordt gehost in Elastic Kubernetes Service, is de verzameling auditlogboekgegevens zonder agent. Dit zijn de vereiste onderdelen om de volledige beveiliging van Microsoft Defender for Containers te ontvangen:

• Kubernetes-auditlogboeken: CloudWatch van het AWS-account maakt het mogelijk en verzamelt auditlogboekgegevens via een collector zonder agent en verzendt de verzamelde gegevens naar de Microsoft Defender voor Cloud back-end voor verdere analyse.
• Kubernetes met Azure Arc - Kubernetes met Azure Arc: een oplossing op basis van agents, geïnstalleerd op één knooppunt in het cluster, die uw clusters verbindt met Defender voor Cloud. Defender voor Cloud vervolgens de volgende twee agents als Arc-extensies kunt implementeren:
• Defender-agent: De DaemonSet die op elk knooppunt wordt geïmplementeerd, verzamelt signalen van hosts met behulp van eBPF-technologie en biedt runtimebeveiliging. De agent is geregistreerd bij een Log Analytics-werkruimte en wordt gebruikt als gegevenspijplijn. De auditlogboekgegevens worden echter niet opgeslagen in de Log Analytics-werkruimte. De Defender-agent wordt geïmplementeerd als een Kubernetes-extensie met Arc.
• Azure Policy voor Kubernetes: een pod die de opensource Gatekeeper v3 uitbreidt en zich registreert als een webhook op Kubernetes-toegangsbeheer, zodat het mogelijk is om afdwinging op schaal toe te passen en beveiligingsmaatregelen op uw clusters op een gecentraliseerde, consistente manier te waarborgen. De Azure Policy voor Kubernetes-pod wordt geïmplementeerd als een Kubernetes-extensie met Arc. Het is slechts geïnstalleerd op één knooppunt in het cluster.

Hoe werkt detectie zonder agent voor Kubernetes in AWS?

Het detectieproces is gebaseerd op momentopnamen die met intervallen zijn gemaakt:

Wanneer u de detectie zonder agent inschakelt voor de Kubernetes-extensie, wordt het volgende proces uitgevoerd:

• Maken:

  • De Defender voor Cloud rol MDCContainersAgentlessDiscoveryK8sRole moet worden toegevoegd aan de aws-auth ConfigMap van de EKS-clusters. De naam kan worden aangepast.
    

• Toewijzen: Defender voor Cloud de rol MDCContainersAgentlessDiscoveryK8sRole de volgende machtigingen toewijst:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Detecteren: Met behulp van de door het systeem toegewezen identiteit voert Defender voor Cloud een detectie uit van de EKS-clusters in uw omgeving met behulp van API-aanroepen naar de API-server van EKS.

Architectuurdiagram van Defender voor Cloud- en GKE-clusters

Wanneer Defender voor Cloud een cluster beveiligt dat wordt gehost in Google Kubernetes Engine, is de verzameling auditlogboekgegevens zonder agent. Dit zijn de vereiste onderdelen om de volledige beveiliging van Microsoft Defender for Containers te ontvangen:

• Kubernetes-auditlogboeken: GCP Cloud Logging maakt het mogelijk en verzamelt auditlogboekgegevens via een collector zonder agent en verzendt de verzamelde gegevens naar de Microsoft Defender voor Cloud back-end voor verdere analyse.
• Kubernetes met Azure Arc - Kubernetes met Azure Arc: een oplossing op basis van agents, geïnstalleerd op één knooppunt in het cluster, die uw clusters verbindt met Defender voor Cloud. Defender voor Cloud vervolgens de volgende twee agents als Arc-extensies kunt implementeren:
• Defender-agent: De DaemonSet die op elk knooppunt wordt geïmplementeerd, verzamelt signalen van hosts met behulp van eBPF-technologie en biedt runtimebeveiliging. De agent is geregistreerd bij een Log Analytics-werkruimte en wordt gebruikt als gegevenspijplijn. De auditlogboekgegevens worden echter niet opgeslagen in de Log Analytics-werkruimte. De Defender-agent wordt geïmplementeerd als een Kubernetes-extensie met Arc.
• Azure Policy voor Kubernetes: een pod die de opensource Gatekeeper v3 uitbreidt en zich registreert als een webhook op Kubernetes-toegangsbeheer, zodat het mogelijk is om afdwinging op schaal toe te passen en beveiligingsmaatregelen op uw clusters op een gecentraliseerde, consistente manier te waarborgen. De Azure Policy voor Kubernetes-pod wordt geïmplementeerd als een Kubernetes-extensie met Arc. Het hoeft slechts op één knooppunt in het cluster te worden geïnstalleerd.

Hoe werkt detectie zonder agent voor Kubernetes in GCP?

Het detectieproces is gebaseerd op momentopnamen die met intervallen zijn gemaakt:

Wanneer u de detectie zonder agent inschakelt voor de Kubernetes-extensie, wordt het volgende proces uitgevoerd:

• Maken:

  • De serviceaccount mdc-containers-k8s-operator wordt gemaakt. De naam kan worden aangepast.

• Toewijzen: Defender voor Cloud koppelt de volgende rollen aan de mdc-containers-k8s-operator van het serviceaccount:

  • De aangepaste rol MDCGkeClusterWriteRole, die de machtiging container.clusters.update heeft
  • De ingebouwde rolcontainer.viewer

• Detecteren: Met behulp van de door het systeem toegewezen identiteit voert Defender voor Cloud een detectie uit van de GKE-clusters in uw omgeving met behulp van API-aanroepen naar de API-server van GKE.