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 Microsoft Entra ID, 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.
• Helhetsinsyn från byggfasen genom hela applikationen 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.

AKS stöder två klusterlägen: AKS Automatic och AKS Standard. Säkerhetsbegreppen i den här artikeln gäller för båda lägena om inget annat anges. AKS Automatic innehåller en härdad säkerhetsbaslinje med flera kontroller förkonfigurerade som standard, medan AKS Standard ger mer konfigurationsflexibilitet.

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

Skapa säkerhet

Byggsäkerhet är startpunkten för din säkra leveranskedja. Innan avbildningar befordras till distributionsmiljöer kör du statisk analys och sårbarhets- och efterlevnadsbedömning i CI.

I båda AKS-lägena använder du riskbaserad sortering i stället för att blockera alla versioner av eventuella sårbarheter. Prioritera reparation med hjälp av leverantörsstatus och allvarlighetsgrad och tillämpa respitperioder för undantag som inte kan utnyttjas eller är tidsbundna.

AKS Automatic hjälper till att minska konfigurationsavvikelser längre ned i kedjan genom att låta kluster utgå från en härdad grundkonfiguration med förkonfigurerade säkerhetskontroller. Detta gör validering vid byggtillfället av avbildningskvalitet och efterlevnad av policyer ännu viktigare, eftersom betrodda avbildningar mer konsekvent flyttas vidare till en säker baslinje för körning.

AKS Standard ger större flexibilitet på klusternivå, så byggpipelines bör uttryckligen upprätthålla organisationens baslinjekrav för containeravbildningars ursprung, tröskelvärden för sårbarheter och policykontroller före driftsättning.

Registersäkerhet

Registersäkerhet verifierar att endast betrodda och kompatibla avbildningar är tillgängliga för distribution och hjälper till att identifiera drift efter generering. Utvärdera sårbarhetstillståndet för avbildningar i registret kontinuerligt, inte bara vid byggtiden. Registergenomsökning fångar nyligen avslöjade säkerhetsrisker och avbildningar som förbigick godkända byggsökvägar. Använd signering och verifiering av avbilder, till exempel Notary V2, för att säkerställa att arbetslaster driftsätts från betrodda källor med verifierbar härkomst.

För AKS Automatic, där flera körningssäkerhetsfunktioner är förkonfigurerade, förblir registerkontrollerna en viktig uppströmsgrind för att hålla leveranskedjan för körning ren. För AKS Standard ska du använda samma registerkontroller och anpassa dem till klustrets antagnings- och policykonfiguration för att konsekvent säkerställa användning av betrodda avbilder.

Klustersäkerhet

I AKS är Kubernetes primära komponenter en del av den hanterade tjänsten som tillhandahålls, hanteras och underhålls av Microsoft. Varje AKS-kluster har en egen, dedikerad Kubernetes primär 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.

För AKS Automatic är integreringen av API-servern med virtuellt nätverk förkonfigurerad som en del av den förvalda säkerhetskonfigurationen. I AKS Standard är samma funktion tillgänglig och kan aktiveras baserat på nätverksdesign och säkerhetskrav.

Du kan styra åtkomsten till API-servern med kubernetes rollbaserad åtkomstkontroll (Kubernetes RBAC) och Azure RBAC. I AKS Automatic är Azure RBAC för Kubernetes-auktorisering förkonfigurerad. I AKS Standard kan du välja och konfigurera den auktoriseringsmodell som passar din miljö bäst. Mer information finns i Microsoft Entra integrering med AKS.

Standardinställningar för automatisk säkerhet i AKS

AKS Automatic innehåller en härdad baslinje med säkerhetskontroller förkonfigurerade som standard, inklusive:

• Azure RBAC för Kubernetes-auktorisering
• Integrering av virtuellt API-servernätverk
• Arbetslastidentitet och OIDC-utfärdare
• Skyddsåtgärder för distribution och grundläggande poddsäkerhetsstandarder i tvingande läge
• Bildrengöringsmedel för att ta bort oanvända sårbara bilder
• Säkerhetsbegränsningar för hanterad systemnodpool som bevarar gränser mellan kundarbetsbelastningar och AKS-hanterad infrastruktur

AKS Standard stöder dessa funktioner med större implementeringsflexibilitet, men de kan kräva explicit aktivering och driftshantering.

Nodsäkerhet

AKS-noder är Azure virtuella datorer (VM). I AKS Standard hanterar du konfigurations- och livscykelalternativ för nodpooler. I AKS Automatic hanterar AKS systemnodpooler och kärnsystemkomponenter åt dig, inklusive skalning och uppgraderingar, med säkerhetsbegränsningar för hanterad systeminfrastruktur.

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.

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

Azure Container Linux (ACL) är ett oföränderligt, containeroptimerad operativsystem för AKS. ACL har sitt ursprung i projektet Flatcar Container Linux och bygger vidare på Flatcars beprövade, containercentrerade och immutabla design, samtidigt som Azure Linux-paket, underhåll och plattformsintegration tillförs. Detta gör att ACL kan hålla sig nära den överordnade Flatcar-innovationen samtidigt som den uppfyller Azure produktions-, säkerhets- och efterlevnadskrav. Mer information om Flatcar Container Linux finns i Flatcar-dokumentationen.

ACL är allmänt tillgänglig (GA) som OS-alternativ i AKS från och med AKS v1.34. Du kan distribuera ACL-nodpooler i ett nytt AKS-kluster, lägga till ACL-nodpooler i dina befintliga kluster och migrera befintliga Linux-nodpooler till ACL.

Mer information om ACL finns i Azure Container Linux (ACL) för AKS-översikt.

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.

I AKS Automatisk förkonfigureras hanterade virtuella nätverksfunktioner och grundläggande ingress- och utgående standardvärden för att tillhandahålla en säker baslinje. I AKS Standard är nätverksmodeller och utgående/ingress-kontroller mer flexibla och bör väljas baserat på din säkerhetsarkitektur.

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.

I AKS Automatic är arbetsbelastningsidentitet och OIDC-utfärdare förkonfigurerade för att förenkla säker arbetsbelastningsåtkomst till Azure tjänster. I AKS Standard är dessa funktioner tillgängliga och kan aktiveras som en del av din säkerhetsstatus för baslinjen.

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.

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.

Relaterat innehåll

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

Om du utvärderar standardinställningar för respektive läge och ansvar för drift, se Vad är Azure Kubernetes Service (AKS) Automatic?

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