Opties voor toegang en identiteit voor Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

AKS maakt gebruik van identiteit in vijf verschillende scenario's. Elk scenario beantwoordt een andere vraag en heeft een eigen configuratiemodel.

Voor de meeste AKS-workloads in productie is AKS Automatic de aanbevolen standaardinstelling, omdat deze begint met een platformbasislijn die gereed is voor productie, inclusief standaardinstellingen voor identiteiten, terwijl hetzelfde AKS-identiteitsmodel behouden blijft dat in dit artikel wordt beschreven.

Dit artikel geeft een korte inleiding op elk scenario, legt uit hoe de richtlijnen zich verhouden tot AKS Automatic en AKS Standard, en verwijst naar de verdiepende documentatie.

De vijf identiteitsscenario's in AKS

Scenario Vraag die het beantwoordt Diepgaande documentatie
Eén. Kubernetes-verificatie op het besturingsvlak Wie is de aanroeper die de Kubernetes-API aanroept? Concepten van clusterverificatie, externe id-providers
B. Autorisatie van kubernetes-besturingsvlak Wat mag de aanroeper doen nadat deze is geverifieerd bij de Kubernetes-API? Concepten voor clusterautorisatie
C. AKS-resourceautorisatie (Azure Resource Manager) Wie kan bewerkingen op Azure-niveau uitvoeren op de AKS-resource, zoals ophalen kubeconfig? Toegang tot clusterconfiguratiebestand beperken, ingebouwde Azure-rollen
D. Clusteridentiteit (cluster → Azure) Hoe handelt het AKS-cluster in Azure om namens u resources te beheren? Beheerde identiteiten in AKS
E. Workloadidentiteit (pod → Azure) Hoe worden pods geverifieerd bij Azure-services zoals Key Vault of Storage? Overzicht van de Microsoft Entra Workload-id

Identiteitspostuur in AKS Automatic en AKS Standard

De vijf identiteitsscenario's in dit artikel zijn van toepassing op zowel AKS Automatic als AKS Standard. Het belangrijkste verschil is operationele houding:

  • AKS Automatic biedt meer vooraf geconfigureerde standaardinstellingen voor identiteiten en beveiliging.
  • AKS Standard biedt meer handmatige controle en vereist meer configuratieopties.

Gebruik AKS Automatic als het standaardstartpunt voor de meeste productieworkloads en gebruik AKS Standard wanneer u een diepere aangepaste platformconfiguratie nodig hebt.

Zie Inleiding tot Azure Kubernetes Service (AKS) Automatic voor een overzicht van AKS Automatic.

Vergelijking van automatische AKS- en AKS-standaardidentiteitspostuur

Identiteitsgebied Automatische AKS-houding AKS Standard-houding Meer informatie
Kubernetes-API-verificatie Op productie gerichte standaardinstellingen met Microsoft Entra-integratie als het aanbevolen model Configureerbaar, inclusief lokale accounts en Opties voor Entra-integratie Concepten voor clusterverificatie
Kubernetes-API-autorisatie Azure RBAC voor Kubernetes-autorisatie vooraf is geconfigureerd Model waarbij lokale accounts voorrang hebben en autorisatiemodel geselecteerd via de clusterconfiguratie Concepten voor clusterautorisatie
Autorisatie van AKS-resources Maakt gebruik van standaard Azure RBAC-model voor AKS-resourcebewerkingen Maakt gebruik van standaard Azure RBAC-model voor AKS-resourcebewerkingen Kubeconfig-toegang beheren
Clusteridentiteit Maakt gebruik van een beheerd identiteitsmodel met standaardinstellingen voor productiebasislijnen Maakt gebruik van een beheerd identiteitsmodel met door operator geselecteerde installatie Beheerde identiteiten in AKS
Workload-identiteit Workloadidentiteit en OIDC-verlener zijn vooraf geconfigureerd Optioneel en geconfigureerd per operator Overzicht van workload-identiteit

De rest van dit artikel geeft een korte oriëntatie voor elk scenario.

Eén. Kubernetes-verificatie op het besturingsvlak

Met Kubernetes-besturingsvlakverificatie wordt de identiteit van een gebruiker of service-principal vastgesteld die de Kubernetes-API-server aanroept. AKS ondersteunt:

  • Microsoft Entra ID (aanbevolen):gebruik Entra ID identiteiten en groepen om u aan te melden bij het cluster. Microsoft Entra-integratie voorziet en roteert de integratie namens u. Zie Microsoft Entra-integratie gebruiken om dit in te schakelen.
  • Lokale accounts: een ingebouwd clusterbeheerderscertificaat dat Entra ID omzeilt. We raden u aan lokale accounts uit te schakelen in de productieomgeving. Bekijk Lokale accounts beheren.
  • Externe id-providers: gebruik een andere id-provider die compatibel is met OIDC dan Microsoft Entra ID. Zie Verificatie van externe id-provider.

Voor de meeste productieworkloads begint u met automatische AKS- en Microsoft Entra-integratie.

Zie concepten voor clusterverificatie voor gedetailleerde informatie over hoe AKS Kubernetes API-aanvragen verifieert.

B. Autorisatie van kubernetes-besturingsvlak

Nadat een aanroeper is geverifieerd bij de Kubernetes-API, autoriseert AKS de aanvraag met behulp van een (of beide) van twee modellen:

  • Kubernetes RBAC: het systeemeigen Kubernetes Role- ClusterRoleen RoleBinding model dat wordt geëvalueerd door de API-server. Machtigingen bevinden zich in het cluster als Kubernetes-objecten.
  • Microsoft Entra ID autorisatie: een AKS-autorisatiewebhook delegeert autorisatiebeslissingen voor Microsoft Entra ID met behulp van Azure roltoewijzingen. Azure RBAC-roltoewijzingen met dataActions worden ondersteund voor alle standaard Kubernetes-API-resources en roltoewijzingen met Azure ABAC-voorwaarden worden ondersteund voor aangepaste resources. Beheer machtigingen centraal in Microsoft Entra ID om veel clusters aan te sturen via één roltoewijzing op het niveau van een abonnement, beheergroep of resourcegroep.

In AKS Automatic wordt Azure RBAC voor Kubernetes-autorisatie vooraf geconfigureerd als onderdeel van het standaardpostuur dat gereed is voor productie.

Zie Concepten voor clusterautorisatie voor een vergelijking en richtlijnen voor het gebruik van elk model.

C. AKS-resourceautorisatie (Azure Resource Manager)

Naast het autoriseren van aanroepen naar de Kubernetes-API, moet u ook bewerkingen op Azure-niveau autoriseren voor de AKS-resource zelf. Het meest voorkomende voorbeeld is bepalen wie een cluster kubeconfigkan ophalen. Dit is een zelfstandige Azure Resource Manager-bewerking die u gedetailleerd kunt beheren met Azure RBAC. Deze bewerking maakt gebruik van standaard Azure RBAC voor de Microsoft.ContainerService resourceprovider, is gescheiden van kubernetes-API-autorisatie en past dezelfde manier toe op AKS Automatic en AKS Standard. Zie De toegang tot het clusterconfiguratiebestand en de ingebouwde rollen in Azure ingebouwde rollen beperken voor meer informatie.

D. Clusteridentiteit (cluster → Azure)

AKS-clusters gebruiken door Azure beheerde identiteiten om namens u op Azure-resources te reageren, bijvoorbeeld om load balancers te maken, schijven te koppelen of installatiekopieën op te halen uit Azure Container Registry. De belangrijkste identiteiten zijn:

  • Identiteit van besturingsvlak: wordt gebruikt door het clusterbesturingsvlak om Azure resources voor het cluster te beheren.
  • Kubelet-identiteit: wordt door de kubelet op elk knooppunt gebruikt om te verifiëren bij services zoals Azure Container Registry.
  • Identiteit van invoegtoepassingen/extensies: sommige AKS-invoegtoepassingen en -extensies gebruiken hun eigen beheerde identiteiten.

AKS Automatic houdt hetzelfde identiteitsmodel bij en vermindert de wrijving van de installatie door vooraf geconfigureerde productiestandaarden.

Zie Beheerde identiteiten in AKS voor meer informatie over elk identiteitstype en het gebruik van door het systeem toegewezen versus door de gebruiker toegewezen identiteiten.

E. Workloadidentiteit (pod → Azure)

Met workload-identiteit kunnen pods die worden uitgevoerd in uw AKS-cluster zich authenticeren bij door Microsoft Entra beveiligde Azure-services (zoals Key Vault, Storage of Cosmos DB) zonder geheimen in het cluster op te slaan. AKS maakt gebruik van Microsoft Entra Workload-id, die een Kubernetes-serviceaccounttoken projecteert dat is gefedereerd aan een Microsoft Entra-toepassing of een door de gebruiker toegewezen beheerde identiteit.

AKS Automatic bevat workloadidentiteit en OIDC-verlener als vooraf geconfigureerde standaardwaarden. In AKS Standard zijn deze mogelijkheden optioneel en geconfigureerd door de operator.

Gebruik niet de afgeschafte door Microsoft Entra beheerde identiteit voor nieuwe workloads.

Beslissingshandleiding

Goal Gebruik deze documenten
Begin met een productierijpe identiteitsbaseline voor de meeste workloads Inleiding tot AKS Automatic
Gebruikers aanmelden bij het cluster met Microsoft Entra-id Microsoft Entra-integratie inschakelen
Bepalen wie wat kan doen in de Kubernetes-API in veel clusters Microsoft Entra ID-autorisatie gebruiken voor de Kubernetes-API
Toegang tot specifieke aangepaste resourcetypen beperken ABAC-voorwaarden in Entra ID-autorisatie
Machtigingen toewijzen per cluster, per naamruimte als Kubernetes-objecten Kubernetes RBAC gebruiken met Entra-integratie
Laat het cluster ophalen uit ACR of schijven koppelen Beheerde identiteiten in AKS
Laat pods Key Vault of Storage bereiken zonder geheimen Overzicht van de Microsoft Entra Workload-id
Beperken wie het cluster kan downloaden kubeconfig Toegang tot clusterconfiguratiebestand beperken
Een cluster maken dat gereed is voor productie met standaardidentiteitspostuur Een automatisch AKS-cluster maken

AKS-servicemachtigingen referentie

Voor de Azure machtigingen die AKS gebruikt (de identiteit die het cluster maakt, de clusteridentiteit tijdens runtime, aanvullende machtigingen voor clusteridentiteit en toegang tot AKS-knooppunten), raadpleegt u de naslaginformatie over AKS-servicemachtigingen.

Verwante inhoud

Voor meer informatie over de kernconcepten van Kubernetes en AKS, zie de volgende artikelen:

  • Last updated on