Overzicht van beheerde identiteiten in Azure Kubernetes Service (AKS)

Dit artikel bevat een overzicht van door het systeem toegewezen en door de gebruiker toegewezen beheerde identiteiten in AKS, waaronder hoe ze werken, roltoewijzingen en AKS-specifieke functies voor beheerde identiteiten.

Zie de documentatie over beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten in Azure.

Opmerking

Beheerde identiteiten hebben betrekking op het cluster-naar-Azure-identiteitsscenario in AKS: hoe het AKS-cluster in Azure werkt om resources namens u te beheren. Zie voor de andere identiteitsscenario's (verificatie en autorisatie op controlevlak en pod-naar-Azure-workloadidentiteit) Toegangs- en identiteitsopties voor AKS.

Opmerking

De door het systeem toegewezen en door de gebruiker toegewezen identiteitstypen verschillen van een workloadidentiteit, die is bedoeld voor gebruik door een toepassing die op een pod wordt uitgevoerd.

Autorisatiestroom voor beheerde identiteiten in AKS

AKS-clusters maken gebruik van door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteiten om tokens aan te vragen bij Microsoft Entra. Deze tokens helpen bij het autoriseren van toegang tot andere resources die worden uitgevoerd in Azure. U wijst een azure RBAC-rol (op rollen gebaseerd toegangsbeheer) toe aan de beheerde identiteit om deze machtigingen te verlenen aan een bepaalde Azure-resource. U kunt bijvoorbeeld machtigingen verlenen aan een beheerde identiteit voor toegang tot geheimen in een Azure-sleutelkluis voor gebruik door het cluster.

Gedrag van beheerde identiteit in AKS

Wanneer u een AKS-cluster implementeert, wordt standaard een door het systeem toegewezen beheerde identiteit voor u gemaakt. U kunt het cluster ook maken met een door de gebruiker toegewezen beheerde identiteit of een bestaand cluster bijwerken naar een ander type beheerde identiteit.

Als uw cluster al gebruikmaakt van een beheerde identiteit en u het identiteitstype wijzigt (bijvoorbeeld van door het systeem toegewezen aan door de gebruiker toegewezen), is er een vertraging terwijl onderdelen van het besturingsvlak overschakelen naar de nieuwe identiteit. Onderdelen van het besturingsvlak blijven de oude identiteit gebruiken totdat het token van de oude identiteit verloopt. Nadat het token is vernieuwd, schakelen ze over naar de nieuwe identiteit. Dit proces kan enkele uren duren.

Opmerking

U kunt ook een cluster maken met een toepassingsservice-principal in plaats van een beheerde identiteit. Gebruik echter een beheerde identiteit via een toepassingsservice-principal voor beveiliging en gebruiksgemak. Als u een bestaand cluster hebt dat gebruikmaakt van een toepassingsservice-principal, kunt u het bijwerken om een beheerde identiteit te gebruiken.

AKS-identiteits- en referentiebeheer

Het Azure-platform beheert zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteiten en hun referenties, zodat u toegang vanuit uw toepassingen kunt autoriseren zonder dat u geheimen hoeft in te richten of te roteren.

Door het systeem toegewezen beheerde identiteit

De volgende tabel bevat een overzicht van de belangrijkste kenmerken van een door het systeem toegewezen beheerde identiteit in AKS:

Hoe deze wordt gemaakt Levenscyclusgedrag Delen van resources Veelvoorkomende gebruiksvoorbeelden in AKS
Gemaakt als onderdeel van een Azure-resource, zoals een AKS-cluster Gekoppeld aan de levenscyclus van de bovenliggende resource, zodat deze wordt verwijderd wanneer de bovenliggende resource wordt verwijderd Kan slechts aan één resource worden gekoppeld • Workloads in één Azure-resource
• Workloads waarvoor onafhankelijke identiteiten zijn vereist

Door de gebruiker toegewezen beheerde identiteit

De volgende tabel bevat een overzicht van de belangrijkste kenmerken van een door de gebruiker toegewezen beheerde identiteit in AKS:

Hoe deze wordt gemaakt Levenscyclusgedrag Delen van resources Veelvoorkomende gebruiksvoorbeelden in AKS
Gemaakt als een zelfstandige Azure-resource en moet bestaan voordat het cluster wordt gemaakt Onafhankelijk van de levenscyclus van een specifieke resource, dus moet handmatig worden verwijderd als deze niet meer nodig is Kan worden gedeeld over meerdere resources • Workloads die worden uitgevoerd op meerdere resources en die één identiteit kunnen delen
• Workloads waarvoor preautorisatie vereist is voor een beveiligde resource als onderdeel van een inrichtingsproces.
• Workloads waarbij middelen regelmatig worden gerecycled, maar consistente machtigingen nodig hebben

Vooraf gemaakte beheerde kubelet-identiteit

Een vooraf gemaakte beheerde kubelet-identiteit is een optionele door de gebruiker toegewezen identiteit die kubelet kan gebruiken voor toegang tot andere resources in Azure. Deze functie maakt scenario's mogelijk, zoals verbinding met Azure Container Registry (ACR) tijdens het maken van het cluster. Als u geen door de gebruiker toegewezen beheerde identiteit voor kubelet opgeeft, maakt AKS een door de gebruiker toegewezen kubelet-identiteit in de resourcegroep van het knooppunt. Voor een door de gebruiker toegewezen kubelet-identiteit buiten de standaardresourcegroep van het werkknooppunt wijst u de rol Managed Identity Operator toe aan de control plane-identiteit van het cluster, ongeacht of deze door het systeem of door de gebruiker is toegewezen, waarbij de roltoewijzing is beperkt tot de kubelet-identiteit.

Roltoewijzingen voor beheerde identiteiten in AKS

U kunt een Azure RBAC-rol toewijzen aan een beheerde identiteit om de clustermachtigingen voor een andere Azure-resource te verlenen. Azure RBAC ondersteunt zowel ingebouwde als aangepaste roldefinities die machtigingsniveaus opgeven. Zie Stappen voor het toewijzen van een Azure-rol als u een rol wilt toewijzen.

Wanneer u een Azure RBAC-rol toewijst aan een beheerde identiteit, moet u het bereik voor de rol definiëren. Over het algemeen is het een best practice om het bereik van een rol te beperken tot de minimale bevoegdheden die zijn vereist voor de beheerde identiteit. Zie Het bereik voor Azure RBAC begrijpen voor meer informatie over het bereik van Azure RBAC.

Roltoewijzingen voor beheerde identiteiten in het controlevlak

Wanneer u uw eigen VNet maakt en gebruikt, gekoppelde Azure-schijven, statisch IP-adres, routetabel of door de gebruiker toegewezen kubelet-identiteit waarbij de resources zich buiten de resourcegroep van het werkknooppunt bevinden, wordt de roltoewijzing automatisch toegevoegd. Als u een ARM-sjabloon of een andere methode gebruikt, gebruikt u de principal-id van de beheerde identiteit om een roltoewijzing uit te voeren.

Als u de Azure CLI niet gebruikt, maar uw eigen VNet gebruikt, gekoppelde Azure schijven, statisch IP-adres, routetabel of door de gebruiker toegewezen kubelet-identiteit waar deze resources zich buiten de resourcegroep van het werkknooppunt bevinden, raden we u aan een door de gebruiker toegewezen beheerde identiteit voor het besturingsvlak te gebruiken en handmatig de vereiste roltoewijzing uit te voeren met behulp van de principal-id van die identiteit.

Wanneer het besturingsvlak een door het systeem toegewezen beheerde identiteit gebruikt, maakt u de identiteit op hetzelfde moment als het cluster, zodat u de roltoewijzing pas kunt uitvoeren nadat het cluster is gemaakt. Nadat u het cluster hebt gemaakt, haalt u de principal-ID van de identiteit op en voegt u de vereiste roltoewijzing toe.

Samenvatting van beheerde identiteiten die worden gebruikt door AKS

AKS maakt gebruik van verschillende beheerde identiteiten voor ingebouwde services en invoegtoepassingen. De volgende tabel bevat een overzicht van de beheerde identiteiten die door AKS worden gebruikt, de bijbehorende use cases, standaardmachtigingen en of u uw eigen identiteit kunt gebruiken:

Identiteit Naam Gebruiksituatie Standaardmachtigingen Neem je eigen identiteit mee
beheerlaag Naam van AKS-cluster Wordt gebruikt door AKS-besturingsvlakonderdelen voor het beheren van clusterresources, waaronder load balancers voor inkomend verkeer en door AKS beheerde openbare IP-adressen, automatische schaalaanpassing van clusters, Azure Disk, File, Blob CSI-stuurprogramma's Bijdragerrol voor knooppuntresourcegroep Ondersteund
Kubelet AKS-clusternaam-agentpool Verificatie met Azure Container Registry (ACR) Geen; vereist een ACR Pull-rol op basis van de machtigingsmodus van het register Ondersteund
Invoegtoepassing AzureNPM Geen identiteit vereist N/A Niet ondersteund
Invoegtoepassing AzureCNI-netwerkbewaking Geen identiteit vereist N/A Niet ondersteund
Invoegtoepassing azure-beleid (gatekeeper) Geen identiteit vereist N/A Niet ondersteund
Invoegtoepassing Calico Geen identiteit vereist N/A Niet ondersteund
Invoegtoepassing toepassingsroutering (NGINX) Beheert Azure DNS- en Azure Key Vault-certificaten Key Vault-certificaatgebruiker voor Key Vault, DNS-zonebijdrager voor DNS-zones Niet ondersteund
Invoegtoepassing ingressapplicationgateway-naam van AKS-cluster Beheert vereiste netwerkbronnen voor application gateway-ingangscontroller (AGIC) Afhankelijk van de implementatietopologie Niet ondersteund
Invoegtoepassing Container Insights Verzamelt containerlogboeken en inventarisgegevens en verzendt deze naar een Log Analytics werkruimte Maakt gebruik van de beheerde identiteit van het cluster; geen Publisher rol voor bewakingsgegevens vereist Maakt gebruik van de clusteridentiteit
Invoegtoepassing Virtual-Node (ACIConnector) Beheert vereiste netwerkbronnen voor Azure Container Instances (ACI) Bijdragerrol voor knooppuntresourcegroep Niet ondersteund
Invoegtoepassing kostenanalyse-identiteit Verzamelt Azure Resource Manager id's voor kostentoewijzing Leestoegang tot de resourcegroep van het knooppunt Niet ondersteund
Workload-identiteit Door de gebruiker geconfigureerde Microsoft Entra identiteit Hiermee kunnen toepassingen veilig toegang krijgen tot cloudresources met de Workload-id van Microsoft Entra Is afhankelijk van de resources waartoe de workload toegang heeft Required

Opmerking

Voor de kubelet-identiteit is een ACR-pull-rol vereist. Gebruik voor registers in de modus voor RBAC-registermachtigingen de rol AcrPull. Gebruik de Container Registry Repository Reader rol voor registers in het RBAC-register + ABAC-opslagplaatsmachtigingen. Voeg de Container Registry Repository Catalog Lister rol alleen toe als de identiteit opslagplaatsen moet vermelden. Zie toegewezen identiteit van een AKS-knooppunt voor meer informatie.

In de rij voor toepassingsroutering wordt de op NGINX gebaseerde ervaring beschreven. Microsoft biedt tot en met november 2026 ondersteuning voor kritieke beveiligingspatches voor NGINX Ingress-resources van de invoegtoepassing voor toepassingsroutering. Migreren naar de Application Routing Gateway-API of een andere ondersteunde implementatie, in november 2026. De GATEWAY-API DNS- en TLS-integratie maakt gebruik van Microsoft Entra Workload-id in plaats van de beheerde identiteit van de invoegtoepassing. Voor gateway-API maakt u een door de gebruiker toegewezen beheerde identiteit, verleent u deze de vereiste Azure DNS en Azure Key Vault rollen en maakt u federatieve identiteitsreferenties voor de Kubernetes-serviceaccounts.

AGIC-machtigingen zijn afhankelijk van de wijze waarop u Application Gateway implementeert. Wanneer de invoegtoepassing een nieuwe Toepassingsgateway maakt, worden doorgaans automatisch de vereiste machtigingen toegewezen. Als u handmatig machtigingen moet toewijzen, kent u de invoegtoepassingsidentiteit de rol Netwerkbijdrager toe op het subnet van de Application Gateway. Voor een bestaande Application Gateway in een andere resourcegroep dan het AKS-cluster geeft u de invoegtoepassingsidentiteit de rollen Netwerkbijdrager en Lezer voor de resourcegroep van de Application Gateway. Zie AGIC inschakelen met een nieuwe Application Gateway en AGIC inschakelen met een bestaande Application Gateway voor meer informatie.

Container Insights is standaard ingesteld op beheerde identiteitsverificatie en gebruikt de beheerde identiteit van het cluster om gegevens naar Azure Monitor te verzenden. Verouderde authenticatie, waarvoor de rol Monitoring Metrics Publisher is vereist, wordt op 30 september 2026 buiten gebruik gesteld. Container Insights verzamelt logboeken en inventarisgegevens in een Log Analytics werkruimte; Azure Monitor beheerde service voor Prometheus verzamelt afzonderlijk metrische gegevens van Prometheus in een Azure Monitor werkruimte. Zie Container Insights-verificatie voor meer informatie.

AKS maakt de cost-analysis-identity met leestoegang tot de knooppuntresourcegroep en wijst deze toe aan de knooppuntgroepen van het cluster wanneer u kostenanalyse inschakelt. U kunt geen andere identiteit opgeven voor de invoegtoepassing. Zie AKS-kostenanalyse inschakelen voor meer informatie.

Microsoft Entra Workload-id is een identiteitsmodel van pod naar Azure, geen door een cluster of invoegtoepassing beheerde identiteit. U configureert de Microsoft Entra-identiteit die elke workload gebruikt, annoteert het Kubernetes-serviceaccount met de client-id van de identiteit en maakt een federatieve identiteitsreferentie aan. Zie Microsoft Entra Workload-id implementeren en configureren voor meer informatie.

Volgende stap

Schakel het gewenste beheerde identiteitstype in op een nieuw of bestaand AKS-cluster met behulp van de volgende handleidingen:

  • Last updated on