Defender for Containers-arkitektur

Slutförd

Defender for Containers är utformat på olika sätt för varje Kubernetes-miljö oavsett om de körs i:

• Azure Kubernetes Service (AKS) – Microsofts hanterade tjänst för att utveckla, distribuera och hantera containerbaserade program.
  
• Amazon Elastic Kubernetes Service (EKS) på ett anslutet AWS-konto (Amazon Web Services) – Amazons hanterade tjänst för att köra Kubernetes på AWS utan att behöva installera, använda och underhålla ett eget Kubernetes-kontrollplan eller -noder.
  
• Google Kubernetes Engine (GKE) i ett anslutet GCP-projekt (Google Cloud Platform) – Googles hanterade miljö för distribution, hantering och skalning av program med GCP-infrastruktur.
  
• En ohanterad Kubernetes-distribution (med Azure Arc-aktiverade Kubernetes) – CNCF-certifierade Kubernetes-kluster (Cloud Native Computing Foundation) som finns lokalt eller på IaaS.

För att skydda dina Kubernetes-containrar tar Defender för containrar emot och analyserar:

• Granska loggar och säkerhetshändelser från API-servern
• Klusterkonfigurationsinformation från kontrollplanet
• Arbetsbelastningskonfiguration från Azure Policy
• Säkerhetssignaler och händelser från nodnivån

Arkitektur för varje Kubernetes-miljö

Arkitekturdiagram över Defender för molnet- och AKS-kluster

När Defender för molnet skyddar ett kluster som finns i Azure Kubernetes Service är insamlingen av granskningsloggdata agentlös och samlas in automatiskt via Azure-infrastrukturen utan extra kostnad eller konfigurationsöverväganden. Det här är de komponenter som krävs för att få det fullständiga skydd som erbjuds av Microsoft Defender för containrar:

• Defender-agent: DaemonSet som distribueras på varje nod, samlar in signaler från värdar med hjälp av eBPF-tekniken (Extended Berkeley Packet Filter) och ger körningsskydd. Agenten registreras med en Log Analytics-arbetsyta och används som en datapipeline. Granskningsloggdata lagras dock inte på Log Analytics-arbetsytan. Defender-agenten distribueras som en AKS-säkerhetsprofil.

  • *eBPF Background and Information*: The Extended Berkeley Packet Filter (eBPF) är ett kraftfullt och mångsidigt ramverk i Linux-kerneln för programmatisk analys och filtrering av nätverkspaket, samt för att utföra olika andra uppgifter på systemnivå. EBPF baserades ursprungligen på Berkeley Packet Filter (BPF) som introducerades på 1990-talet och utökar dess funktioner genom att tillåta användardefinierade program att köras i kerneln, vilket möjliggör dynamisk och effektiv paketbearbetning utan att kräva ändringar i själva kärnan.
  • eBPF-program skrivs i en begränsad delmängd av C och läses in i kerneln, där de körs i en säker och sandbox-miljö. På så sätt kan ett brett spektrum av nätverksrelaterade uppgifter utföras direkt i kerneln, till exempel paketfiltrering, trafikövervakning, säkerhetsövervakning och till och med anpassad protokollparsing.
  • En av de viktigaste fördelarna med eBPF är dess mångsidighet och prestanda. Genom att köra i kerneln kan eBPF-program komma åt och manipulera nätverkspaket direkt, vilket avsevärt minskar kostnaderna jämfört med traditionella bearbetningsmetoder för användarutrymmespaket. Dessutom kan eBPF-program läsas in dynamiskt och kopplas till olika krokar i kerneln, vilket möjliggör realtidsrespons och anpassningsbarhet för förändrade nätverksförhållanden.
  • eBPF har blivit allt populärare i moderna nätverk och säkerhetsprogram på grund av dess flexibilitet och effektivitet. Den används ofta i verktyg och ramverk för nätverksövervakning, intrångsidentifiering, trafikanalys och prestandajustering. Dessutom sträcker sig dess funktioner bortom nätverk till andra områden av systemobservabilitet och kontroll, vilket gör det till en grundläggande byggsten för ett brett utbud av Linux-baserade program och tjänster.

• Azure Policy for Kubernetes: En podd som utökar Gatekeeper v3 med öppen källkod och registreras som en webbkrok till Kubernetes-åtkomstkontroll, vilket gör det möjligt att tillämpa skalbara tillämpningsåtgärder och skydd på dina kluster på ett centraliserat och konsekvent sätt. Azure Policy for Kubernetes-podden distribueras som ett AKS-tillägg. Den installeras bara på en nod i klustret.

Information om Defender-agentkomponent

Poddnamn	Namnområde	Variant	Kort beskrivning	Funktioner	Resursgränser	Utgående trafik krävs
microsoft-defender-collector-ds-*	kube-system	DaemonSet	En uppsättning containrar som fokuserar på att samla in inventerings- och säkerhetshändelser från Kubernetes-miljön.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	minne: 296Mi cpu: 360m	Nej
microsoft-defender-collector-misc-*	kube-system	Distribution	En uppsättning containrar som fokuserar på att samla in inventerings- och säkerhetshändelser från Kubernetes-miljön som inte är begränsade till en specifik nod.	Ej tillämpligt	minne: 64Mi cpu: 60m	Nej
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Publicera insamlade data till serverdelstjänsten Microsoft Defender for Containers där data bearbetas för och analyseras.	Ej tillämpligt	minne: 200Mi cpu: 60m	Https 443

Hur fungerar agentlös identifiering för Kubernetes i Azure?

Identifieringsprocessen baseras på ögonblicksbilder som tas med jämna mellanrum:

När du aktiverar den agentlösa identifieringen för Kubernetes-tillägget sker följande process:

• Skapa:

  • Om tillägget är aktiverat från Defender CSPM skapar Defender för molnet en identitet i kundmiljöer som kallas CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Om tillägget är aktiverat från Defender för containrar skapar Defender för molnet en identitet i kundmiljöer med namnet CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Tilldela: Defender för molnet tilldelar en inbyggd roll med namnet Kubernetes Agentless Operator till den identiteten i prenumerationsomfånget. Rollen innehåller följande behörigheter:
  • AKS-läsning (Microsoft.ContainerService/managedClusters/read)
    
  • AKS-betrodd åtkomst med följande behörigheter:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Upptäck: Med hjälp av den systemtilldelade identiteten utför Defender för molnet en identifiering av AKS-klustren i din miljö med hjälp av API-anrop till API-servern i AKS.

• Bindning: Vid identifiering av ett AKS-kluster utför Defender för molnet en AKS-bindningsåtgärd genom att skapa ett ClusterRoleBinding mellan den skapade identiteten och Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. ClusterRole visas via API:et och ger Defender för molnet läsbehörighet för dataplanet i klustret.

Få säker åtkomst för Azure-resurser i Azure Kubernetes Service med hjälp av betrodd åtkomst (förhandsversion)

Många Azure-tjänster som integreras med Azure Kubernetes Service (AKS) behöver åtkomst till Kubernetes API-servern. Om du vill undvika att bevilja dessa tjänster administratörsåtkomst eller göra dina AKS-kluster offentliga för nätverksåtkomst kan du använda funktionen för betrodd åtkomst i AKS.

Den här funktionen ger tjänster säker åtkomst till AKS och Kubernetes med hjälp av Azure-serverdelen utan att kräva en privat slutpunkt. I stället för att förlita sig på identiteter som har Microsoft Entra-behörigheter kan den här funktionen använda din systemtilldelade hanterade identitet för att autentisera med de hanterade tjänster och program som du vill använda med dina AKS-kluster.

Viktigt!

AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och anmäl dig. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. AKS-förhandsversioner omfattas delvis av kundsupport på bästa sätt.

Kommentar

API:et för betrodd åtkomst är allmänt tillgängligt. Vi tillhandahåller stöd för allmän tillgänglighet (GA) för Azure CLI, men det är fortfarande i förhandsversion och kräver att du använder aks-preview-tillägget.

Översikt över funktionen Betrodd åtkomst

Betrodd åtkomst hanterar följande scenarier:

• Om ett auktoriserat IP-intervall har angetts eller i ett privat kluster kanske Azure-tjänsterna inte kan komma åt Kubernetes API-servern om du inte implementerar en privat slutpunktsåtkomstmodell.
• Att ge en Azure-tjänstadministratör åtkomst till Kubernetes-API:et följer inte bästa praxis för åtkomst med minsta möjliga behörighet och kan leda till privilegiereskaleringar eller risk för läckage av autentiseringsuppgifter. Du kan till exempel behöva implementera högprivilegierade tjänst-till-tjänst-behörigheter och de är inte idealiska i en granskningsgranskning.

Du kan använda betrodd åtkomst för att ge uttryckligt medgivande till din systemtilldelade hanterade identitet för tillåtna resurser för åtkomst till dina AKS-kluster med hjälp av en Azure-resurs som kallas rollbindning. Dina Azure-resurser får åtkomst till AKS-kluster via den regionala AKS-gatewayen via systemtilldelad hanterad identitetsautentisering. Lämpliga Kubernetes-behörigheter tilldelas via en Azure-resurs som kallas roll. Via betrodd åtkomst kan du komma åt AKS-kluster med olika konfigurationer, inklusive men inte begränsat till privata kluster, kluster som har lokala konton inaktiverade, Microsoft Entra-kluster och auktoriserade IP-intervallkluster.

Förutsättningar

• Ett Azure-konto med en aktiv prenumeration. Skapa ett konto utan kostnad.

• Resurstyper som stöder systemtilldelad hanterad identitet.

  • Om du använder Azure CLI krävs tillägget aks-preview version 0.5.74 eller senare.

• Information om vilka roller som ska användas i olika scenarier finns i följande artiklar:

  • Azure Machine Learning-åtkomst till AKS-kluster med särskilda konfigurationer
  • Vad är Azure Kubernetes Service Backup?
  • Aktivera en agentlös containerstatus

Arkitekturdiagram över Defender för molnet och Arc-aktiverade Kubernetes-kluster

Dessa komponenter krävs för att få det fullständiga skydd som erbjuds av Microsoft Defender för containrar:

• Azure Arc-aktiverade Kubernetes – Azure Arc-aktiverade Kubernetes – en agentbaserad lösning som installeras på en nod i klustret och som ansluter dina kluster till Defender för molnet. Defender för molnet kan sedan distribuera följande två agenter som Arc-tillägg:
• Defender-agent: DaemonSet som distribueras på varje nod, samlar in värdsignaler med hjälp av eBPF-teknik och Kubernetes-granskningsloggar för att tillhandahålla körningsskydd. Agenten registreras med en Log Analytics-arbetsyta och används som en datapipeline. Granskningsloggdata lagras dock inte på Log Analytics-arbetsytan. Defender-agenten distribueras som ett Arc-aktiverat Kubernetes-tillägg.
• Azure Policy for Kubernetes: En podd som utökar Gatekeeper v3 med öppen källkod och registreras som en webbkrok till Kubernetes-åtkomstkontroll, vilket gör det möjligt att tillämpa skalbara tillämpningsåtgärder och skydd på dina kluster på ett centraliserat och konsekvent sätt. Azure Policy for Kubernetes-podden distribueras som ett Arc-aktiverat Kubernetes-tillägg. Den installeras bara på en nod i klustret. Mer information finns i Skydda dina Kubernetes-arbetsbelastningar och Förstå Azure Policy för Kubernetes-kluster.
  

Arkitekturdiagram över Defender för molnet- och EKS-kluster

När Defender för molnet skyddar ett kluster som finns i Elastic Kubernetes Service är insamlingen av granskningsloggdata agentlös. Det här är de komponenter som krävs för att få det fullständiga skydd som erbjuds av Microsoft Defender för containrar:

• Kubernetes-granskningsloggar – AWS-kontots CloudWatch aktiverar och samlar in granskningsloggdata via en agentlös insamlare och skickar den insamlade informationen till Microsoft Defender för molnet serverdel för ytterligare analys.
• Azure Arc-aktiverade Kubernetes – Azure Arc-aktiverade Kubernetes – en agentbaserad lösning som installeras på en nod i klustret och som ansluter dina kluster till Defender för molnet. Defender för molnet kan sedan distribuera följande två agenter som Arc-tillägg:
• Defender-agent: DaemonSet som distribueras på varje nod, samlar in signaler från värdar med hjälp av eBPF-teknik och ger körningsskydd. Agenten registreras med en Log Analytics-arbetsyta och används som en datapipeline. Granskningsloggdata lagras dock inte på Log Analytics-arbetsytan. Defender-agenten distribueras som ett Arc-aktiverat Kubernetes-tillägg.
• Azure Policy for Kubernetes: En podd som utökar Gatekeeper v3 med öppen källkod och registreras som en webbkrok till Kubernetes-åtkomstkontroll, vilket gör det möjligt att tillämpa skalbara tillämpningsåtgärder och skydd på dina kluster på ett centraliserat och konsekvent sätt. Azure Policy for Kubernetes-podden distribueras som ett Arc-aktiverat Kubernetes-tillägg. Den installeras bara på en nod i klustret.

Hur fungerar agentlös identifiering för Kubernetes i AWS?

Identifieringsprocessen baseras på ögonblicksbilder som tas med jämna mellanrum:

När du aktiverar den agentlösa identifieringen för Kubernetes-tillägget sker följande process:

• Skapa:

  • Den Defender för molnet rollen MDCContainersAgentlessDiscoveryK8sRole måste läggas till i aws-auth ConfigMap för EKS-klustren. Namnet kan anpassas.
    

• Tilldela: Defender för molnet tilldelar rollen MDCContainersAgentlessDiscoveryK8sRole följande behörigheter:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Upptäck: Med hjälp av den systemtilldelade identiteten utför Defender för molnet en identifiering av EKS-klustren i din miljö med HJÄLP av API-anrop till API-servern för EKS.

Arkitekturdiagram över Defender för molnet- och GKE-kluster

När Defender för molnet skyddar ett kluster som finns i Google Kubernetes Engine är insamlingen av granskningsloggdata agentlös. Det här är de komponenter som krävs för att få det fullständiga skydd som erbjuds av Microsoft Defender för containrar:

• Kubernetes-granskningsloggar – GCP Cloud Logging aktiverar och samlar in granskningsloggdata via en agentlös insamlare och skickar den insamlade informationen till Microsoft Defender för molnet serverdel för ytterligare analys.
• Azure Arc-aktiverade Kubernetes – Azure Arc-aktiverade Kubernetes – en agentbaserad lösning som installeras på en nod i klustret och som ansluter dina kluster till Defender för molnet. Defender för molnet kan sedan distribuera följande två agenter som Arc-tillägg:
• Defender-agent: DaemonSet som distribueras på varje nod, samlar in signaler från värdar med hjälp av eBPF-teknik och ger körningsskydd. Agenten registreras med en Log Analytics-arbetsyta och används som en datapipeline. Granskningsloggdata lagras dock inte på Log Analytics-arbetsytan. Defender-agenten distribueras som ett Arc-aktiverat Kubernetes-tillägg.
• Azure Policy for Kubernetes: En podd som utökar Gatekeeper v3 med öppen källkod och registreras som en webbkrok till Kubernetes-åtkomstkontroll, vilket gör det möjligt att tillämpa skalbara tillämpningsåtgärder och skydd på dina kluster på ett centraliserat och konsekvent sätt. Azure Policy for Kubernetes-podden distribueras som ett Arc-aktiverat Kubernetes-tillägg. Den behöver bara installeras på en nod i klustret.

Hur fungerar agentlös identifiering för Kubernetes i GCP?

Identifieringsprocessen baseras på ögonblicksbilder som tas med jämna mellanrum:

När du aktiverar den agentlösa identifieringen för Kubernetes-tillägget sker följande process:

• Skapa:

  • Tjänstkontot mdc-containers-k8s-operator skapas. Namnet kan anpassas.

• Tilldela: Defender för molnet kopplar följande roller till tjänstkontot mdc-containers-k8s-operator:

  • Den anpassade rollen MDCGkeClusterWriteRole, som har behörigheten container.clusters.update
  • Den inbyggda rollen container.viewer

• Upptäck: Med hjälp av den systemtilldelade identiteten utför Defender för molnet en identifiering av GKE-klustren i din miljö med hjälp av API-anrop till API-servern för GKE.