Delen via

Een beheerde identiteit gebruiken in Azure Kubernetes Service (AKS)

  • Artikel

AKS-clusters (Azure Kubernetes Service) vereisen een Microsoft Entra-identiteit voor toegang tot Azure-resources, zoals load balancers en beheerde schijven. Beheerde identiteiten voor Azure-resources zijn de aanbevolen manier om toegang van een AKS-cluster tot andere Azure-services te autoriseren.

U kunt een beheerde identiteit gebruiken om toegang vanuit een AKS-cluster te autoriseren naar elke service die Microsoft Entra-autorisatie ondersteunt, zonder dat u referenties hoeft te beheren of ze in uw code hoeft op te nemen. U wijst een op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) toe aan de beheerde identiteit om deze machtigingen te verlenen aan een bepaalde resource in Azure. U kunt bijvoorbeeld machtigingen verlenen aan een beheerde identiteit voor toegang tot geheimen in een Azure-sleutelkluis voor gebruik door het cluster. Zie Wat is op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)? voor meer informatie over Azure RBAC.

In dit artikel wordt beschreven hoe u de volgende typen beheerde identiteiten inschakelt op een nieuw of bestaand AKS-cluster:

  • Door het systeem toegewezen beheerde identiteit. Een door het systeem toegewezen beheerde identiteit is gekoppeld aan één Azure-resource, zoals een AKS-cluster. Deze bestaat alleen voor de levenscyclus van het cluster.
  • Door de gebruiker toegewezen beheerde identiteit. Een door de gebruiker toegewezen beheerde identiteit is een zelfstandige Azure-resource die een AKS-cluster kan gebruiken om toegang tot andere Azure-services te autoriseren. Het blijft los van het AKS-cluster behouden en kan worden gebruikt door meerdere Azure-resources.
  • 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. Als u geen door de gebruiker toegewezen beheerde identiteit voor kubelet opgeeft, maakt AKS een door het systeem toegewezen kubelet-identiteit in de knooppuntresourcegroep.

Zie Beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten.

Overzicht

Een AKS-cluster maakt gebruik van een beheerde identiteit om tokens aan te vragen bij Microsoft Entra. Deze tokens worden gebruikt om toegang te verlenen tot andere resources die worden uitgevoerd in Azure. U kunt een Azure RBAC-rol toewijzen aan een beheerde identiteit om uw clustermachtigingen toegang te verlenen tot specifieke resources. Als uw cluster bijvoorbeeld toegang nodig heeft tot geheimen in een Azure-sleutelkluis, kunt u de beheerde identiteit van het cluster toewijzen aan een Azure RBAC-rol die deze machtigingen verleent.

Een beheerde identiteit kan worden toegewezen aan het systeem of aan de gebruiker. Deze twee typen beheerde identiteiten zijn vergelijkbaar omdat u beide typen kunt gebruiken om toegang tot Azure-resources vanuit uw AKS-cluster te autoriseren. Het belangrijkste verschil is dat een door het systeem toegewezen beheerde identiteit is gekoppeld aan één Azure-resource, zoals een AKS-cluster, terwijl een door de gebruiker toegewezen beheerde identiteit zelf een zelfstandige Azure-resource is. Zie Beheerde identiteitstypen in Beheerde identiteiten voor Azure-resources voor meer informatie over de verschillen tussen typen beheerde identiteiten.

Beide typen beheerde identiteiten worden beheerd door het Azure-platform, zodat u toegang vanuit uw toepassingen kunt autoriseren zonder dat u geheimen hoeft in te richten of te roteren. Azure beheert de referenties van de identiteit voor u.

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.

Het is ook mogelijk om een cluster te maken met een toepassingsservice-principal in plaats van een beheerde identiteit. Beheerde identiteiten worden aanbevolen voor service-principals voor beveiliging en gebruiksgemak. Zie Een service-principal gebruiken met Azure Kubernetes Service (AKS) voor meer informatie over het maken van een cluster met een service-principal.

U kunt een bestaand cluster bijwerken om een beheerde identiteit te gebruiken vanuit een toepassingsservice-principal. U kunt ook een bestaand cluster bijwerken naar een ander type beheerde identiteit. Als uw cluster al gebruikmaakt van een beheerde identiteit en de identiteit is gewijzigd, bijvoorbeeld als u het clusteridentiteitstype hebt bijgewerkt 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 verloopt. Nadat het token is vernieuwd, schakelen ze over naar de nieuwe identiteit. Dit proces kan enkele uren duren.

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

Voordat u begint

Voordat u de voorbeelden in dit artikel uitvoert, stelt u uw abonnement in als het huidige actieve abonnement door de opdracht az account set aan te roepen en uw abonnements-id door te geven.

az account set --subscription <subscription-id>

Maak ook een Azure-resourcegroep als u er nog geen hebt door de opdracht aan te az group create roepen.

az group create \
    --name myResourceGroup \
    --location westus2

Een door het systeem toegewezen beheerde identiteit inschakelen

Een door het systeem toegewezen beheerde identiteit is een identiteit die is gekoppeld aan een AKS-cluster of een andere Azure-resource. De door het systeem toegewezen beheerde identiteit is gekoppeld aan de levenscyclus van het cluster. Wanneer het cluster wordt verwijderd, wordt ook de door het systeem toegewezen beheerde identiteit verwijderd.

Het AKS-cluster kan de door het systeem toegewezen beheerde identiteit gebruiken om toegang te verlenen tot andere resources die worden uitgevoerd in Azure. U kunt een Azure RBAC-rol toewijzen aan de door het systeem toegewezen beheerde identiteit om de clustermachtigingen toegang te verlenen tot specifieke resources. Als uw cluster bijvoorbeeld toegang nodig heeft tot geheimen in een Azure-sleutelkluis, kunt u de door het systeem toegewezen beheerde identiteit toewijzen aan een Azure RBAC-rol die deze machtigingen verleent.

Een door het systeem toegewezen beheerde identiteit inschakelen op een nieuw AKS-cluster

Als u een door het systeem toegewezen beheerde identiteit wilt inschakelen op een nieuw cluster, roept u de az aks create. Een door het systeem toegewezen beheerde identiteit is standaard ingeschakeld op het nieuwe cluster.

Maak een AKS-cluster met behulp van de az aks create opdracht.

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --generate-ssh-keys

Als u wilt controleren of een door het systeem toegewezen beheerde identiteit is ingeschakeld voor het cluster nadat het is gemaakt, raadpleegt u Bepalen welk type beheerde identiteit een cluster gebruikt.

Een bestaand AKS-cluster bijwerken om een door het systeem toegewezen beheerde identiteit te gebruiken

Als u een bestaand AKS-cluster wilt bijwerken dat gebruikmaakt van een service-principal om in plaats daarvan een door het systeem toegewezen beheerde identiteit te gebruiken, voert u de az aks update opdracht uit met de --enable-managed-identity parameter.

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity

Nadat u het cluster hebt bijgewerkt voor het gebruik van een door het systeem toegewezen beheerde identiteit in plaats van een service-principal, gebruiken de besturingsvlak en pods de door het systeem toegewezen beheerde identiteit voor autorisatie bij het openen van andere services in Azure. Kubelet blijft een service-principal gebruiken totdat u ook uw agentpool bijwerken. U kunt de az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only opdracht op uw knooppunten gebruiken om bij te werken naar een beheerde identiteit. Een upgrade van een knooppuntgroep veroorzaakt downtime voor uw AKS-cluster, omdat de knooppunten in de knooppuntgroepen zijn ingesnoerd, leeggestroomd en opnieuw worden gemaakt.

Notitie

Houd rekening met de volgende informatie bij het bijwerken van uw cluster:

  • Een update werkt alleen als er een VHD-update wordt gebruikt. Als u de nieuwste VHD uitvoert, moet u wachten tot de volgende VHD beschikbaar is om de update uit te voeren.

  • De Azure CLI zorgt ervoor dat de machtiging van uw invoegtoepassing correct is ingesteld na de migratie. Als u de Azure CLI niet gebruikt om de migratiebewerking uit te voeren, moet u de machtiging van de invoegtoepassingsidentiteit zelf afhandelen. Zie Azure-rollen toewijzen met behulp van ARM-sjablonen voor een voorbeeld van een Azure Resource Manager-sjabloon (ARM).

  • Als uw cluster gebruikmaakt --attach-acr van het ophalen van installatiekopieën uit Azure Container Registry (ACR), moet u de az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> opdracht uitvoeren nadat u het cluster hebt bijgewerkt, zodat de zojuist gemaakte kubelet die wordt gebruikt voor beheerde identiteit, de machtiging krijgt om uit ACR te halen. Anders kunt u na de update niet meer ophalen uit ACR.

Een roltoewijzing toevoegen voor een door het systeem toegewezen beheerde identiteit

U kunt een Azure RBAC-rol toewijzen aan de door het systeem toegewezen 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 voor meer informatie over het toewijzen van Azure RBAC-rollen.

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 Azure RBAC voor meer informatie over het bereik van Azure RBAC.

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 u uw eigen VNet gebruikt, gekoppelde Azure-schijven, statisch IP-adres, routetabel of door de gebruiker toegewezen kubelet-identiteit die zich buiten de resourcegroep van het werkknooppunt bevindt, raden we u aan een door de gebruiker toegewezen beheerde identiteit voor het besturingsvlak te gebruiken. Wanneer het besturingsvlak een door het systeem toegewezen beheerde identiteit gebruikt, wordt de identiteit gemaakt op hetzelfde moment als het cluster, zodat de roltoewijzing pas kan worden uitgevoerd als het cluster is gemaakt.

De principal-id van de door het systeem toegewezen beheerde identiteit ophalen

Als u een Azure RBAC-rol wilt toewijzen aan de door het systeem toegewezen beheerde identiteit van een cluster, hebt u eerst de principal-id voor de beheerde identiteit nodig. Haal de principal-id op voor de door het cluster toegewezen beheerde identiteit door de az aks show opdracht aan te roepen.

# Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.principalId \
    --output tsv)

Een Azure RBAC-rol toewijzen aan de door het systeem toegewezen beheerde identiteit

Als u een door het systeem toegewezen beheerde identiteit machtigingen wilt verlenen aan een resource in Azure, roept u de az role assignment create opdracht aan om een Azure RBAC-rol toe te wijzen aan de beheerde identiteit.

Voor een VNet, gekoppelde Azure-schijf, statisch IP-adres of routetabel buiten de standaardresourcegroep voor werkknooppunten, moet u de Network Contributor rol toewijzen aan de aangepaste resourcegroep.

Wijs bijvoorbeeld de Network Contributor rol toe aan de aangepaste resourcegroep met behulp van de az role assignment create opdracht. Geef voor de --scope parameter de resource-id op voor de resourcegroep voor het cluster.

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Network Contributor" \
    --scope "<resource-group-id>"

Notitie

Het kan maximaal 60 minuten duren voordat de machtigingen die zijn verleend aan de beheerde identiteit van uw cluster, zijn doorgegeven.

Een door de gebruiker toegewezen beheerde identiteit inschakelen

Een door de gebruiker toegewezen beheerde identiteit is een zelfstandige Azure-resource. Wanneer u een cluster maakt met een door de gebruiker toegewezen beheerde identiteit voor het besturingsvlak, moet de door de gebruiker toegewezen beheerde identiteitsresource bestaan voordat het cluster wordt gemaakt. Deze functie maakt scenario's mogelijk, zoals het maken van het cluster met een aangepast VNet of met een uitgaand type door de gebruiker gedefinieerde routering (UDR).

Een door de gebruiker toegewezen beheerde identiteit maken

Als u nog geen door de gebruiker toegewezen beheerde identiteitsresource hebt, maakt u er een met behulp van de az identity create opdracht.

az identity create \
    --name myIdentity \
    --resource-group myResourceGroup

De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

De principal-id van de door de gebruiker toegewezen beheerde identiteit ophalen

Als u de principal-id van de door de gebruiker toegewezen beheerde identiteit wilt ophalen, roept u az identity show en query op de principalId eigenschap aan:

CLIENT_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query principalId \
    --output tsv)

De resource-id van de door de gebruiker toegewezen beheerde identiteit ophalen

Als u een cluster wilt maken met een door de gebruiker toegewezen beheerde identiteit, hebt u de resource-id voor de nieuwe beheerde identiteit nodig. Als u de resource-id van de door de gebruiker toegewezen beheerde identiteit wilt ophalen, roept u az aks show en query op de id eigenschap aan:

RESOURCE_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query id \
    --output tsv)

Een Azure RBAC-rol toewijzen aan de door de gebruiker toegewezen beheerde identiteit

Voordat u het cluster maakt, voegt u een roltoewijzing toe voor de beheerde identiteit door de az role assignment create opdracht aan te roepen.

In het volgende voorbeeld wordt de rol Key Vault Secrets User toegewezen aan de door de gebruiker toegewezen beheerde identiteit toegewezen om deze machtigingen te verlenen voor toegang tot geheimen in een sleutelkluis. De roltoewijzing is gericht op de sleutelkluisresource:

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Key Vault Secrets User" \
    --scope "<keyvault-resource-id>"

Notitie

Het kan tot 60 minuten duren voordat de machtigingen die zijn verleend aan de beheerde identiteit van uw cluster, zijn doorgegeven.

Een cluster maken met de door de gebruiker toegewezen beheerde identiteit

Als u een AKS-cluster wilt maken met de door de gebruiker toegewezen beheerde identiteit, roept u de az aks create opdracht aan. Neem de --assign-identity parameter op en geef de resource-id door voor de door de gebruiker toegewezen beheerde identiteit:

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity $RESOURCE_ID \
    --generate-ssh-keys

Notitie

De regio's USDOD Central, USDOD East en USGov Iowa in de Azure US Government-cloud bieden geen ondersteuning voor het maken van een cluster met een door de gebruiker toegewezen beheerde identiteit.

Een bestaand cluster bijwerken om een door de gebruiker toegewezen beheerde identiteit te gebruiken

Als u een bestaand cluster wilt bijwerken om een door de gebruiker toegewezen beheerde identiteit te gebruiken, roept u de az aks update opdracht aan. Neem de --assign-identity parameter op en geef de resource-id door voor de door de gebruiker toegewezen beheerde identiteit:

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity $RESOURCE_ID

De uitvoer voor een geslaagde clusterupdate voor het gebruik van een door de gebruiker toegewezen beheerde identiteit moet lijken op de volgende voorbeelduitvoer:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },

Notitie

Het migreren van een beheerde identiteit voor het besturingsvlak van het systeem dat is toegewezen aan door de gebruiker toegewezen, leidt niet tot downtime voor besturingsvlak- en agentpools. Onderdelen van het besturingsvlak blijven gedurende maximaal enkele uren de oude door het systeem toegewezen identiteit behouden totdat het volgende token wordt vernieuwd.

Bepalen welk type beheerde identiteit een cluster gebruikt

Als u wilt bepalen welk type beheerde identiteit uw bestaande AKS-cluster gebruikt, roept u de opdracht az aks show aan en voert u een query uit voor de typeeigenschap van de identiteit.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv

Als het cluster een beheerde identiteit gebruikt, wordt de waarde van de typeeigenschap SystemAssigned of UserAssigned.

Als het cluster een service-principal gebruikt, is de waarde van de typeeigenschap null. Overweeg om uw cluster te upgraden om een beheerde identiteit te gebruiken.

Een vooraf gemaakte beheerde kubelet-identiteit gebruiken

Een vooraf gemaakte kubelet-identiteit is een door de gebruiker toegewezen beheerde identiteit die bestaat voordat het cluster wordt gemaakt. Deze functie maakt scenario's mogelijk, zoals verbinding met Azure Container Registry (ACR) tijdens het maken van het cluster.

Notitie

AKS maakt een door de gebruiker toegewezen kubelet-identiteit in de knooppuntresourcegroep als u uw eigen door kubelet beheerde identiteit niet opgeeft.

Voor een door de gebruiker toegewezen kubelet-identiteit buiten de resourcegroep van het standaardwerkknooppunt moet u de rol Managed Identity Operator toewijzen aan de kubelet-identiteit voor beheerde identiteit op het besturingsvlak.

Beheerde kubelet-identiteit

Als u geen beheerde kubelet-identiteit hebt, maakt u er een met behulp van de az identity create opdracht.

az identity create \
    --name myKubeletIdentity \
    --resource-group myResourceGroup

De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer:

{
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
  "location": "westus2",
  "name": "myKubeletIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Een RBAC-rol toewijzen aan de beheerde kubelet-identiteit

Wijs de ACRPull rol toe aan de kubelet-identiteit met behulp van de az role assignment create opdracht. Geef de principal-id van de kubelet-identiteit op voor de variabele $KUBELET_CLIENT_ID en geef de ACR-register-id op voor de variabele $ACR_REGISTRY_ID.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "acrpull" \
    --scope "$ACR_REGISTRY_ID"

Een cluster maken om de kubelet-identiteit te gebruiken

U kunt nu uw AKS-cluster maken met uw bestaande identiteiten. Zorg ervoor dat u de resource-id van de beheerde identiteit voor het besturingsvlak opgeeft door het assign-identity argument en de beheerde kubelet-identiteit op te geven met behulp van het assign-kubelet-identity argument.

Maak een AKS-cluster met uw bestaande identiteiten met behulp van de az aks create opdracht.

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Een geslaagd AKS-cluster maken met behulp van een beheerde kubelet-identiteit moet resulteren in uitvoer die vergelijkbaar is met de volgende:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Een bestaand cluster bijwerken om de kubelet-identiteit te gebruiken

Als u een bestaand cluster wilt bijwerken om de beheerde kubelet-identiteit te gebruiken, moet u eerst de huidige beheerde identiteit voor uw AKS-cluster ophalen.

Waarschuwing

Als u de beheerde kubelet-identiteit bijwerkt, worden de knooppuntgroepen van uw AKS-cluster bijgewerkt, waardoor downtime voor het cluster wordt veroorzaakt, omdat de knooppunten in de knooppuntgroepen cordoned/leeg zijn en opnieuw worden hersteld.

  1. Controleer of uw AKS-cluster de door de gebruiker toegewezen beheerde identiteit gebruikt met behulp van de az aks show opdracht.

    az aks show \
    --resource-group <RGName> \
    --name <ClusterName> \
    --query "servicePrincipalProfile"

    Als uw cluster een beheerde identiteit gebruikt, wordt de uitvoer weergegeven clientId met een waarde van msi. Een cluster met behulp van een service-principal toont een object-id. Voorbeeld:

    # The cluster is using a managed identity.
{
  "clientId": "msi"
}

  2. Nadat u hebt bevestigd dat uw cluster een beheerde identiteit gebruikt, zoekt u de resource-id van de beheerde identiteit met behulp van de az aks show opdracht.

    az aks show --resource-group <RGName> \
    --name <ClusterName> \
    --query "identity"

    Voor een door de gebruiker toegewezen beheerde identiteit moet uw uitvoer er ongeveer uitzien als in de volgende voorbeelduitvoer:

    {
  "principalId": null,
  "tenantId": null,
  "type": "UserAssigned",
  "userAssignedIdentities": <identity-resource-id>
      "clientId": "<client-id>",
      "principalId": "<principal-id>"
},

  3. Werk uw cluster bij met uw bestaande identiteiten met behulp van de az aks update opdracht. Geef de resource-id op van de door de gebruiker toegewezen beheerde identiteit voor het besturingsvlak voor het assign-identity argument. Geef de resource-id op van de beheerde kubelet-identiteit voor het assign-kubelet-identity argument.

    az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id>

De uitvoer voor een geslaagde clusterupdate met uw eigen beheerde kubelet-identiteit moet er ongeveer uitzien als in de volgende voorbeelduitvoer:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "<client-id>",
      "objectId": "<object-id>",
      "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
    }
  },

Notitie

Als uw cluster gebruikmaakt --attach-acr van het ophalen van installatiekopieën uit Azure Container Registry, voert u de az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> opdracht uit nadat u het cluster hebt bijgewerkt, zodat de zojuist gemaakte kubelet die wordt gebruikt voor beheerde identiteit, de machtiging krijgt om uit ACR te halen. Anders kunt u na de upgrade niet meer ophalen uit ACR.

De eigenschappen van de kubelet-identiteit ophalen

Als u de eigenschappen van de kubelet-identiteit wilt ophalen, roept u az aks show en query's op de identityProfile.kubeletidentity eigenschap aan.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query "identityProfile.kubeletidentity"

Vooraf gemaakte kubelet-identiteitsbeperkingen

Let op de volgende beperkingen voor de vooraf gemaakte kubelet-identiteit:

  • Een vooraf gemaakte kubelet-identiteit moet een door de gebruiker toegewezen beheerde identiteit zijn.
  • De regio's China - oost en China - noord in Microsoft Azure beheerd door 21Vianet worden niet ondersteund.

Samenvatting van beheerde identiteiten die worden gebruikt door AKS

AKS maakt gebruik van verschillende beheerde identiteiten voor ingebouwde services en invoegtoepassingen.

Identiteit Naam Gebruiksscenario Standaardmachtigingen Bring Your Own Identity
Besturingsvlak 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. Rol Inzender voor knooppuntresourcegroep Ondersteund
Kubelet AKS-clusternaam-agentpool Verificatie met Azure Container Registry (ACR). N.v.v1.15 (voor kubernetes v1.15+) Ondersteund
Invoegtoepassing AzureNPM Er is geen identiteit vereist. N.v.t. Nee
Invoegtoepassing AzureCNI-netwerkbewaking Er is geen identiteit vereist. N.v.t. Nee
Invoegtoepassing azure-policy (gatekeeper) Er is geen identiteit vereist. N.v.t. Nee
Invoegtoepassing azure-policy Er is geen identiteit vereist. N.v.t. Nee
Invoegtoepassing Calico Er is geen identiteit vereist. N.v.t. Nee
Invoegtoepassing toepassingsroutering Beheert Azure DNS- en Azure Key Vault-certificaten Key Vault Secrets User role for Key Vault, DNZ Zone Contributor role for DNS zones, Privé-DNS Zone Contributor role for private DNS zones Nee
Invoegtoepassing HTTPApplicationRouting Beheert de vereiste netwerkbronnen. Lezerrol voor knooppuntresourcegroep, rol inzender voor DNS-zone Nee
Invoegtoepassing Toepassingsgateway voor inkomend verkeer Beheert de vereiste netwerkbronnen. Rol Inzender voor knooppuntresourcegroep Nee
Invoegtoepassing omsagent Wordt gebruikt om metrische AKS-gegevens naar Azure Monitor te verzenden. De rol Van uitgever van metrische gegevens bewaken Nee
Invoegtoepassing Virtueel knooppunt (ACIConnector) Beheert vereiste netwerkbronnen voor Azure Container Instances (ACI). Rol Inzender voor knooppuntresourcegroep Nee
Invoegtoepassing Kostenanalyse Wordt gebruikt om kostentoewijzingsgegevens te verzamelen
Workload-identiteit Workload-id van Microsoft Entra Hiermee kunnen toepassingen veilig toegang krijgen tot cloudresources met de workload-id van Microsoft Entra. N.v.t. Nee

Belangrijk

De open source door Microsoft Entra beheerde identiteit (preview) in Azure Kubernetes Service is afgeschaft op 24-10-2022 en het project dat in september 2023 is gearchiveerd. Zie de afschaffingsmelding voor meer informatie. De door AKS beheerde invoegtoepassing wordt in september 2024 afgeschaft.

We raden u aan Microsoft Entra Workload-ID te bekijken. Entra Workload-ID-verificatie vervangt de afgeschafte functie voor door pod beheerde identiteiten (preview). Entra Workload-ID is de aanbevolen methode om een toepassing die op een pod wordt uitgevoerd, in staat te stellen zichzelf te verifiëren bij andere Azure-services die deze ondersteunen.

Beperkingen

  • Het verplaatsen of migreren van een cluster met beheerde identiteit naar een andere tenant wordt niet ondersteund.

  • Als voor het cluster een door Microsoft Entra beheerde identiteit (aad-pod-identity) is ingeschakeld, wijzigen NMI-pods (Node Managed Identity) de iptables van de knooppunten om aanroepen te onderscheppen naar het EINDPUNT van Azure Instance Metadata (IMDS). Deze configuratie betekent dat elke aanvraag die is ingediend bij het IMDS-eindpunt wordt onderschept door NMI, zelfs als een bepaalde pod niet wordt gebruikt aad-pod-identity.

    De aangepaste resourcedefinitie van AzurePodIdentityException (CRD) kan worden geconfigureerd om op te geven dat aanvragen voor het IMDS-eindpunt dat afkomstig is van een pod die overeenkomt met labels die zijn gedefinieerd in de CRD, moeten worden geproxied zonder dat er verwerking in NMI wordt uitgevoerd. Sluit de systeempods uit met het kubernetes.azure.com/managedby: aks label in kube-system-naamruimte aad-pod-identity door de CRD van AzurePodIdentityException te configureren. Zie Microsoft Entra door pods beheerde identiteiten gebruiken in Azure Kubernetes Service voor meer informatie.

    Als u een uitzondering wilt configureren, installeert u de YAML van de microfoon-uitzondering.

  • AKS biedt geen ondersteuning voor het gebruik van een door het systeem toegewezen beheerde identiteit wanneer u een aangepaste privé-DNS-zone gebruikt.

Volgende stappen