Åtkomst- och identitetsalternativ för Azure Kubernetes Service (AKS)

Gäller för: ✔️ AKS Automatic ✔️ AKS Standard

AKS använder identitet i fem olika scenarier. Varje scenario besvarar en annan fråga och har en egen konfigurationsmodell.

För de flesta AKS-arbetsbelastningar i produktion är AKS Automatic den rekommenderade standardinställningen eftersom den börjar med en produktionsklar plattformsbaslinje, inklusive identitetsrelaterade standardvärden, samtidigt som samma AKS-identitetsmodell som beskrivs i den här artikeln bevaras.

Den här artikeln ger en kort introduktion till varje scenario, förklarar hur vägledningen mappar till AKS Automatic och AKS Standard och pekar på djupdykningsdokumentationen.

De fem identitetsscenarierna i AKS

Scenario Frågan den besvarar Dokumentation för djupgående analys
A. Kubernetes-kontrollplansautentisering Vem är det som anropar Kubernetes-API:et? Begrepp för klusterautentisering, externa identitetsprovidrar
B. Kubernetes-kontrollplansauktorisering Vad kan anroparen göra när den autentiseras till Kubernetes-API:et? Begrepp för klusterauktorisering
C. AKS-resursauktorisering (Azure Resource Manager) Vem kan utföra åtgärder på Azure-nivå på AKS-resursen, till exempel att hämta kubeconfig? Begränsa åtkomsten till klusterkonfigurationsfilen, inbyggda Azure-roller
D. Klusteridentitet (kluster → Azure) Hur fungerar AKS-klustret i Azure för att hantera resurser åt dig? Hanterade identiteter i AKS
E. Arbetsbelastningsidentitet (podd → Azure) Hur autentiserar poddar till Azure-tjänster som Key Vault eller Storage? Microsoft Entra Workload ID översikt

Identitetsstatus i AKS Automatic och AKS Standard

De fem identitetsscenarierna i den här artikeln gäller både AKS Automatic och AKS Standard. Den största skillnaden är driftstatus:

  • AKS Automatic tillhandahåller mer förkonfigurerade identitets- och säkerhetsstandarder.
  • AKS Standard ger mer manuell kontroll och kräver fler konfigurationsalternativ.

Använd AKS Automatic som standardstartpunkt för de flesta produktionsarbetsbelastningar och använd AKS Standard när du behöver en djupare anpassad plattformskonfiguration.

En översikt över AKS Automatic finns i Introduktion till Azure Kubernetes Service (AKS) Automatisk.

Jämförelse av identitetssäkerhetsstatus för AKS Automatic och AKS Standard

Identitetsområde Automatisk AKS-position AKS Standard-hållning Learn more
Kubernetes API-autentisering Produktionsorienterade standardvärden med Microsoft Entra integrering som rekommenderad modell Konfigurerbara, inklusive lokala konton och Entra-integreringsalternativ Begrepp för klusterautentisering
Kubernetes API-auktorisering Azure RBAC för Kubernetes-auktorisering är förkonfigurerat Modell med lokalt konto först och auktoriseringsmodell vald av klusterkonfigurationen Begrepp för klusterauktorisering
AKS-resursauktorisering Använder standard Azure RBAC-modell för AKS-resursåtgärder Använder standard Azure RBAC-modell för AKS-resursåtgärder Kontrollera kubeconfig-åtkomst
Klusteridentitet Använder hanterad identitetsmodell med standardvärden för produktionsbaslinje Använder hanterad identitetsmodell med operatorvald konfiguration Hanterade identiteter i AKS
Arbetsbelastningsidentitet Arbetsbelastningsidentitet och OIDC-utfärdare är förkonfigurerade Valfritt och konfigurerat av operatorn Översikt över arbetsbelastningsidentiteter

Resten av den här artikeln ger en kort orientering till varje scenario.

A. Kubernetes-kontrollplansautentisering

Kubernetes-kontrollplansautentisering upprättar identiteten för en användare eller tjänstens huvudnamn som anropar Kubernetes API-servern. AKS stöder:

  • Microsoft Entra ID (rekommenderas): Använd Entra ID identiteter och grupper för att logga in på klustret. Microsoft Entra-integrering förbereder och hanterar rotationen av integrationen åt dig. Information om hur du aktiverar finns i Använda Microsoft Entra-integrering.
  • Lokala konton: Ett inbyggt klusteradministratörscertifikat som kringgår Entra ID. Vi rekommenderar att du inaktiverar lokala konton i produktion. Se Hantera lokala konton.
  • Externa identitetsprovidrar: Använd en OIDC-kompatibel identitetsprovider än Microsoft Entra ID. Se Extern identitetsproviderautentisering.

För de flesta produktionsarbetsbelastningar börjar du med AKS Automatic och Microsoft Entra integrering.

En djupgående titt på hur AKS autentiserar Kubernetes API-begäranden finns i Begrepp för klusterautentisering.

B. Kubernetes-kontrollplansauktorisering

När en anropare har autentiserats till Kubernetes-API:et auktoriserar AKS begäran med hjälp av en (eller båda) av två modeller:

  • Kubernetes RBAC: Den interna Kubernetes Role, ClusterRoleoch RoleBinding modellen som utvärderas av API-servern. Behörigheter finns i klustret som Kubernetes-objekt.
  • Microsoft Entra ID auktorisering: En AKS-auktoriseringswebbhooks delegerar auktoriseringsbeslut till Microsoft Entra ID med hjälp av Azure rolltilldelningar. Azure RBAC-rolltilldelningar med dataActions stöds för alla kubernetes API-standardresurser och rolltilldelningar med Azure ABAC-villkor stöds för anpassade resurser. Hantera behörigheter centralt i Microsoft Entra ID för att styra många kluster från en enskild rolltilldelning i prenumeration, hanteringsgrupp eller resursgruppsomfång.

I AKS Automatic är Azure RBAC för auktorisering i Kubernetes förkonfigurerad som en del av den produktionsklara standardkonfigurationen.

En jämförelse och vägledning om när du ska använda varje modell finns i Begrepp för klusterauktorisering.

C. AKS-resursauktorisering (Azure Resource Manager)

Förutom att auktorisera anrop till Kubernetes-API:et måste du även auktorisera åtgärder på Azure-nivå på själva AKS-resursen. Det vanligaste exemplet är att styra vem som kan hämta ett klusterskubeconfig, vilket är en fristående Azure Resource Manager-åtgärd som du kan styra granulärt med Azure RBAC. Den här åtgärden använder standard Azure RBAC mot Microsoft.ContainerService resursprovidern, är separat från Kubernetes API-auktorisering och tillämpar samma sätt på AKS Automatic och AKS Standard. Mer information finns i Begränsa åtkomsten till klusterkonfigurationsfilen och de inbyggda rollerna i Azure inbyggda roller.

D. Klusteridentitet (kluster → Azure)

AKS-kluster använder Azure-hanterade identiteter för att agera på Azure-resurser åt dig – till exempel för att skapa lastbalanserare, koppla diskar eller hämta avbildningar från Azure Container Registry. Huvudidentiteterna är:

  • Kontrollplansidentitet: Används av klusterkontrollplanet för att hantera Azure resurser för klustret.
  • Kubelet-identitet: Används av kubeleten på varje nod för att autentisera till tjänster som Azure Container Registry.
  • Identitet för tillägg och tilläggsmoduler: Vissa AKS-tillägg och tilläggsmoduler använder sina egna hanterade identiteter.

AKS Automatic behåller samma identitetsmodell samtidigt som konfigurationsfriktionen minskar genom förkonfigurerade standardvärden för produktion.

Mer information om varje identitetstyp och hur du använder systemtilldelade eller användartilldelade identiteter finns i Hanterade identiteter i AKS.

E. Arbetsbelastningsidentitet (podd → Azure)

Med arbetsbelastningsidentitet kan poddar som körs i AKS-klustret autentiseras mot Microsoft Entra-skyddade Azure-tjänster (till exempel Key Vault, Storage eller Cosmos DB) utan att lagra hemligheter i klustret. AKS använder Microsoft Entra Workload ID, som projicerar en Kubernetes-tjänstkontotoken federerad till ett Microsoft Entra-program eller användartilldelad hanterad identitet.

AKS Automatic innehåller arbetsbelastningsidentitet och OIDC-utfärdare som förkonfigurerade standardvärden. I AKS Standard är dessa funktioner valfria och konfigurerade av operatorn.

Använd inte den föråldrade Microsoft Entra-poddhanterade identiteten för nya tillämpningar.

Beslutsguide

Mål Använda dessa dokument
Börja med en produktionsklar identitetsbaslinje för de flesta arbetsbelastningar Introduktion till AKS Automatic
Logga in användare i klustret med Microsoft Entra-ID Aktivera Microsoft Entra-integrering
Styra vem som kan göra vad i Kubernetes-API:et i många kluster Använda Microsoft Entra ID-auktorisering för Kubernetes API
Begränsa åtkomsten till specifika anpassade resurstyper ABAC-villkor i Entra ID-auktorisering
Skapa behörigheter per kluster per namnområde som Kubernetes-objekt Använd Kubernetes RBAC med Entra-integration
Låt klustret hämta från ACR eller ansluta diskar Hanterade identiteter i AKS
Låt poddar nå Key Vault eller Storage utan hemligheter Microsoft Entra Workload ID översikt
Begränsa vem som kan ladda ned klustret kubeconfig Begränsa åtkomsten till klusterkonfigurationsfilen
Skapa ett produktionsklart kluster med standardidentitetsstatus Skapa ett AKS-automatiskt kluster

Referens för AKS-tjänstbehörigheter

Information om de Azure behörigheter som AKS använder (identiteten som skapar klustret, klusteridentiteten vid körning, ytterligare behörigheter för klusteridentitet och ÅTKOMST till AKS-noder) finns i REFERENS för AKS-tjänstbehörigheter.

Relaterat innehåll

Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar:

  • Last updated on