Säkerhetsbegrepp för program och kluster i Azure Kubernetes Service (AKS)

Containersäkerhet skyddar hela pipelinen hela vägen från byggandet till applikationsarbetsbelastningar som körs på Azure Kubernetes Service (AKS).

Den säkra leveranskedjan innehåller byggmiljön och registret.

Kubernetes innehåller säkerhetskomponenter, till exempel poddsäkerhetsstandarder och hemligheter. Azure innehåller komponenter som služba Active Directory, Microsoft Defender för containrar, Azure Policy, Azure Key Vault, nätverkssäkerhetsgrupper och orkestrerade klusteruppgraderingar. AKS kombinerar dessa säkerhetskomponenter för att:

• Ange en fullständig autentiserings- och auktoriseringsberättelse.
• Använd inbyggda AKS-Azure Policy för att skydda dina program.
• Fullständig insikt från byggprocessen genom hela din applikation med Microsoft Defender för containrar.
• Se till att AKS-klustret kör de senaste säkerhetsuppdateringarna för operativsystemet och Kubernetes-versionerna.
• Ge säker poddtrafik och åtkomst till känsliga autentiseringsuppgifter.

Den här artikeln beskriver de grundläggande begreppen som skyddar dina program i AKS.

Viktigt!

Från och med November 30, 2025 Azure Kubernetes Service (AKS) inte längre stöder eller tillhandahåller säkerhetsuppdateringar för Azure Linux 2.0. Nodbilden Azure Linux 2.0 är fryst på 202512.06.0 release. Från och med den 31 mars 2026 tas nodbilder bort och du kan inte skala dina nodpooler. Migrera till en Azure Linux-version som stöds genom att uppgradera dina nodpooler till en Kubernetes-version som stöds eller migrera till osSku AzureLinux3. Mer information finns i pensionsfrågan på GitHub och pensionsmeddelandet från Azure Updates. För att hålla dig informerad om meddelanden och uppdateringar, följ AKS-versionsinformation.

Skapa säkerhet

Som en startpunkt för leveranskedjan är det viktigt att utföra statisk analys av bildbyggen innan de förs vidare i pipelinen. Detta omfattar sårbarhets- och efterlevnadsbedömning. Det handlar inte om att misslyckas med ett bygge eftersom det har en säkerhetsrisk, eftersom det bryter utvecklingen. Det handlar om att granska leverantörsstatus för att segmentera baserat på sårbarheter som kan åtgärdas av utvecklingsteamen. Använd även respitperioder för att ge utvecklare tid att åtgärda identifierade problem.

Registersäkerhet

Att utvärdera sårbarhetstillståndet för avbildningen i registret identifierar drift och fångar även avbildningar som inte kom från din byggmiljö. Använd Notary V2 för att bifoga signaturer till dina avbildningar för att säkerställa att distributionerna kommer från en betrodd plats.

Klustersäkerhet

I AKS ingår Kubernetes-huvudkomponenterna i den hanterade tjänsten som tillhandahålls, hanteras och underhålls av Microsoft. Varje AKS-kluster har en egen, dedikerad Kubernetes-huvudserver för att tillhandahålla API Server, Scheduler osv. Mer information finns i Vulnerability management for Azure Kubernetes Service.

Som standard använder Kubernetes API-servern en offentlig IP-adress och ett fullständigt kvalificerat domännamn (FQDN). Du kan begränsa åtkomsten till API-serverslutpunkten med hjälp av auktoriserade IP-intervall. Du kan också skapa ett helt privat kluster för att begränsa API-serveråtkomsten till ditt virtuella nätverk.

Du kan styra åtkomsten till API-servern med kubernetes rollbaserad åtkomstkontroll (Kubernetes RBAC) och Azure RBAC. Mer information finns i Microsoft Entra integrering med AKS.

Nodsäkerhet

AKS-noder är Azure virtuella datorer som du hanterar och underhåller.

• Linux-noder kör optimerade versioner av Ubuntu eller Azure Linux.
• Windows Server noder kör en optimerad Windows Server version med hjälp av containerd containerkörning.

När ett AKS-kluster skapas eller skalas upp distribueras noderna automatiskt med de senaste os-säkerhetsuppdateringarna och konfigurationerna.

Anteckning

AKS-kluster som för närvarande körs:

• Kubernetes version 1.19 och senare – Linux-nodpooler använder containerd som containerkörning. Windows Server 2019 och Windows Server 2022 node-pooler använder containerd som containermiljö. Mer information finns i Lägg till en Windows Server nodpool med containerd.
• Kubernetes version 1.19 och tidigare – Linux-nodpooler använder Docker som containerkörning.

Mer information om säkerhetsuppgraderingsprocessen för Linux- och Windows arbetsnoder finns i Säkerhetskorrigeringsnoder.

AKS-kluster som kör Azure virtuella datorer i generation 2 har stöd för Trusted Launch. Den här funktionen skyddar mot avancerade och beständiga attacktekniker genom att kombinera tekniker som du kan aktivera oberoende av varandra, till exempel säker start och en virtualiserad version av den betrodda plattformsmodulen (vTPM). Administratörer kan distribuera AKS-arbetsnoder med verifierade och signerade startladdare, OS-kernels och drivrutiner för att säkerställa integriteten för hela startkedjan för den underliggande virtuella datorn.

Alternativ för container- och säkerhetsoptimerade operativsystem

AKS har släppt stöd för två nya optimerade Linux OS-alternativ. Azure Linux OS Guard (förhandsversion) skapas och optimeras av Microsoft för Azure. OS Guard bygger på Azure Linux med specialiserad konfiguration för att stödja containerbaserade arbetsbelastningar med säkerhetsoptimeringar. Flatcar Container Linux for AKS (förhandsversion) är ett CNCF-baserat leverantörsneutralt containeroptimerad oföränderligt operativsystem som passar bäst för att köras i miljöer med flera moln och lokalt. Dessa os-alternativ ger ökad säkerhet jämfört med andra Linux OS-alternativ, till exempel:

• Både Azure Linux OS Guard och Flatcar Container Linux för AKS har ett oföränderligt operativsystem som du inte kan ändra vid körning. Alla os-binärfiler, bibliotek och statisk konfiguration är skrivskyddade och bit-för-bit-integriteten skyddas ofta kryptografiskt. Dessa operativsystem för särskilda ändamål levereras som fristående avbildningar och kommer utan någon form av pakethantering eller andra traditionella sätt att ändra operativsystemet. Användararbetslaster körs i isolerade miljöer som containrar och är isolerade från operativsystemet.
• Både Azure Linux OS Guard och Flatcar Container Linux för AKS använder SELinux för obligatorisk Access Control.
• Azure Linux OS Guard upprätthåller FIPS och Trusted Launch möjliggörande, vilket ger förbättrad efterlevnad och skydd mot avancerade och beständiga attacker genom att kombinera säker uppstart och en virtualiserad version av Trusted Platform Module (vTPM).

När du bestämmer mellan vilka containeroptimerade os-alternativ som ska användas rekommenderar AKS följande:

• Använd Flatcar Container Linux för AKS (förhandsversion) om du letar efter ett leverantörsneutralt oföränderligt operativsystem med stöd för flera moln.
• Använd Azure Linux OS Guard (förhandsversion) om du letar efter ett företagsklart oföränderligt operativsystem som rekommenderas av Microsoft.
• Använd Ubuntu om du letar efter ett leverantörsneutralt operativsystem för generell användning med stöd för flera moln.
• Använd Azure Linux om du letar efter ett företagsklart operativsystem för generell användning som rekommenderas av Microsoft.

Nodauktorisering

Nodauktorisering är ett särskilt auktoriseringsläge som specifikt auktoriserar kubelet API-begäranden för att skydda mot attacker mellan öst och väst. Nodauktorisering är aktiverat som standard i AKS 1.24 + kluster.

Noddistribution

Noder distribueras till ett privat virtuellt nätverksundernät, utan att några offentliga IP-adresser har tilldelats. För felsökning och hantering är SSH aktiverat som standard och endast tillgängligt med hjälp av den interna IP-adressen. Att inaktivera SSH när kluster och nodpool skapas, eller för ett befintligt kluster eller en befintlig nodpool, är i förhandsgranskning. Mer information finns i Hantera SSH-åtkomst .

Nodlagring

För att tillhandahålla lagring använder noderna Azure Managed Disks. För de flesta VM-nodstorlekar är Azure Managed Disks Premium-diskar som backas upp av högpresterande SSD:er. Data som lagras på hanterade diskar krypteras automatiskt i vila inom Azure-plattformen. För att förbättra redundansen replikeras Azure Managed Disks på ett säkert sätt inom Azure datacenter.

Fientliga multitenantarbetsbelastningar

För närvarande är Kubernetes-miljöer inte säkra för fientlig användning av flera klientorganisationer. Extra säkerhetsfunktioner, till exempel poddsäkerhetsprinciper eller Kubernetes RBAC för noder, blockerar effektivt kryphål. För att uppnå verklig säkerhet när du kör fientliga delade arbetsbelastningar, lita bara på en hypervisor. Säkerhetsdomänen för Kubernetes blir hela klustret, inte en enskild nod.

För dessa typer av fientliga multitenantarbetsbelastningar bör du använda fysiskt isolerade kluster. Mer information om hur du isolerar arbetsbelastningar finns i Metodtips för klusterisolering i AKS.

Beräkningsisolering

På grund av efterlevnads- eller regelkrav kan vissa arbetsbelastningar kräva en hög grad av isolering från andra kundarbetsbelastningar. För dessa arbetsbelastningar tillhandahåller Azure:

• Kernel-isolerade containrar som ska användas som agentnoder i ett AKS-kluster. Dessa containrar är helt isolerade till en viss maskinvarutyp och isolerade från Azure Värdinfrastruktur, värdoperativsystemet och hypervisor-programmet. De är dedikerade till en enda kund. Välj en av de isolerade virtuella datorernas storlek som nodstorlek när du skapar ett AKS-kluster eller lägger till en nodpool.
• Konfidentiella containrar (förhandsversion), även baserade på Kata Confidential Containers, krypterar containerminnet och förhindrar att data i minnet under beräkningen är i klartext, läsbart format och manipulering. Det hjälper till att isolera dina containrar från andra containergrupper/poddar och VM-nodens OS-kernel. Konfidentiella containrar (förhandsversion) använder maskinvarubaserad minneskryptering (SEV-SNP).
• Podsandboxning (förhandsversion) skapar en isoleringsbarriär mellan containerapplikationen och de delade resurserna från kerneln och beräkningsresurserna (CPU, minne och nätverk) för containervärden.

Nätverkssäkerhet

För anslutning och säkerhet med lokala nätverk kan du distribuera DITT AKS-kluster till befintliga Azure virtuella nätverksundernät. Dessa virtuella nätverk ansluter tillbaka till ditt lokala nätverk med hjälp av Azure PLATS-till-plats-VPN eller Express Route. Definiera Kubernetes-ingresskontrollanter med privata, interna IP-adresser för att begränsa tjänsternas åtkomst till den interna nätverksanslutningen.

Azure nätverkssäkerhetsgrupper

Om du vill filtrera trafikflödet för virtuella nätverk använder Azure regler för nätverkssäkerhetsgrupper. Dessa regler definierar käll- och mål-IP-intervall, portar och protokoll som tillåts eller nekas åtkomst till resurser. Standardregler skapas för att tillåta TLS-trafik till Kubernetes API-servern. Du skapar tjänster med lastbalanserare, portmappningar eller ingressvägar. AKS ändrar automatiskt nätverkssäkerhetsgruppen för att möjliggöra trafikflöde.

Om du anger ett eget undernät för AKS-klustret (oavsett om du använder Azure CNI eller Kubenet) ska du inte ändra nätverkssäkerhetsgruppen på NIC-nivå som hanteras av AKS. Skapa i stället fler nätverkssäkerhetsgrupper på undernätsnivå om du vill ändra trafikflödet. Se till att de inte stör nödvändig trafik som hanterar klustret, till exempel åtkomst till lastbalanserare, kommunikation med kontrollplanet eller utgående trafik.

Kubernetes-nätverksprincip

För att begränsa nätverkstrafiken mellan poddar i klustret erbjuder AKS stöd för Kubernetes-nätverksprinciper. Med nätverksprinciper kan du tillåta eller neka specifika nätverkssökvägar i klustret baserat på namnområden och etikettväljare.

Programsäkerhet

För att skydda poddar som körs på AKS bör du överväga Microsoft Defender för containrar för att identifiera och begränsa cyberattacker mot dina program som körs i dina poddar. Kör kontinuerlig genomsökning för att identifiera avvikelse i programmets sårbarhetstillstånd och implementera en "blå/grön/kanarie"-process för att korrigera och ersätta de sårbara bilderna.

Skydda containeråtkomst till resurser

På samma sätt som du bör ge användare eller grupper de minsta behörigheter som krävs bör du också begränsa containrar till endast nödvändiga åtgärder och processer. Undvik att konfigurera program och containrar som kräver eskalerade privilegier eller rotåtkomst för att minimera risken för angrepp. Inbyggda Linux-säkerhetsfunktioner som AppArmor och seccomp rekommenderas som metodtips för att skydda containeråtkomst till resurser.

Kubernetes-hemligheter

Med en Kubernetes-hemlighet matar du in känsliga data i poddar, till exempel åtkomstautentiseringsuppgifter eller nycklar.

1. Skapa en hemlighet med kubernetes-API:et.
2. Definiera din podd eller distribution och begär en specifik hemlighet.
   • Hemligheter tillhandahålls endast till noder med en schemalagd pod som kräver dem.
   • Hemligheten lagras i tmpfs, inte skrivs till disk.
3. När du tar bort den sista podden på en nod som kräver en hemlighet tas hemligheten bort från nodens tmpfs.
   • Hemligheter lagras i ett angivet namnområde och är endast tillgängliga från poddar inom samma namnområde.

Genom att använda Secrets minskar den känsliga informationen som definieras i YAML-manifestet för en pod eller tjänst. I stället begär du hemligheten som lagras i Kubernetes API Server som en del av YAML-manifestet. Den här metoden ger endast den specifika podd åtkomst till hemlighet.

Anteckning

De rå hemliga manifestfilerna innehåller hemliga data i base64-format. Mer information finns i den officiella dokumentationen. Behandla dessa filer som känslig information och lägg aldrig upp dem i källkontrollen.

Kubernetes-hemligheter lagras i etcd, ett distribuerat nyckelvärdeslager. AKS tillåter kryptering i resten av hemligheter i etcd med hjälp av kundhanterade nycklar.

Nästa steg

Information om hur du kommer igång med att skydda dina AKS-kluster finns i Uppgradera ett AKS-kluster.

För tillhörande metodtips, se Metodtips för klustersäkerhet och uppgraderingar i AKS och Metodtips för poddsäkerhet i AKS.

Mer information om viktiga Kubernetes- och AKS-begrepp finns i:

• Kubernetes/AKS-kluster och arbetsbelastningar
• Kubernetes/AKS-identitet
• Virtuella Kubernetes/AKS-nätverk
• Kubernetes/AKS-lagring
• Kubernetes/AKS-skala