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 Een beheerde identiteit gebruiken in Azure Kubernetes Service (AKS) als u een beheerde identiteit wilt inschakelen op een nieuw of bestaand AKS-cluster. Zie de documentatie over beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten in Azure.

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 verloopt. Nadat het token is vernieuwd, schakelen ze over naar de nieuwe identiteit. Dit proces kan enkele uren duren.

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:

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:

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 resourcegroep van het standaardwerkknooppunt moet u de rol Managed Identity Operator toewijzen aan de kubelet-identiteit voor beheerde identiteit op het besturingsvlak.

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 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 nadat het cluster is gemaakt.

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:

Volgende stap: Beheerde identiteiten in AKS inschakelen

Zie Een beheerde identiteit gebruiken in Azure Kubernetes Service (AKS) voor meer informatie over het inschakelen van beheerde identiteiten in een nieuw of bestaand AKS-cluster.