Identiteitsbindingen voor Azure Kubernetes Service (AKS) (preview)

Identiteitsbinding is een preview-functie voor Azure Kubernetes Service (AKS) die de bestaande functie voor workloadidentiteit uitbreidt om beperkingen op te schalen rond federatieve identiteitsreferenties (FIC's) voor door de gebruiker toegewezen beheerde identiteiten (UAM's). Met workload-identiteit voor AKS kan één UAMI niet meer dan 20 FICs hebben. Grote Kubernetes-platformimplementaties kunnen meer dan 20 clusters omvatten (elk cluster heeft een unieke verlener) of veel <namespace, service-account> combinaties hebben die moeten worden toegewezen aan dezelfde UAMI, waardoor het FIC-quotum wordt uitgeput.

Identiteitsbindingen hebben betrekking op deze beperking doordat meerdere AKS-clusters dezelfde UAMI kunnen delen met behulp van één FIC per UAMI. Deze aanpak verhoogt de schaalbaarheid aanzienlijk en vereenvoudigt bewerkingen voor grootschalige AKS-omgevingen waarvoor Microsoft Entra-verificatie is vereist.

Wat is een identiteitsbinding?

Een identiteitsbinding is een resourcetoewijzing tussen één UAMI en één AKS-cluster met workloads waarvoor Microsoft Entra-verificatie met die identiteit nodig is.

Stel dat u een UAMI hebt, MI-1die nodig is voor workloads die worden uitgevoerd in clusters AKS-cluster-1, AKS-cluster-2en AKS-cluster-3. U kunt drie identiteitsbindingen maken om MI-1 aan elk van deze clusters toe te wijzen:

• Identiteitsbinding IB-A toewijzen MI-1 aan AKS-cluster-1.
• Identiteitsbinding IB-B toewijzen MI-1 aan AKS-cluster-2.
• Identiteitsbinding IB-C toewijzen MI-1 aan AKS-cluster-3.

Zelfs als dezelfde UAMI nodig is voor meerdere clusters, wordt er slechts één federatieve identiteitsreferentie per UAMI gemaakt, waarbij de vorige 20 FIC-beperking wordt aangepakt. Wanneer u een identiteitsbinding maakt, maakt AKS automatisch (of hergebruikt) de enkele FIC voor die UAMI. In de volgende diagrammen ziet u de verschillen tussen het vorige workloadidentiteitsmodel en het nieuwe model voor identiteitsbindingen:

Schermopname van twee diagrammen: één toont identiteitsbindingen die een UAMI toewijzen aan meerdere AKS-clusters terwijl gebruik wordt gemaakt van een enkele FIC, en de andere toont werkbelasting-identiteitskoppelingen.

Nadat u de identiteitsbinding hebt gemaakt en de UAMI is geautoriseerd voor het cluster, moet u ClusterRole en ClusterRoleBinding objecten definiëren die de naamruimten en serviceaccounts (granulair of collectief) opgeven die de beheerde identiteit mogen gebruiken voor het verkrijgen van Microsoft Entra-token.

Identiteitsbindingen gebruiken met Azure Identity-clientbibliotheken

Volg deze stappen om identiteitsbindingen te gebruiken met uw toepassingsworkloads:

1. Zorg ervoor dat u het minimaal vereiste Azure Identity-pakket gebruikt.
2. Gebruik WorkloadIdentityCredential en meld u aan voor de functie. Deze functie wordt niet ondersteund in ManagedIdentityCredential of DefaultAzureCredential.

De volgende tabel bevat een overzicht van de minimale pakketversies en het inschakelen van identiteitsbindingen voor elke ondersteunde taal:

Veelgestelde vragen (FAQ's)

Is identiteitsconsistentie (namespace en serviceaccount consistentie) vereist voor clusters die dezelfde UAMI gebruiken?

Nee. Voor identiteitsbindingen is geen naamruimte-/serviceaccount-zelfdeheid vereist. Het is aan de clusteroperator om expliciet de naamruimten en serviceaccounts binnen elk cluster te autoriseren die de beheerde identiteit mogen gebruiken via op rollen gebaseerd toegangsbeheer (RBAC).

Kan ik meerdere identiteitsbindingen maken voor dezelfde UAMI?

Ja. De OIDC-verlener-URL die wordt onderhouden door AKS voor die UAMI, is hetzelfde voor alle identiteitsbindingen die verwijzen naar dezelfde beheerde identiteit.

Welke machtigingen zijn vereist om identiteitsbindingen te maken?

Vereiste ARM-machtigingen (Azure Resource Manager):

• Microsoft.ContainerService/managedClusters/identityBindings/*
• Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/*

Vereiste Kubernetes-machtigingen:

• Mogelijkheid om ClusterRole- en ClusterRoleBinding-objecten te maken (clusterbeheerder of gelijkwaardig).

Wat gebeurt er met de automatisch gemaakte FIC nadat alle identiteitsbindingen voor een UAMI zijn verwijderd?

Er is momenteel geen automatische garbagecollection van de FIC wanneer de laatste identiteitsbinding die verwijst naar een UAMI wordt verwijderd. Operators moeten de FIC pas handmatig opschonen nadat alle identiteitsbindingen voor die UAMI zijn verwijderd om te voorkomen dat de resterende afhankelijkheden worden onderbroken.

Welke netwerkvereisten bestaan er voor identiteitsbindingen?

Voorheen vereiste workloadidentiteit uitgaand verkeer naar login.microsoftonline.com, zodat workloads serviceaccounttokens konden uitwisselen voor Microsoft Entra-toegangstokens. Met identiteitsbindingen worden tokenaanvragen omgeleid via een clusterspecifieke identiteitsbindingsproxy die wordt beheerd door AKS. Directe uitgaande verbindingen voor login.microsoftonline.com tokenuitwisseling zijn niet vereist.

Welke beperkingen gelden er voor identiteitsbindingen?

Identiteitsbindingen worden nog niet ondersteund op clusters die zijn geconfigureerd met integratie van het virtuele netwerk van de API-server.

Verwante inhoud

• Identiteitsbindingen instellen voor Azure Kubernetes Service (AKS)