Säkerhet för AKS

Den här artikeln vägleder dig genom aspekter av säkerhetsstyrning i Azure Kubernetes Service (AKS) som du bör överväga innan du implementerar någon lösning.

Artikeln fokuserar på hur du implementerar lösningar med hjälp av Azure och programvara med öppen källkod. De beslut du fattar när du skapar en landningszon i företagsskala kan delvis fördefiniera din styrning. Information om styrningsprinciper finns i Säkerhetsstyrning och efterlevnad i företagsskala.

Attackytor

Tänk på följande fem attackytor när du skapar en säkerhetsstrategi för Kubernetes-kluster:

• Skapa
• Register
• Kluster
• Nod
• Program

För varje kategori diskuterar vi de största riskerna att ta hänsyn till och motåtgärder för dessa risker.

Skapa säkerhet

Byggsäkerhet handlar om korrekt användning av DevSecOps med containeravbildningar.

Större risker

Dålig avbildningskonfiguration kan leda till säkerhetsrisker i pipelinen. Du kan till exempel ha containrar som körs med större behörighet än de behöver. Containrarna kan också konfigureras för att tillåta viss nätverksåtkomst, vilket kan äventyra systemet. Att inte begränsa de tillåtna systemanropen till de anrop som krävs för säker drift av containrar kan öka risken från en komprometterad container.

En annan säkerhetsrisk kan vara att tillåta containern att få åtkomst till en känslig katalog för värden eller tillåta att containrarna ändrar de platser som styr värdens grundläggande funktion.

Oseriösa containrar är oplanerade containrar i en miljö. De kan vara resultatet av att utvecklare testar sin kod i testmiljöer. Dessa containrar kanske inte har genomgått rigorös genomsökning efter säkerhetsrisker eller konfigurerats korrekt. Dessa säkerhetsrisker kan öppna en startpunkt för angripare.

Att använda basavbildningar som inte kommer från betrodda källor eller inte är uppdaterade med säkerhetsuppdateringar kan också leda till sårbarheter i de containrar som de använder för att skapa.

Risk motåtgärder

Byggsäkerhet handlar om implementeringen av DevSecOps för att flytta säkerheten åt vänster och åtgärda de flesta problem innan de börjar flytta ned pipelinen. Det handlar inte om att lägga allt ägarskap på utvecklare, utan om att dela ägarskapet med driften. Utvecklare kan sedan se och åtgärda sårbarheter och efterlevnadsproblem som de faktiskt kan åtgärda.

Du kan skapa en pipeline som söker igenom och misslyckas med byggen eftersom den har en eller tio kritiska säkerhetsrisker. En bättre metod kan vara att titta på nästa lager nedåt. Du kan börja segmentera ansvarspunkten baserat på leverantörsstatus.

Ange ett tröskelvärde i statusskiktet för säkerhetsrisken. Allt med statusen Open, Will not fix eller Deferred fortsätter att flöda ned i pipelinen där SecOps kan komma åt risken, som de gör idag. En säkerhetsrisk med statusen Leverantörskorrigeringar är något som en utvecklare kan åtgärda. Användning av respitperioder ger utvecklare tid att åtgärda sårbarheter.

Tillsammans med sårbarhetsbedömningen är efterlevnadsbedömningen. Om du till exempel tillåter att en avbildning körs som rot eller exponerar SSH bryts efterlevnadsstatusen för de flesta företag. Åtgärda det här problemet under bygget i stället för under distributionen.

Vanligtvis genomsöker du dina avbildningar mot Docker CIS-riktmärket. När du använder dessa typer av flöden bryter du inte utvecklingen genom att införa säkerhetsreparation, men du kan förbättra företagets övergripande säkerhetsstatus.

Det är viktigt att använda ett verktyg som möjliggör dessa funktioner för att effektivt implementera rätt strategi för ditt företag. Traditionella verktyg kan ofta inte identifiera sårbarheter i containrar, vilket kan leda till en falsk känsla av säkerhet. Verktyg som använder den pipelinebaserade byggmetoden och containerteknikens oföränderliga och deklarativa karaktär krävs för att skydda containerekosystemet på ett korrekt sätt.

Dessa verktyg bör ha följande egenskaper:

• Integrering med hela livslängden för avbildningarna, från början av byggprocessen till registret till körningen.
• Insyn i sårbarheter i alla lager av avbildningen, inklusive basskiktet för avbildningen, programramverk och anpassad programvara.
• Principdriven tillämpning med rätt detaljnivå, vilket gör att din organisation kan skapa kvalitetsgrindar i varje steg i bygg- och distributionsprocesserna.

Registersäkerhet

Registersäkerhet handlar om:

• Avdriftskontroll från bygge.
• Förebyggande av push/pull av kontaminerade bilder.
• Bildsignering.

Större risker

Bilder innehåller ofta upphovsrättsskyddad information, inklusive en organisations källkod. Om anslutningar till register inte är korrekt säkra kan innehållet i en bild utgöra sekretessrisker lika allvarliga som alla andra former av data som överförs inom din organisation. Inaktuella avbildningar med sårbara inaktuella versioner i registret kan öka säkerhetsriskerna om de distribueras av misstag.

En annan säkerhetsrisk kan omfatta otillräckliga autentiserings- och auktoriseringsbegränsningar för containerregister. Dessa register kan innehålla känsliga upphovsrättsskyddade tillgångar i bilderna.

När innehåll skapas och distribueras är fördelningen av det här innehållet en av många attackvektorer. Hur ser du till att innehållet som mellanlagras för distribution är samma innehåll som levereras till en avsedd slutpunkt?

Risk motåtgärder

Konfigurera distributionsprocesser för att säkerställa att utvecklingsverktyg, nätverk och containerkörningar endast är anslutna till register via krypterade kanaler. Se också till att innehållet kommer från en betrodd källa. Så här minskar du riskerna med att använda inaktuella bilder:

• Ta bort osäkra, sårbara avbildningar som inte längre ska användas från containerregister.
• Framtvinga åtkomst till bilder med oföränderliga namn som anger specifika versioner av bilder som ska användas. Du kan implementera den här konfigurationen med hjälp av en senaste tagg eller en specifik version av avbildningarna. En tagg garanterar inte färskhet. Därför bör du införa en process för att säkerställa att Kubernetes-orkestreraren använder de senaste unika talen eller att den senaste taggen representerar de senaste versionerna.

Åtkomst till register som innehåller känsliga avbildningar bör kräva autentisering och auktorisering. All skrivåtkomst bör också kräva autentisering. Din princip kan till exempel göra det möjligt för utvecklare att endast skicka bilder till de specifika lagringsplatser som de ansvarar för.

Åtkomsten till dessa register bör federeras och dra nytta av åtkomstprinciper på affärsnivå. Du kan till exempel konfigurera CI/CD-pipelinen för att skicka avbildningar till lagringsplatser först efter att de har klarat sårbarhetsgenomsökningen av efterlevnadsutvärderingar och kvalitetskontrolltester.

Containerregister som nu betraktas som artefaktregister blir ett primärt sätt att distribuera alla innehållstyper, inte bara containeravbildningar. Varje moln tillhandahåller ett register med projekt med öppen källkod och leverantörsprodukter som är tillgängliga för lokal eller privat värd i molnleverantörer. Innehållet höjs upp i och mellan register från den ursprungliga versionen till produktionsdistributionen.

Hur kan du se till att integriteten för innehållet som gick in i registret är samma innehåll som kommer ut ur registret? Om du antar en lösning för avbildningssignering ser du till att distributioner endast kommer från betrodda register och distribuerar betrott innehåll.

Klustersäkerhet

Klustersäkerhet handlar om:

• Autentisering och auktorisering.
• Nätverkssäkerhet.
• Sårbarhets- och efterlevnadshantering.

Större risker

Ibland kan ett enskilt Kubernetes-kluster användas för att köra olika program som hanteras av olika team med olika krav på åtkomstnivå. Om åtkomst tillhandahålls till enskilda användare utan begränsningar eller endast enligt deras behov kan en skadlig eller vårdslös användare kompromettera arbetsbelastningar som de har åtkomst till och andra tillgångar i klustret.

En annan säkerhetsrisk kan inträffa när klustrets egen användarkatalog hanterar auktorisering och autentisering. En katalog för organisationsautentisering kontrolleras ofta striktare. Eftersom dessa konton är mycket privilegierade och oftast överblivna ökar risken för ett komprometterat konto.

Det här scenariot kan leda till klusterrisker eller till och med systemomfattande säkerhetsrisker. Data som lagras av containervolymer hanteras av orkestrerare, som måste ha åtkomst till data oavsett vilken nod de finns på.

Traditionella nätverksfilter kan ha en säkerhetsblindhet på grund av ett nätverksöverlägg som är utformat för att kryptera data under överföring. Den här designen gör det svårt att övervaka trafik i klustret, så särskilda bestämmelser kan krävas för att övervaka Kubernetes-kluster.

Trafik från olika program som delar samma kluster kan ha olika känslighetsnivåer, till exempel en offentlig webbplats och ett internt program som kör kritiska känsliga affärsprocesser. Att dela samma virtuella nätverk i klustret kan leda till komprometterade känsliga data. En angripare kan till exempel använda det delade nätverk som exponeras för Internet för att attackera de interna programmen.

Skydda komponenter som kör själva klustret mot sårbarheter och efterlevnadsproblem. Kontrollera att du kör den senaste möjliga versionen av Kubernetes för att dra nytta av reparationen.

Risk motåtgärder

Åtkomst till Kubernetes-klusteranvändare bör använda en modell för åtkomst med minst behörighet. Ge endast användare åtkomst till att utföra specifika åtgärder på specifika värdar, containrar och avbildningar som krävs för att de ska kunna utföra sina jobb. Testteamets medlemmar bör ha begränsad eller ingen åtkomst till containrar i produktion. Användarkonton med klusteromfattande åtkomst bör kontrolleras noggrant och användas sparsamt.

Använd starka autentiseringsmetoder som multifaktorautentisering för att skydda åtkomsten till dessa konton. En organisations användarkatalog bör användas för att hantera kluster via enkel inloggning i stället för klusterspecifika användarkonton som kanske inte har samma nivå av principer och kontroller.

Använd krypteringsmetoder som gör det möjligt för containrar att få korrekt åtkomst till data oavsett vilken värd containrarna körs på. Dessa krypteringsverktyg bör förhindra obehörig åtkomst till data från andra containrar även inom samma nod som inte ska ha åtkomst till dem.

Konfigurera Kubernetes-kluster för att separera nätverkstrafik i diskreta virtuella nätverk eller undernät efter känslighetsnivå. Segmentering per program kan också vara möjlig, men det kan vara tillräckligt att definiera nätverk efter känslighetsnivåer. Till exempel bör virtuella nätverk för kundinriktade program som är åtskilda från dem som hanterar interna program med känslig trafik implementeras som ett minimum.

Du kan använda taints och toleranser för att isolera distributioner till specifika uppsättningar noder efter känslighetsnivåer. Undvik att hantera mycket känsliga arbetsbelastningar inom samma nod som de arbetsbelastningar med lägre känslighet. Att använda separata hanterade kluster är ett säkrare alternativ.

Segmentera containrar efter syfte, känslighet och trådstatus för att ge extra skydd för känsliga arbetsbelastningar. Genom att segmentera containrar på det här sättet är det svårare för en angripare som har fått åtkomst till ett segment att få åtkomst till andra segment. Den här konfigurationen har den extra fördelen att säkerställa att restdata, till exempel cacheminnen eller volymmonteringar, isoleras efter känslighetsnivå.

Kubernetes-kluster ska konfigureras för att:

• Tillhandahålla en säker miljö för program som körs på dem.
• Se till att noderna läggs till på ett säkert sätt i klustret.
• Ha beständiga identiteter för att säkerställa säkerheten under hela livscykeln.
• Ange live, korrekt information om klustrets tillstånd, inklusive nätverk och noderna i det.

Det måste vara enkelt för en komprometterad nod att isoleras och tas bort från klustret utan att det påverkar klustrets prestanda. AKS gör det enkelt.

Definiera konfigurationsstandarder för containerkörning för att automatiskt säkerställa efterlevnad. Det finns många principer i Azure som gör den här processen enkel och användarna kan också skapa egna principer. Använd Azure-säkerhetsfunktioner för att kontinuerligt utvärdera konfigurationsinställningar i hela miljön och aktivt framtvinga dem.

Se automatiskt till att säkerhetsrisker för Kubernetes-komponenterna åtgärdas. Använd separata miljöer för utveckling, testning och produktion, var och en med sina egna kontroller och rollbaserad åtkomstkontroll (RBAC) för containerhantering. Associera alla skapande av containrar med enskilda användaridentiteter så ska den loggas för granskning. Den här konfigurationen bidrar till att minska risken för oseriösa containrar.

Nodsäkerhet

Nodsäkerhet handlar om:

• Körningsskydd.
• Sårbarhets- och efterlevnadshantering.

Större risker

En arbetsnod har privilegierad åtkomst till alla komponenter på noden. Angripare kan använda valfri nätverkstillgänglig tjänst som startpunkt, så att ge åtkomst till värden från flera punkter kan allvarligt öka dess attackyta. Ju större attackytan är, desto större är risken för att en angripare får åtkomst till noden och dess operativsystem.

Dessutom har containerspecifika operativsystem som de som används i AKS-noder en mindre attackyta eftersom de inte innehåller bibliotek som gör att vanliga operativsystem kan köra databaser och webbservrar direkt. Användningen av en delad kernel resulterar i en större attackyta för containrar som körs i samma miljö än containrar på separata virtuella datorer. Detta gäller även när containerspecifika operativsystem som körs på AKS-noder används.

Värdoperativsystem tillhandahåller grundläggande systemkomponenter som kan ha sårbarheter och efterlevnadsrisker. Eftersom de är lågnivåkomponenter kan deras sårbarheter och konfiguration påverka alla containrar som hanteras. AKS skyddar användarna genom att se till att dessa sårbarheter hanteras via regelbundna OS-uppdateringar på noder som körs på AKS och att arbetsnodens efterlevnadsstatus upprätthålls.

Felaktiga användaråtkomsträttigheter kan också leda till säkerhetsrisker när användare loggar in direkt till noderna för att hantera containrarna i stället för via AKS-kontrollplanet. Att logga in direkt kan göra det möjligt för användaren att göra ändringar i program utöver de som de bör ha åtkomst till.

Skadliga containrar kan också leda till manipulering av operativsystemfilsystemet. Om en container till exempel tillåts montera en känslig katalog i värdoperativsystemet kan containern göra ändringar i filerna. Ändringarna kan påverka säkerheten för andra containrar som körs på värden.

Risk motåtgärder

Begränsa nodåtkomsten genom att begränsa SSH-åtkomsten.

Användning av det containerspecifika operativsystemet i AKS-noder minskar vanligtvis attackytorna eftersom andra tjänster och funktioner är inaktiverade. De har också skrivskyddade filsystem och använder andra metoder för klusterhärdning som standard.

Azure-plattformen tillämpar automatiskt os-säkerhetskorrigeringar på Linux- och Windows-noder varje natt. Om en säkerhetsuppdatering för Linux-operativsystemet kräver en värdomstart startas den inte om automatiskt. AKS tillhandahåller mekanismer för omstart för att tillämpa dessa specifika korrigeringar.

Microsoft Defender för servrar gäller inte för AKS Linux- och Windows-noder eftersom Microsoft hanterar deras operativsystem. Om inga andra virtuella datorer finns i prenumerationen där AKS distribueras kan du på ett säkert sätt inaktivera Microsoft Defender för servrar.

Om miljön har distribuerats, inklusive de rekommenderade Azure-principerna i företagsskala, kan du konfigurera ett undantag för principtilldelningen i hanteringsgruppen som automatiskt gör det möjligt för Microsoft Defender för servrar att undvika onödiga kostnader.

Programsäkerhet

Programsäkerhet handlar om:

• Körningsskydd.
• Sårbarhets- och efterlevnadshantering.

Större risker

Avbildningar är filer som innehåller alla komponenter som krävs för att köra ett program. När de senaste versionerna av dessa komponenter används för att skapa avbildningar kan de vara fria från kända sårbarheter vid den tidpunkten, men de kan ändras snabbt.

Du måste hålla filerna uppdaterade med de senaste versionerna eftersom paketutvecklare regelbundet identifierar säkerhetsrisker. Gör containeruppdateringarna längre uppströms genom att uppdatera avbildningarna som används för att skapa containrarna, till skillnad från traditionella program, som vanligtvis uppdateras på värden.

Skadliga filer kan också bäddas in i en bild, som sedan kan användas för att attackera andra containrar eller komponenter i systemet. Containrar från tredje part kan vara en möjlig attackvektor. Specifik information kan vara okänd om dem och de kan läcka data. Containrarna kanske inte har uppdaterats med nödvändiga säkerhetsuppdateringar.

En annan attackvektor är användningen av inbäddning av hemligheter som lösenord och niska veze direkt i ett bildfilsystem. Den här metoden kan orsaka en säkerhetsrisk eftersom alla som har åtkomst till avbildningen kan få åtkomst till hemligheterna.

Det kan finnas brister i själva programmen, till exempel program som är sårbara för skript mellan platser eller SQL-inmatning. När det finns brister kan sårbarheten användas för att ge obehörig åtkomst till känslig information i andra containrar eller till och med värdoperativsystemet.

AKS-containerkörningen gör det enkelt att övervaka säkerhetsrisker med hjälp av de olika säkerhetsverktygen som är tillgängliga i Azure. Mer information finns i Introduktion till Microsoft Defender för Kubernetes.

Du bör också styra utgående nätverkstrafik som skickas till containrar för att säkerställa att containrar inte kan skicka trafik över nätverk med olika känslighetsnivåer som miljöer som är värdar för säkra data eller till Internet. Azure gör den här kontrollen enkel med sina olika nätverks- och AKS-säkerhetsfunktioner.

Som standard fokuserar Kubernetes-schemaläggare på att driva skalning och maximera densiteten för arbetsbelastningar som körs på noder. De kan placera poddar med olika känslighetsnivåer i samma nod bara för att värden har de mest tillgängliga resurserna. Det här scenariot kan potentiellt leda till säkerhetsincidenter när angripare använder åtkomst till offentliga arbetsbelastningar för att attackera containrar som kör mer känsliga processer på samma värd. En komprometterad container kan också användas för att genomsöka nätverket för att hitta andra säkerhetsrisker som angriparen kan utnyttja.

Risk motåtgärder

Lagra aldrig hemligheter i programkod eller filsystem. Hemligheter bör lagras i nyckellager och tillhandahållas till containrar vid körning efter behov. AKS kan se till att endast containrar som behöver åtkomst till vissa nycklar har åtkomst till dem och att dessa hemligheter inte sparas på disken. Azure Key Vault kan till exempel lagra dessa hemligheter på ett säkert sätt och tillhandahålla dem till AKS-klustret efter behov. Det är också enkelt att se till att dessa hemligheter krypteras både i lagring och under överföring.

Undvik att använda obetrodda bilder och register och se till att endast bilder från betrodda uppsättningar tillåts köras i deras kluster. För en metod med flera lager:

• Kontrollera centralt exakt vilka avbildningar och register som är betrodda.
• Identifiera varje bild diskret med kryptografisk signatur.
• Sätt principer på plats som säkerställer att alla värdar bara kör avbildningar som kommer från den godkända uppsättningen.
• Verifiera dessa signaturer före körning.
• Övervaka och uppdatera dessa avbildningar och register när säkerhetsrisker och konfigurationskrav ändras.

Säkra beräkningsprofiler ska användas för att begränsa containrar och allokeras vid körning. Anpassade profiler kan skapas och skickas till containerkörningar för att ytterligare begränsa deras funktioner. Kontrollera minst att containrar körs med standardprofilerna. Överväg att använda anpassade, mer begränsade profiler för containrar som kör högriskprogram.

Verktyg kan automatiskt profilera program med hjälp av beteendeinlärning och upptäcka avvikelser. Du kan använda lösningar från tredje part för att identifiera avvikelser vid körning. Avvikelser kan omfatta händelser som:

• Ogiltig eller oväntad processkörning eller systemanrop.
• Ändringar i skyddade konfigurationsfiler och binärfiler.
• Skriver till oväntade platser och filtyper.
• Skapa oväntade nätverkslyssnare.
• Trafik som skickas till oväntade nätverksmål.
• Lagring och körning av skadlig kod.

Microsoft Defender för Kubernetes investerar för närvarande på det här området.

Containrar ska köras med sitt rotfilsystem i skrivskyddat läge för att isolera skrivningar till definierade kataloger, som dessa verktyg enkelt kan övervaka. Den här konfigurationen gör containrar mer motståndskraftiga att kompromettera eftersom du isolerar manipulering till dessa specifika platser. De kan enkelt separeras från resten av programmet.

Utformningsbeaktanden

AKS har flera gränssnitt till andra Azure-tjänster som Microsoft Entra ID, Azure Storage och Azure Virtual Network. Användning av dessa tjänster kräver särskild uppmärksamhet under planeringsfasen. AKS lägger också till extra komplexitet som kräver att du överväger att tillämpa samma säkerhetsstyrnings- och efterlevnadsmekanismer och kontroller som i resten av infrastrukturlandskapet.

Här följer några andra designöverväganden för AKS-säkerhetsstyrning och -efterlevnad:

• Om du skapar ett AKS-kluster i en prenumeration som distribuerats enligt metodtips för landningszoner i företagsskala ska du bekanta dig med de Azure-principer som klustren ärver. Mer information finns i Principer som ingår i Referensimplementeringar för Azure-landningszoner.
• Bestäm om klustrets kontrollplan ska vara tillgängligt via Internet (vi rekommenderar IP-begränsningar), vilket är standard eller endast inifrån ditt privata nätverk i Azure eller lokalt som ett privat kluster. Om din organisation följer metodtips för Corp landningszoner i företagsskala har hanteringsgruppen en Associerad Azure Policy som tvingar kluster att vara privata. Mer information finns i Principer som ingår i Referensimplementeringar för Azure-landningszoner.
• Utvärdera med hjälp av den inbyggda Säkerhetsmodulen för AppArmor Linux för att begränsa åtgärder som containrar kan utföra, till exempel läsa, skriva, köra eller systemfunktioner som montering av filsystem. Till exempel har alla prenumerationer Azure-principer som hindrar poddar i alla AKS-kluster från att skapa privilegierade containrar. Mer information finns i Principer som ingår i Referensimplementeringar för Azure-landningszoner.
• Utvärdera användning seccomp (säker databehandling) på processnivå för att begränsa de processanrop som containrar kan utföra. Azure Policy används till exempel som en del av den allmänna implementeringen av landningszoner i företagsskala i hanteringsgruppen för landningszoner för att förhindra eskalering av containerprivilegier till rotanvändare seccomp via Azure-principer för Kubernetes.
• Bestäm om ditt containerregister är tillgängligt via Internet eller endast i ett specifikt virtuellt nätverk. Inaktivering av Internetåtkomst i ett containerregister kan ha negativa effekter på andra system som förlitar sig på offentlig anslutning för att få åtkomst till den. Exempel är pipelines för kontinuerlig integrering eller Microsoft Defender för avbildningsgenomsökning. Mer information finns i Ansluta privat till ett containerregister med hjälp av Azure Private Link.
• Bestäm om ditt privata containerregister delas mellan flera landningszoner eller om du distribuerar ett dedikerat containerregister till varje landningszonprenumeration.
• Överväg att använda en säkerhetslösning som Microsoft Defender för Kubernetes för hotidentifiering.
• Överväg att söka igenom dina containeravbildningar efter säkerhetsrisker.
• Överväg att inaktivera Microsoft Defender för servrar i AKS-prenumerationen om det inte finns några virtuella datorer som inte är virtuella AKS-datorer för att undvika onödiga kostnader.

Designrekommendationer

• Begränsa åtkomsten till Kubernetes-klusterkonfigurationsfilen med hjälp av Azure RBAC.
• Säker poddåtkomst till resurser. Ange minst antal behörigheter och undvik att använda rot- eller privilegierad eskalering.
• Använd Entra-arbetsbelastnings-ID med AKS och Azure Key Vault-providern för Secrets Store CSI-drivrutin för att skydda hemligheter, certifikat och niska veze.
• Använd AKS-nodavbildningsuppgradering för att uppdatera AKS-klusternodavbildningar om möjligt, eller kured för att automatisera nodomstarter när du har tillämpat uppdateringar.
• Övervaka och framtvinga konfiguration med hjälp av Azure Policy-tillägget för Kubernetes. I prenumerationer som distribueras enligt metodtips för landningszoner i företagsskala sker den här konfigurationen automatiskt via en Azure Policy som distribueras på hanteringsgruppsnivå.
• Visa AKS-rekommendationer i Microsoft Defender för molnet.
• Använd Microsoft Defender för containrar, den molnbaserade lösningen för att förbättra, övervaka och upprätthålla säkerheten för dina kluster, containrar och deras program.
• Distribuera en dedikerad och privat instans av Azure Container Registry till varje landningszonprenumeration.
• Använd Private Link för Container Registry för att ansluta det till AKS.
• Sök igenom dina bilder efter sårbarheter med Upravljanje ranjivostima za Microsoft Defender eller någon annan lösning för bildgenomsökning.

Viktigt!

Avbildningsgenomsökningen i Microsoft Defender för molnet är inte kompatibel med Container Registry-slutpunkter. Mer information finns i Ansluta privat till ett containerregister med hjälp av Private Link.