Den här artikeln beskriver hur Amazon Elastic Kubernetes Service (Amazon EKS) och Azure Kubernetes Service (AKS) tillhandahåller identitet för Kubernetes-arbetsbelastningar för åtkomst till molnplattformstjänster. En detaljerad jämförelse av Amazon Web Services (AWS) Identity and Access Management (IAM) och Microsoft Entra ID finns i:
- Microsoft Entra-identitetshantering och åtkomsthantering för AWS
- Mappa AWS IAM-begrepp till liknande begrepp i Azure
Den här guiden beskriver hur AKS-kluster, inbyggda tjänster och tillägg använder hanterade identiteter för att komma åt Azure-resurser som lastbalanserare och hanterade diskar. Artikeln visar också hur du använder Microsoft Entra-arbetsbelastnings-ID så att AKS-arbetsbelastningar kan komma åt Azure-resurser utan att behöva en anslutningssträng, åtkomstnyckel eller användarautentiseringsuppgifter.
Kommentar
Den här artikeln är en del av en serie artiklar som hjälper proffs som är bekanta med Amazon EKS att förstå Azure Kubernetes Service (AKS).
Amazon EKS Identity and Access Management
Amazon Elastic Kubernetes Service (EKS) innehåller inbyggda alternativ för att hantera identitets- och åtkomsthantering i Kubernetes-poddar. Dessa alternativ omfattar IAM-roller för tjänstkonton och Amazon EKS-tjänstlänkade roller.
IAM-roller för tjänstkonton
Med IAM-roller för tjänstkonton kan du associera IAM-roller med Kubernetes-tjänstkonton. Den här associationen ger AWS-behörigheter till containrarna i alla poddar som använder tjänstkontot. Fördelarna med att använda IAM-roller för tjänstkonton är följande:
Minsta behörighet: Du kan tilldela specifika IAM-behörigheter till ett tjänstkonto, vilket säkerställer att endast poddar som använder det tjänstkontot har åtkomst till dessa behörigheter. Detta eliminerar behovet av att bevilja utökade behörigheter till nod-IAM-rollen för alla poddar på en nod, vilket ger en säkrare och mer detaljerad metod. Dessutom eliminerar den här funktionen behovet av lösningar från tredje part som kube2iam. Mer information finns i IAM-roller för tjänstkonton.
Isolering av autentiseringsuppgifter: Varje container i en podd kan bara hämta autentiseringsuppgifterna för den IAM-roll som är associerad med respektive tjänstkonto. Den här isoleringen säkerställer att en container inte kan komma åt autentiseringsuppgifter som tillhör en annan container i en annan podd.
Auditability: Amazon EKS utnyttjar Amazon CloudTrail- för att ge åtkomst och händelseloggning, vilket underlättar granskning och efterlevnad i efterhand.
Mer information om IAM-roller för tjänstkonton finns i den officiella dokumentationen.
Amazon EKS-tjänstlänkade roller
Amazon EKS-tjänstlänkade roller är unika IAM-roller som är direkt länkade till Amazon EKS. Dessa fördefinierade roller innehåller alla nödvändiga behörigheter som krävs för att anropa AWS-tjänster för den associerade rollens räkning. Den huvudsakliga tjänstlänkade rollen för Amazon EKS är IAM-rollen Amazon EKS-nod.
Amazon EKS-noden kubelet daemon använder Amazon EKS-nodens IAM-roll för att göra API-anrop till AWS-tjänster för nodens räkning. IAM-instansprofilen och tillhörande principer ger behörighet för dessa API-anrop. Den här konfigurationen förenklar hanteringen av IAM-roller för noder i EKS-klustret.
Mer information om Amazon EKS-tjänstlänkade roller finns i den officiella dokumentationen.
Ytterligare information
Förutom IAM-roller för tjänstkonton och Amazon EKS-tjänstlänkade roller finns det andra viktiga aspekter av att hantera identitet och åtkomst i Amazon EKS.
Amazon EKS RBAC Authorization: Amazon EKS stöder rollbaserad åtkomstkontroll (RBAC), så att du kan definiera detaljerade behörigheter för Kubernetes-resurser i klustret.
AWS Identity and Access Management (IAM): IAM tillhandahåller en omfattande identitetshanteringslösning för AWS-tjänster, inklusive EKS. Det gör att du kan skapa och hantera användare, grupper och roller för att styra åtkomsten till dina EKS-resurser.
Amazon EKS-säkerhetsgrupper: Med Amazon EKS kan du använda säkerhetsgruppsregler för poddar som körs i klustret för att styra inkommande och utgående trafik.
Mer information om hur du hanterar identitets- och åtkomsthantering i Amazon EKS finns i den officiella Amazon EKS-dokumentationen.
AKS-klusterhanterade identiteter
Azure Kubernetes Service-kluster (AKS) kräver en Microsoft Entra-identitet för att få åtkomst till Azure-resurser som lastbalanserare och hanterade diskar. Hanterade identiteter för Azure-resurser är det rekommenderade sättet att auktorisera åtkomst från ett AKS-kluster till andra Azure-tjänster.
Vad är hanterade identiteter?
En vanlig utmaning för utvecklare är hanteringen av hemligheter, autentiseringsuppgifter, certifikat och nycklar som används för att skydda kommunikationen mellan tjänster. Hanterade identiteter eliminera behovet av att utvecklare hanterar dessa autentiseringsuppgifter. Med hanterade identiteter kan du autentisera ditt AKS-kluster utan att hantera autentiseringsuppgifter eller inkludera dem i koden. Med hanterade identiteter tilldelar du en rollbaserad åtkomstkontroll i Azure (Azure RBAC) roll till identiteten, vilket ger den behörighet till specifika resurser i Azure.
Här är två typer av hanterade identiteter:
Systemtilldelade. Med vissa Azure-resurser, till exempel virtuella datorer, kan du aktivera en hanterad identitet direkt på resursen. När du aktiverar en systemtilldelad hanterad identitet:
- Ett huvudnamn för tjänsten av en särskild typ skapas i Microsoft Entra-ID för identiteten. Tjänstens huvudnamn är kopplat till livscykeln för den Azure-resursen. När Azure-resursen tas bort tar Azure automatiskt bort tjänstens huvudnamn åt dig.
- Avsiktligt kan endast den Azure-resursen använda den här identiteten för att begära token från Microsoft Entra-ID.
- Du ger den hanterade identiteten åtkomst till en eller flera tjänster.
- Namnet på det systemtilldelade tjänstens huvudnamn är alltid samma som namnet på den Azure-resurs som den har skapats för.
Användartilldelad. Du kan också skapa en hanterad identitet som en fristående Azure-resurs. Du kan skapa en användartilldelad hanterad identitet och tilldela den till en eller flera Azure-resurser. När du aktiverar en användartilldelad hanterad identitet:
- Ett huvudnamn för tjänsten av en särskild typ skapas i Microsoft Entra-ID för identiteten. Tjänstens huvudnamn hanteras separat från de resurser som använder det.
- Användartilldelade identiteter kan användas av flera resurser.
- Du ger den hanterade identiteten åtkomst till en eller flera tjänster.
Mer information om skillnaderna mellan de två typerna av hanterade identiteter finns i Hanterade identitetstyper.
Hanterade identiteter i Azure Kubernetes Service (AKS)
Dessa två typer av hanterade identiteter liknar dem eftersom du kan använda någon av typerna för att auktorisera åtkomst till Azure-resurser från ditt AKS-kluster. Den viktigaste skillnaden mellan dem är att en systemtilldelad hanterad identitet är associerad med en enda Azure-resurs som ett AKS-kluster, medan en användartilldelad hanterad identitet i sig är en fristående Azure-resurs. Mer information om skillnaderna mellan olika typer av hanterade identiteter finns i Hanterade identitetstyper i Hanterade identiteter för Azure-resurser.
Det finns tre typer av hanterade identiteter som du kan använda med ett AKS-kluster:
Systemtilldelad hanterad identitet: Den här typen av hanterad identitet är associerad med en enda Azure-resurs, till exempel ett AKS-kluster. Den finns endast för klustrets livscykel.
Användartilldelad hanterad identitet: En användartilldelad hanterad identitet är en fristående Azure-resurs som du kan använda för att auktorisera åtkomst till andra Azure-tjänster från ditt AKS-kluster. Den bevaras separat från klustret och kan användas av flera Azure-resurser.
Fördefinierad kubelet-hanterad identitet: Det här är en valfri användartilldelad identitet som kan användas av kubelet för att få åtkomst till andra resurser i Azure. Om ingen användartilldelad hanterad identitet har angetts för kubelet skapar AKS en användartilldelad kubelet-identitet i nodresursgruppen.
Hur använder AKS hanterade identiteter?
När du distribuerar ett AKS-kluster skapas automatiskt en systemtilldelad hanterad identitet åt dig. Du kan också välja att skapa klustret med en användartilldelad hanterad identitet. Klustret använder den här hanterade identiteten för att begära token från Microsoft Entra-ID, som sedan används för att auktorisera åtkomst till andra resurser som körs i Azure.
Genom att tilldela en Azure RBAC-roll till den hanterade identiteten kan du ge klustret behörighet att komma åt specifika resurser. Du kan till exempel tilldela den hanterade identiteten en Azure RBAC-roll som gör att den kan komma åt hemligheter i ett Azure Key Vault. På så sätt kan du enkelt auktorisera åtkomst till klustret utan att hantera autentiseringsuppgifter.
Använda hanterade identiteter i AKS
När du använder hanterade identiteter i AKS behöver du inte etablera eller rotera några hemligheter. Azure hanterar identitetens autentiseringsuppgifter åt dig. På så sätt kan du auktorisera åtkomst från dina program utan att hantera några ytterligare hemligheter.
Om du redan har ett AKS-kluster som använder en hanterad identitet kan du uppdatera det till en annan typ av hanterad identitet. Observera dock att det kan uppstå en fördröjning medan kontrollplanets komponenter växlar till den nya identiteten. Den här processen kan ta flera timmar, och under den här tiden fortsätter kontrollplanskomponenterna att använda den gamla identiteten tills dess token upphör att gälla.
Sammanfattning av hanterade identiteter som används av AKS
AKS använder olika typer av hanterade identiteter för att aktivera olika inbyggda tjänster och tillägg. Här är en sammanfattning av de hanterade identiteter som används av AKS:
| Identitet | Användningsfall | Standardbehörigheter |
|---|---|---|
| Kontrollplan (systemtilldelad) | Används av AKS-kontrollplanskomponenter för att hantera klusterresurser, inklusive inkommande lastbalanserare, AKS-hanterade offentliga IP-adresser, Autoskalning av kluster, Azure Disk, Fil och Blob CSI-drivrutiner. | Deltagarroll för nodresursgrupp |
| Kubelet (användartilldelad) | Används för autentisering med Azure Container Registry (ACR). | N/A (för Kubernetes v1.15+) |
| Tilläggsidentiteter (t.ex. AzureNPM, AzureCNI-nätverksövervakning, Azure Policy, Calico osv.) | Ingen identitet krävs för dessa tillägg. | Ej tillämpligt |
| Programroutning | Hanterar Azure DNS- och Azure Key Vault-certifikat. | Nyckelvalvshemligheter Användarroll för Key Vault, DNS-zondeltagareroll för DNS-zoner, privat DNS-zondeltagareroll för privata DNS-zoner |
| Ingress Application Gateway | Hanterar nödvändiga nätverksresurser. | Deltagarroll för nodresursgrupp |
| OMS-agent | Används för att skicka AKS-mått till Azure Monitor. | Övervaka utgivarrollen för mått |
| Virtuell nod (ACI-anslutningsprogram) | Hanterar nödvändiga nätverksresurser för Azure Container Instances (ACI). | Deltagarroll för nodresursgrupp |
| Kostnadsanalys | Används för att samla in kostnadsallokeringsdata. | Ej tillämpligt |
| Arbetsbelastningsidentitet (Microsoft Entra-arbetsbelastnings-ID) | Gör det möjligt för program att på ett säkert sätt komma åt molnresurser med Microsoft Entra-arbetsbelastnings-ID. | Ej tillämpligt |
Mer information om hanterade identiteter i AKS finns i Använda en hanterad identitet i Azure Kubernetes Service.
Microsoft Entra-arbetsbelastnings-ID för Kubernetes
Microsoft Entra Workload ID integreras med Kubernetes för att aktivera arbetsbelastningar som distribueras i ett AKS-kluster för åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. Den använder funktionerna som är inbyggda i Kubernetes för att federera med externa identitetsprovidrar. Mer information finns i Använda Microsoft Entra-arbetsbelastnings-ID med Azure Kubernetes Service.
Om du vill använda Microsoft Entra-arbetsbelastnings-ID måste du konfigurera ett tjänstkonto i Kubernetes. Det här tjänstkontot används sedan av poddar för att autentisera och komma åt Azure-resurser på ett säkert sätt. Microsoft Entra-arbetsbelastnings-ID fungerar bra med Azure Identity-klientbibliotek eller MSAL-samlingen (Microsoft Authentication Library) tillsammans med programregistrering.
För att fullt ut utnyttja Microsoft Entra-arbetsbelastnings-ID i ett Kubernetes-kluster måste du konfigurera AKS-klustret för att utfärda token och publicera ett OIDC-identifieringsdokument för tokenverifiering. Mer information finns i Skapa en OpenID Connect-provider på Azure Kubernetes Service.
Du måste också konfigurera Microsoft Entra-programmen så att de litar på Kubernetes-token. Utvecklare kan sedan konfigurera sina distributioner så att de använder Kubernetes-tjänstkonton för att hämta token, som sedan byts ut mot Microsoft Entra-token via Microsoft Entra-arbetsbelastnings-ID. Slutligen kan AKS-klusterarbetsbelastningar använda dessa Microsoft Entra-token för säker åtkomst till skyddade resurser i Azure.
Som du ser i följande diagram blir Kubernetes-klustret en utfärdare av säkerhetstoken som utfärdar token till Kubernetes-tjänstkonton. Du kan konfigurera dessa token så att de är betrodda i Microsoft Entra-program. Token kan sedan bytas ut mot Microsoft Entra-åtkomsttoken med hjälp av Azure Identity SDK:er eller Microsoft Authentication Library (MSAL).
- Agenten
kubeletprojicerar en tjänstkontotoken till arbetsbelastningen på en konfigurerbar filsökväg. - Kubernetes-arbetsbelastningen skickar den beräknade, signerade tjänstkontotoken till Microsoft Entra-ID:t och begär en åtkomsttoken.
- Microsoft Entra ID använder ett OIDC-identifieringsdokument för att kontrollera förtroendet för den användardefinierade hanterade identiteten eller registrerade programmet och verifiera den inkommande token.
- Microsoft Entra ID utfärdar en säkerhetsåtkomsttoken.
- Kubernetes-arbetsbelastningen får åtkomst till Azure-resurser med hjälp av Microsoft Entra-åtkomsttoken.
Mer information, dokumentation och automatisering som rör Microsoft Entra-arbetsbelastnings-ID finns i följande resurser:
- Azure Workload Identity-projekt med öppen källkod
- Identitetsfederation för arbetsbelastning
- Microsoft Entra-arbetsbelastnings-ID-federation med Kubernetes
- Microsoft Entra-arbetsbelastnings-ID-federation med externa OIDC-identitetsprovidrar
- Minimal Microsoft Entra-arbetsbelastnings-ID-federation
- dokumentation om Microsoft Entra-arbetsbelastnings-ID
- Snabbstart för Microsoft Entra-arbetsbelastnings-ID
- exempel: Använd Microsoft Entra-arbetsbelastnings-ID för Kubernetes med en användartilldelad hanterad identitet i ett .NET Standard-program
Exempel på arbetsbelastning
En exempelarbetsbelastning som körs på ett AKS-kluster består av en klientdel och en serverdelstjänst. Dessa tjänster använder Microsoft Entra-arbetsbelastnings-ID för att få åtkomst till Azure-tjänster, inklusive Azure Key Vault, Azure Cosmos DB, Azure Storage-konto och Azure Service Bus-namnrymd. För att konfigurera den här exempelarbetsbelastningen måste följande krav uppfyllas:
- Konfigurera ett AKS-kluster med OpenID Connect-utfärdare och Microsoft Entra-arbetsbelastnings-ID aktiverat.
- Skapa ett Kubernetes -tjänstkonto i arbetsbelastningen namnområde.
- Skapa en Microsoft Entra-användartilldelad hanterad identitet eller registrerat program.
- Upprätta en federerad identitetsautentisering mellan microsoft entra-hanterad identitet eller registrerat program och arbetsbelastningstjänstkontot.
- Tilldela nödvändiga roller med lämpliga behörigheter till den Hanterade Microsoft Entra-identiteten eller det registrerade programmet.
- Distribuera arbetsbelastningen och verifiera autentiseringen med arbetsbelastningsidentiteten.
Meddelandeflöde för Microsoft Entra-arbetsbelastnings-ID
I det här exemplet hämtar klientdels- och serverdelsprogram Microsoft Entra-säkerhetstoken för åtkomst till PaaS-tjänster (Azure Platform as a Service). Följande diagram illustrerar meddelandeflödet:
Ladda ned en Visio-fil med den här arkitekturen.
- Kubernetes utfärdar en token till podden när den schemaläggs på en nod, baserat på podden eller distributionsspecifikationen.
- Podden skickar den OIDC-utfärdade token till Microsoft Entra-ID:t för att begära en Microsoft Entra-token för den specifika
appIdoch resursen. - Microsoft Entra-ID kontrollerar förtroendet för programmet och validerar den inkommande token.
- Microsoft Entra ID utfärdar en säkerhetstoken:
{sub: appId, aud: requested-audience}. - Podden använder Microsoft Entra-token för att komma åt Azure-målresursen.
Så här använder du Microsoft Entra Workload ID från slutpunkt till slutpunkt i ett Kubernetes-kluster:
- Du konfigurerar AKS-klustret för att utfärda token och publicera ett OIDC-identifieringsdokument för att tillåta validering av dessa token.
- Du konfigurerar Microsoft Entra-programmen så att de litar på Kubernetes-token.
- Utvecklare konfigurerar sina distributioner för att använda Kubernetes-tjänstkonton för att hämta Kubernetes-token.
- Microsoft Entra-arbetsbelastnings-ID:t utbyter Kubernetes-token för Microsoft Entra-token.
- AKS-klusterarbetsbelastningar använder Microsoft Entra-token för att komma åt skyddade resurser, till exempel Microsoft Graph.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- Paolo Salvatori | Huvudtjänsttekniker
- Martin Gjoshevski | Senior Service Engineer
Övriga medarbetare:
- Laura Nicolas | Senior programvarutekniker
- Chad Kittel | Huvudprogramtekniker
- Ed Price | Senior Content Program Manager
- Theano Petersen | Teknisk författare
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
- AKS för Amazon EKS-proffs
- Övervakning och loggning av Kubernetes
- Säker nätverksåtkomst till Kubernetes
- Lagringsalternativ för ett Kubernetes-kluster
- Kostnadshantering för Kubernetes
- Hantering av Kubernetes-noder och nodpooler
- Klusterstyrning
- Microsoft Entra-identitetshantering och åtkomsthantering för AWS