Redigera

Dela via

Kubernetes-arbetsbelastningsidentitet och åtkomst

Microsoft Entra ID
Azure Kubernetes Service (AKS)

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:

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 niska veze, å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 EKS har två inbyggda alternativ för att anropa AWS-tjänster inifrån en Kubernetes-podd: IAM-roller för tjänstkonton och Amazon EKS-tjänstlänkade roller.

IAM-roller för tjänstkonton associerar IAM-roller med ett Kubernetes-tjänstkonto. Det här tjänstkontot ger AWS-behörigheter till containrarna i alla poddar som använder tjänstkontot. IAM-roller för tjänstkonton ger följande fördelar:

  • Minsta behörighet: Du behöver inte ge utökade behörigheter till nod-IAM-rollen för poddar på noden för att anropa AWS-API:er. Du kan begränsa IAM-behörigheter till ett tjänstkonto och endast poddar som använder det tjänstkontot har åtkomst till dessa behörigheter. Den här funktionen eliminerar också behovet av lösningar från tredje part, till exempel kiam eller kube2iam.

  • Isolering av autentiseringsuppgifter: En container kan bara hämta autentiseringsuppgifter för den IAM-roll som är associerad med det tjänstkonto som den tillhör. En container har aldrig åtkomst till autentiseringsuppgifter för en annan container som tillhör en annan podd.

  • Granskningsbarhet: Amazon CloudTrail ger åtkomst och händelseloggning för att säkerställa granskning i efterhand.

Amazon EKS-tjänstlänkade roller är unika IAM-roller som är länkade direkt till Amazon EKS. Tjänstlänkade roller är fördefinierade av Amazon EKS och innehåller alla behörigheter som krävs för att anropa andra AWS-tjänster för rollens räkning. För Amazon EKS-nodens IAM-roll anropar Amazon EKS-noddaemon kubelet AWS-API:er för nodens räkning. Noder får behörigheter för dessa API-anrop från en IAM-instansprofil och associerade principer.

AKS-klusterhanterade identiteter

Ett AKS-kluster kräver en identitet för åtkomst till Azure-resurser som lastbalanserare och hanterade diskar. Den här identiteten kan vara antingen en hanterad identitet eller ett huvudnamn för tjänsten. Som standard skapar skapandet av ett AKS-kluster automatiskt en systemtilldelad hanterad identitet. Azure-plattformen hanterar identiteten och du behöver inte etablera eller rotera några hemligheter. Mer information om Microsoft Entra-hanterade identiteter finns i Hanterade identiteter för Azure-resurser.

AKS skapar inte ett huvudnamn för tjänsten automatiskt, så om du vill använda tjänstens huvudnamn måste du skapa det. Tjänstens huvudnamn upphör så småningom att gälla och du måste förnya det för att klustret ska fungera. Att hantera tjänstens huvudnamn ökar komplexiteten, så det är enklare att använda hanterade identiteter.

Hanterade identiteter är i huvudsak omslutningar kring tjänstens huvudnamn som förenklar hanteringen. Samma behörighetskrav gäller både för tjänstens huvudnamn och hanterade identiteter. Hanterade identiteter använder certifikatbaserad autentisering. Varje autentiseringsuppgifter för hanterade identiteter har en giltighetstid på 90 dagar och roteras efter 45 dagar.

AKS använder både systemtilldelade och användartilldelade hanterade identitetstyper, och dessa identiteter är oföränderliga. När du skapar eller använder ett virtuellt AKS-nätverk, ansluten Azure-disk, statisk IP-adress, routningstabell eller användartilldelad kubelet identitet med resurser utanför nodresursgruppen lägger Azure CLI till rolltilldelningen automatiskt.

Om du använder en annan metod för att skapa AKS-klustret, till exempel en Bicep-mall, Azure Resource Manager-mall eller Terraform-modul, måste du använda huvud-ID:t för den klusterhanterade identiteten för att utföra en rolltilldelning. AKS-klusteridentiteten måste ha minst rollen Nätverksdeltagare i undernätet i ditt virtuella nätverk. Om du vill definiera en anpassad roll i stället för att använda den inbyggda rollen Nätverksdeltagare behöver du följande behörigheter:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

När klusteridentiteten behöver komma åt en befintlig resurs, till exempel när du distribuerar ett AKS-kluster till ett befintligt virtuellt nätverk, bör du använda en användartilldelad hanterad identitet. Om du använder en systemtilldelad kontrollplansidentitet kan resursprovidern inte hämta sitt huvud-ID innan klustret skapas, så det är omöjligt att skapa rätt rolltilldelningar före klusteretablering.

Sammanfattning av hanterade identiteter

AKS använder följande användartilldelade hanterade identiteter för inbyggda tjänster och tillägg.

Identitet Name Användningsfall Standardbehörigheter Ta med din egen identitet
Kontrollplan AKS-klusternamn Hanterar klusterresurser, inklusive inkommande lastbalanserare och AKS-hanterade offentliga IP-adresser, autoskalning av kluster samt CSI-drivrutiner för Azure Disk och Azure-filer Deltagarroll för nodresursgrupp Stöds
Kubelet AKS-klusternamn-agentpool Autentiserar med Azure Container Registry NA (för Kubernetes v1.15+) Stöds
Tillägg HTTPApplicationRouting Hanterar nödvändiga nätverksresurser Läsarroll för nodresursgrupp, deltagarroll för DNS-zon Nej
Tillägg Inkommande programgateway Hanterar nödvändiga nätverksresurser Deltagarroll för nodresursgrupp Nej
Tillägg omsagent Skicka AKS-mått till Azure Monitor Övervaka utgivarrollen för mått Nej
Tillägg Virtual-Node (ACIConnector) Hanterar nödvändiga nätverksresurser för Azure Container Instances Deltagarroll för nodresursgrupp Nej

Mer information finns i Använda en hanterad identitet i Azure Kubernetes Service.

Microsoft Entra-arbetsbelastnings-ID för Kubernetes

Kubernetes-arbetsbelastningar kräver autentiseringsuppgifter för Microsoft Entra-program för åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. En vanlig utmaning för utvecklare är att hantera hemligheter och autentiseringsuppgifter för att skydda kommunikationen mellan olika komponenter i en lösning.

Microsoft Entra-arbetsbelastnings-ID för Kubernetes eliminerar behovet av att hantera autentiseringsuppgifter för åtkomst till molntjänster som Azure Cosmos DB, Azure Key Vault eller Azure Blob Storage. Ett AKS-värdbaserat arbetsbelastningsprogram kan använda Microsoft Entra-arbetsbelastnings-ID för att få åtkomst till en Azure-hanterad tjänst med hjälp av en Microsoft Entra-säkerhetstoken, i stället för explicita autentiseringsuppgifter som en niska veze, användarnamn och lösenord eller primärnyckel.

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).

Diagram som visar ett förenklat arbetsflöde för en poddhanterad identitet i Azure.

  1. Agenten kubelet projicerar en tjänstkontotoken till arbetsbelastningen på en konfigurerbar filsökväg.
  2. Kubernetes-arbetsbelastningen skickar den beräknade, signerade tjänstkontotoken till Microsoft Entra-ID:t och begär en åtkomsttoken.
  3. 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.
  4. Microsoft Entra ID utfärdar en säkerhetsåtkomsttoken.
  5. Kubernetes-arbetsbelastningen får åtkomst till Azure-resurser med hjälp av Microsoft Entra-åtkomsttoken.

Microsoft Entra-arbetsbelastnings-ID-federation för Kubernetes stöds för närvarande endast för Microsoft Entra-program, men samma modell kan potentiellt utökas till hanterade Azure-identiteter.

Mer information, automatisering och dokumentation för Microsoft Entra-arbetsbelastnings-ID finns i:

Exempel på arbetsbelastning

Exempelarbetsbelastningen kör en klientdel och en serverdelstjänst i ett AKS-kluster. Arbetsbelastningstjänsterna använder Microsoft Entra-arbetsbelastnings-ID för att få åtkomst till följande Azure-tjänster med hjälp av Microsoft Entra-säkerhetstoken:

  • Azure Key Vault
  • Azure Cosmos DB
  • Azure-lagringskonto
  • Azure Service Bus-namnområde

Förutsättningar

  1. Konfigurera ett AKS-kluster med OIDC-utfärdaren aktiverad.
  2. Installera webhooken för muterande antagning.
  3. Skapa ett Kubernetes-tjänstkonto för arbetsbelastningarna.
  4. Skapa ett Microsoft Entra-program enligt snabbstarten.
  5. Tilldela roller med rätt behörigheter till nödvändiga Microsoft Entra-registrerade program.
  6. Upprätta en federerad identitetsautentiseringsuppgift mellan Microsoft Entra-programmet och utfärdaren och ämnet för tjänstkontot.
  7. Distribuera arbetsbelastningsprogrammet till AKS-klustret.

Meddelandeflöde för Microsoft Entra-arbetsbelastnings-ID

AKS-program får säkerhetstoken för sitt tjänstkonto från OIDC-utfärdaren av AKS-klustret. Microsoft Entra-arbetsbelastnings-ID:t utbyter säkerhetstoken med säkerhetstoken som utfärdats av Microsoft Entra-ID och programmen använder microsoft Entra-ID-utfärdade säkerhetstoken för att få åtkomst till Azure-resurser.

Följande diagram visar hur klientdels- och serverdelsprogram hämtar Microsoft Entra-säkerhetstoken för att använda PaaS-tjänster (Plattform som en tjänst).

Diagram som visar ett exempelprogram som använder Microsoft Entra-arbetsbelastnings-ID.

Ladda ned en Visio-fil med den här arkitekturen.

  1. Kubernetes utfärdar en token till podden när den schemaläggs på en nod, baserat på podden eller distributionsspecifikationen.
  2. 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 appId och resursen.
  3. Microsoft Entra-ID kontrollerar förtroendet för programmet och validerar den inkommande token.
  4. Microsoft Entra ID utfärdar en säkerhetstoken: {sub: appId, aud: requested-audience}.
  5. 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:

  1. Du konfigurerar AKS-klustret för att utfärda token och publicera ett OIDC-identifieringsdokument för att tillåta validering av dessa token.
  2. Du konfigurerar Microsoft Entra-programmen så att de litar på Kubernetes-token.
  3. Utvecklare konfigurerar sina distributioner för att använda Kubernetes-tjänstkonton för att hämta Kubernetes-token.
  4. Microsoft Entra-arbetsbelastnings-ID:t utbyter Kubernetes-token för Microsoft Entra-token.
  5. 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:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg