Metodtips för autentisering och auktorisering i Azure Kubernetes Service (AKS)

  • Artikel

När du distribuerar och underhåller kluster i Azure Kubernetes Service (AKS) implementerar du sätt att hantera åtkomst till resurser och tjänster. Utan dessa kontroller:

  • Konton kan ha åtkomst till onödiga resurser och tjänster.
  • Det kan vara svårt att spåra autentiseringsuppgifter som används för att göra ändringar.

I den här artikeln går vi igenom vilka rekommenderade metoder en klusteroperator kan följa för att hantera åtkomst och identitet för AKS-kluster. Du lär dig att:

  • Autentisera AKS-klusteranvändare med Microsoft Entra-ID.
  • Kontrollera åtkomsten till resurser med rollbaserad åtkomstkontroll i Kubernetes (Kubernetes RBAC).
  • Använd Azure RBAC för att kontrollera åtkomsten till AKS-resursen, Kubernetes-API:et i stor skala och kubeconfig.
  • Använd en arbetsbelastningsidentitet för att komma åt Azure-resurser från dina poddar.

Varning

Den öppen källkod Microsoft Entra-poddhanterade identiteten (förhandsversion) i Azure Kubernetes Service har inaktuell från och med 2022-01-24.

Om du har microsoft entra poddhanterad identitet aktiverad i ditt AKS-kluster eller överväger att implementera den rekommenderar vi att du läser artikeln översikt över arbetsbelastningsidentitet för att förstå våra rekommendationer och alternativ för att konfigurera klustret så att du använder ett Microsoft Entra-arbetsbelastnings-ID (förhandsversion). Den här autentiseringsmetoden ersätter poddhanterad identitet (förhandsversion), som integreras med kubernetes interna funktioner för att federera med externa identitetsprovidrar.

Använda Microsoft Entra-ID

Vägledning för bästa praxis

Distribuera AKS-kluster med Microsoft Entra-integrering. Genom att använda Microsoft Entra ID centraliseras identitetshanteringsskiktet. Ändringar i användarkonto- eller gruppstatus uppdateras automatiskt i åtkomsten till AKS-klustret. Omfångsanvändare eller grupper till minsta behörighetsbelopp med hjälp av roller, klusterroller eller bindningar.

Dina Kubernetes-klusterutvecklare och programägare behöver åtkomst till olika resurser. Kubernetes saknar en identitetshanteringslösning som du kan använda för att styra de resurser som användarna kan interagera med. I stället kan du integrera klustret med en befintlig identitetslösning som Microsoft Entra ID, en företagsklar identitetshanteringslösning.

Med Microsoft Entra-integrerade kluster i AKS skapar du Roller eller KlusterRoller som definierar åtkomstbehörigheter till resurser. Sedan binder du rollerna till användare eller grupper från Microsoft Entra-ID. Läs mer om dessa Kubernetes RBAC i nästa avsnitt. Microsoft Entra-integrering och hur du styr åtkomsten till resurser visas i följande diagram:

Cluster-level authentication for Microsoft Entra integration with AKS

  1. Utvecklaren autentiserar med Microsoft Entra-ID.
  2. Microsoft Entra-tokenutfärdarslutpunkten utfärdar åtkomsttoken.
  3. Utvecklaren utför en åtgärd med hjälp av Microsoft Entra-token, till exempel kubectl create pod.
  4. Kubernetes validerar token med Microsoft Entra-ID och hämtar utvecklarens gruppmedlemskap.
  5. Kubernetes RBAC- och klusterprinciper tillämpas.
  6. Utvecklarens begäran lyckas baserat på tidigare validering av Microsoft Entra-gruppmedlemskap och Kubernetes RBAC och principer.

Information om hur du skapar ett AKS-kluster som använder Microsoft Entra-ID finns i Integrera Microsoft Entra-ID med AKS.

Använda rollbaserad Kubernetes-åtkomstkontroll (Kubernetes RBAC)

Vägledning för bästa praxis

Definiera användar- eller gruppbehörigheter för klusterresurser med Kubernetes RBAC. Skapa roller och bindningar som tilldelar minst antal behörigheter som krävs. Integrera med Microsoft Entra-ID för att automatiskt uppdatera användarstatus eller gruppmedlemskapsändringar och hålla åtkomsten till klusterresurser aktuell.

I Kubernetes ger du detaljerad åtkomstkontroll till klusterresurser. Du definierar behörigheter på klusternivå eller till specifika namnområden. Du avgör vilka resurser som kan hanteras och med vilka behörigheter. Sedan tillämpar du dessa roller på användare eller grupper med en bindning. Mer information om roller, klusterroller och bindningar finns i Åtkomst- och identitetsalternativ för Azure Kubernetes Service (AKS).

Du kan till exempel skapa en roll med fullständig åtkomst till resurser i namnområdet med namnet finance-app, som du ser i följande exempel på YAML-manifestet:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Sedan skapar du en RoleBinding och binder Microsoft Entra-användaren developer1@contoso.com till den, enligt följande YAML-manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

När developer1@contoso.com autentiseras mot AKS-klustret har de fullständig behörighet till resurser i namnområdet finance-app . På så sätt separerar du logiskt och styr åtkomsten till resurser. Använd Kubernetes RBAC med Microsoft Entra ID-integration.

Information om hur du använder Microsoft Entra-grupper för att styra åtkomsten till Kubernetes-resurser med Kubernetes RBAC finns i Kontrollera åtkomst till klusterresurser med rollbaserad åtkomstkontroll och Microsoft Entra-identiteter i AKS.

Använda Azure RBAC

Vägledning för bästa praxis

Använd Azure RBAC för att definiera den minsta nödvändiga användar- och gruppbehörigheten för AKS-resurser i en eller flera prenumerationer.

Det finns två åtkomstnivåer som krävs för att köra ett AKS-kluster fullt ut:

Använda poddhanterade identiteter

Varning

Den öppen källkod Microsoft Entra-poddhanterade identiteten (förhandsversion) i Azure Kubernetes Service har inaktuell från och med 2022-01-24.

Om du har microsoft entra poddhanterad identitet aktiverad i ditt AKS-kluster eller överväger att implementera den rekommenderar vi att du läser artikeln översikt över arbetsbelastningsidentitet för att förstå våra rekommendationer och alternativ för att konfigurera klustret så att du använder ett Microsoft Entra-arbetsbelastnings-ID (förhandsversion). Den här autentiseringsmetoden ersätter poddhanterad identitet (förhandsversion), som integreras med kubernetes interna funktioner för att federera med externa identitetsprovidrar.

Använd inte fasta autentiseringsuppgifter i poddar eller containeravbildningar eftersom de riskerar att exponeras eller missbrukas. Använd i stället poddidentiteter för att automatiskt begära åtkomst med hjälp av Microsoft Entra-ID.

För att få åtkomst till andra Azure-resurser, till exempel Azure Cosmos DB, Key Vault eller Blob Storage, behöver podden autentiseringsuppgifter. Du kan definiera autentiseringsuppgifter med containeravbildningen eller mata in dem som en Kubernetes-hemlighet. Hur som helst skulle du behöva skapa och tilldela dem manuellt. Vanligtvis återanvänds dessa autentiseringsuppgifter mellan poddar och roteras inte regelbundet.

Med poddhanterade identiteter (förhandsversion) för Azure-resurser begär du automatiskt åtkomst till tjänster via Microsoft Entra-ID. Poddhanterade identiteter är för närvarande i förhandsversion för AKS. Se dokumentationen Använd Microsoft Entra-poddhanterade identiteter i Azure Kubernetes Service (förhandsversion) för att komma igång.

Microsoft Entra poddhanterad identitet (förhandsversion) stöder två driftlägen:

  • Standardläge : I det här läget distribueras följande två komponenter till AKS-klustret:

    • Managed Identity Controller(MIC): En Kubernetes-kontrollant som bevakar ändringar i poddar, AzureIdentity och AzureIdentityBinding via Kubernetes API Server. När den identifierar en relevant ändring lägger MIC till eller tar bort AzureAssignedIdentity efter behov. När en podd schemaläggs tilldelar MIC den hanterade identiteten i Azure till den underliggande VM-skalningsuppsättningen som används av nodpoolen under fasen för att skapa den. När alla poddar som använder identiteten tas bort tas identiteten bort från den virtuella datorns skalningsuppsättning för nodpoolen, såvida inte samma hanterade identitet används av andra poddar. MIC vidtar liknande åtgärder när AzureIdentity eller AzureIdentityBinding skapas eller tas bort.

    • Nodhanterad identitet (NMI): är en podd som körs som en DaemonSet på varje nod i AKS-klustret. NMI fångar upp begäranden om säkerhetstoken till Azure Instance Metadata Service på varje nod. Den omdirigerar begäranden till sig själv och verifierar om podden har åtkomst till den identitet som den begär en token för och hämtar token från Microsoft Entra-klientorganisationen för programmets räkning.

  • Hanterat läge: I det här läget finns det bara NMI. Identiteten måste tilldelas och hanteras manuellt av användaren. Mer information finns i Poddidentitet i hanterat läge. När du i det här läget använder kommandot az aks pod-identity add för att lägga till en poddidentitet i ett AkS-kluster (Azure Kubernetes Service) skapas AzureIdentity och AzureIdentityBinding i det namnområde som anges av --namespace parametern, medan AKS-resursprovidern tilldelar den hanterade identitet som anges av parametern --identity-resource-id till vm-skalningsuppsättningen för varje nodpool i AKS-klustret.

Kommentar

Om du i stället bestämmer dig för att installera microsoft Entra-poddhanterad identitet med hjälp av AKS-klustertillägget använder konfigurationen managed läget.

Läget managed ger följande fördelar jämfört standardmed :

  • Identitetstilldelning på vm-skalningsuppsättningen för en nodpool kan ta upp 40–60-talet. Med cronjobs eller program som kräver åtkomst till identiteten och inte kan tolerera tilldelningsfördröjningen är det bäst att använda managed läget eftersom identiteten är förtilldelad till nodpoolens vm-skalningsuppsättning. Antingen manuellt eller med kommandot az aks pod-identity add .
  • I standard läge kräver MIC skrivbehörigheter för vm-skalningsuppsättningen som används av AKS-klustret och Managed Identity Operator behörighet för de användartilldelade hanterade identiteterna. När du kör i managed mode, eftersom det inte finns någon MIC, krävs inte rolltilldelningarna.

I stället för att manuellt definiera autentiseringsuppgifter för poddar begär poddhanterade identiteter en åtkomsttoken i realtid och använder den för att endast komma åt sina tilldelade resurser. I AKS finns det två komponenter som hanterar åtgärderna så att poddar kan använda hanterade identiteter:

  • Nodhanteringsidentitetsservern (NMI) är en podd som körs som en DaemonSet på varje nod i AKS-klustret. NMI-servern lyssnar efter poddförfrågningar till Azure-tjänster.
  • Azure-resursprovidern frågar Kubernetes API-servern och söker efter en Azure-identitetsmappning som motsvarar en podd.

När poddar begär en säkerhetstoken från Microsoft Entra-ID för åtkomst till en Azure-resurs omdirigerar nätverksregler trafiken till NMI-servern.

  1. NMI-servern:

    • Identifierar poddar som begär åtkomst till Azure-resurser baserat på deras fjärradress.
    • Frågar Azure-resursprovidern.

  2. Azure-resursprovidern söker efter Azure-identitetsmappningar i AKS-klustret.

  3. NMI-servern begär en åtkomsttoken från Microsoft Entra-ID baserat på poddens identitetsmappning.

  4. Microsoft Entra-ID ger åtkomst till NMI-servern, som returneras till podden.

    • Den här åtkomsttoken kan användas av podden för att sedan begära åtkomst till resurser i Azure.

I följande exempel skapar en utvecklare en podd som använder en hanterad identitet för att begära åtkomst till Azure SQL Database:

Pod identities allow a pod to automatically request access to other resources.

  1. Klusteroperatorn skapar ett tjänstkonto för att mappa identiteter när poddar begär åtkomst till resurser.
  2. NMI-servern distribueras för att vidarebefordra alla poddbegäranden, tillsammans med Azure-resursprovidern, för åtkomsttoken till Microsoft Entra-ID.
  3. En utvecklare distribuerar en podd med en hanterad identitet som begär en åtkomsttoken via NMI-servern.
  4. Token returneras till podden och används för att komma åt Azure SQL Database

Information om hur du använder poddhanterade identiteter finns i Använda Microsoft Entra-poddhanterade identiteter i Azure Kubernetes Service (förhandsversion).

Nästa steg

Den här artikeln om metodtips fokuserar på autentisering och auktorisering för ditt kluster och dina resurser. Om du vill implementera några av dessa metodtips kan du läsa följande artiklar:

Mer information om klusteråtgärder i AKS finns i följande metodtips: