Identiteitsbindingen instellen in Azure Kubernetes Service (AKS) (preview)

Stel identiteitsbindingen in uw AKS-clusters (Azure Kubernetes Service) in om een door de gebruiker toegewezen beheerde identiteit (UAMI) toe te wijzen aan meerdere clusters terwijl u één federatieve identiteitsreferentie (FIC) gebruikt. Met deze configuratie kunt u Microsoft Entra-verificatie schalen voor workloads zonder dat FIC-limieten worden bereikt.

Vereiste voorwaarden

Bekijk concepten voor identiteitsbindingen om te begrijpen hoe identiteitsbindingen werken.
Azure CLI versie 2.73.0 of hoger. Gebruik de az version opdracht om uw versie te controleren. Zie Azure CLI installeren of bijwerken om de Azure CLI te installeren of bij te werken.
De versie aks-preview van de Azure CLI-extensie 18.0.0b26 of hoger is geïnstalleerd.
De IdentityBindingPreview featurevlag voor uw abonnement ingeschakeld.
U hebt de volgende Azure-machtigingen nodig voor het bereik van de identiteit en het cluster: Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write en Microsoft.ContainerService/managedClusters/write.
U hebt Kubernetes-clusterbeheerdersmachtigingen (of gelijkwaardige machtigingen) nodig om ClusterRole- en ClusterRoleBinding-resources te maken.

De `aks-preview` extensie installeren of bijwerken

Installeer of werk de Azure CLI-extensie aks-preview bij naar de nieuwste versie met behulp van de az extension add of az extension update opdracht:

# Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview

`IdentityBindingPreview` De functievlag inschakelen

Registreer de IdentityBindingPreview functievlag in uw Azure-abonnement met behulp van de az feature register opdracht.
```
az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview
```
Het kan tot 15 minuten duren voordat de functieregistratie is voltooid.

Wacht totdat de functie is geregistreerd met behulp van de az feature show opdracht.

az feature show --namespace Microsoft.ContainerService --name IdentityBindingPreview

Zodra de functie wordt weergegeven als Registered, vernieuwt u de registratie van de provider met behulp van de az provider register opdracht.
```
az provider register --namespace Microsoft.ContainerService
```

Beperkingen

Identiteitsbindingen worden nog niet ondersteund op clusters die zijn geconfigureerd met VNet-integratie van API-server.

Testresources aanmaken

Maak een Azure-resourcegroep met behulp van de az group create opdracht.

export RESOURCE_GROUP="ib-test"
export LOCATION="westus2"

az group create --name $RESOURCE_GROUP --location $LOCATION

Maak een AKS-cluster met workloadidentiteit en OIDC-verlener ingeschakeld met behulp van de az aks create opdracht met de --enable-workload-identity en --enable-oidc-issuer vlaggen.

export CLUSTER_NAME="ib-test-cluster"

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --location $LOCATION --no-ssh-key --enable-workload-identity --enable-oidc-issuer

Maak een door de gebruiker toegewezen beheerde identiteit (UAMI) met behulp van de az identity create opdracht.
```
export MI_NAME="ib-test-mi"
az identity create --resource-group $RESOURCE_GROUP --name $MI_NAME
```

De versie van de workload-identiteitwebhook controleren

Voor identiteitsbinding is de preview-versie van de webhook van de workload-identiteit vereist. Controleer de geïnstalleerde webhookversie met behulp van de volgende kubectl get pods opdracht:
```
kubectl -n kube-system get pods -l azure-workload-identity.io/system=true -o yaml | grep v1.6.0
```
In de uitvoer moet v1.6.0-alpha.1 in de afbeeldingstag worden weergegeven, dat bevestigt dat de juiste versie is geïnstalleerd.

Haal de UAMI-ids op

Haal de resource-, principal-, client- en tenant-id's van de UAMI op en stel deze in als omgevingsvariabelen met behulp van de volgende az identity show opdrachten:

export MI_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query id --output tsv)
export MI_PRINCIPAL_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query principalId --output tsv)
export MI_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query clientId --output tsv)
export MI_TENANT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query tenantId --output tsv)

Een identiteitsbinding maken

Wijs de UAMI met een identiteitsbinding toe aan het AKS-cluster met behulp van de az aks identity-binding create opdracht.
```
az aks identity-binding create --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib" --managed-identity-resource-id $MI_RESOURCE_ID
```
Opmerking

Wanneer u een identiteitsbinding maakt, maakt AKS automatisch een gefedereerde identiteitsreferentie (FIC) met de naam aks-identity-binding onder de UAMI. Deze referentie wordt beheerd door AKS. Wijzig of verwijder deze niet terwijl identiteitsbindingen in gebruik zijn. De FIC die is gemaakt voor identiteitsbindingen, wordt gedeeld door alle identiteitsbindingen die verwijzen naar dezelfde UAMI.

Verkrijg de OIDC-uitgever-URL voor de UAMI

Haal de OIDC-verlener-URL op die is gekoppeld aan de UAMI door de identiteitsbinding te inspecteren met behulp van de az aks identity-binding show opdracht.

az aks identity-binding show --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib"

Verkorte voorbeelduitvoer:

{
  "oidcIssuer": {
    "oidcIssuerUrl": "https://ib.oic.prod-aks.azure.com/<MI-tenant-id>/<MI-client-id>"
  }
}

Verbinding maken met het AKS-cluster

Haal de AKS-clusterreferenties op met behulp van de az aks get-credentials opdracht en sla deze op in een afzonderlijk kubeconfig-bestand:
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME -a -f "${CLUSTER_NAME}.kubeconfig"
```
Stel de KUBECONFIG omgevingsvariabele in om te verwijzen naar het nieuwe kubeconfig-bestand:
```
export KUBECONFIG="$(pwd)/${CLUSTER_NAME}.kubeconfig"
```

Naamruimten en serviceaccounts autoriseren

Configureer op rollen gebaseerd toegangsbeheer (RBAC) om specifieke onderwerpen de machtiging te verlenen om de beheerde identiteit te gebruiken via identiteitsbinding door het volgende manifest toe te passen met behulp van de volgende kubectl apply opdracht.

Opmerking

Het volgende voorbeeld verwijst expliciet naar het demo serviceaccount in de demo naamruimte. Hoewel het expliciet verwijzen naar een specifiek serviceaccount één optie is, is het ook mogelijk om te verwijzen naar een verzameling serviceaccounts onder subjects. Zie Verwijzen naar onderwerpen in de Kubernetes-documentatie voor meer informatie.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo
  namespace: demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-mi-${MI_CLIENT_ID}
rules:
  - verbs: ["use-managed-identity"]
    apiGroups: ["cid.wi.aks.azure.com"]
    resources: ["${MI_CLIENT_ID}"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: use-mi-${MI_CLIENT_ID}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-mi-${MI_CLIENT_ID}
subjects:
  - kind: ServiceAccount
    name: demo
    namespace: demo
EOF

Een sleutelkluis maken met beveiliging tegen opschonen en Azure RBAC-autorisatie

Maak een sleutelkluis met opschoningsbeveiliging en Azure RBAC-autorisatie ingeschakeld met behulp van de az keyvault create opdracht met de --enable-purge-protection en --enable-rbac-authorization vlaggen. U kunt ook een bestaande sleutelkluis gebruiken als deze is geconfigureerd voor zowel beveiliging tegen opschonen als Azure RBAC-autorisatie.
```
export KEY_VAULT_NAME="ib-test"

az keyvault create \
    --name $KEY_VAULT_NAME \
    --resource-group $RESOURCE_GROUP \
    --location $LOCATION \
    --enable-purge-protection \
    --enable-rbac-authorization
```

De resource-id en URL van de sleutelkluis ophalen

Haal de resource-id van de sleutelkluis op met behulp van de az keyvault show opdracht en stel deze in als een omgevingsvariabele:

export KEY_VAULT_RESOURCE_ID=$(az keyvault show --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query id \
    --output tsv)

Haal de sleutelkluis-URL op met behulp van de az keyvault show opdracht en stel deze in als een omgevingsvariabele:

export KEYVAULT_URL="$(az keyvault show \
    --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query properties.vaultUri \
    --output tsv)"

Toegang tot key vault configureren en geheim maken

In de volgende stappen ziet u hoe u vanuit de pod toegang verleent tot geheimen, sleutels of certificaten in Azure Key Vault. In de voorbeelden in deze sectie wordt de toegang tot geheimen in de sleutelkluis voor de workloadidentiteit geconfigureerd, maar u kunt vergelijkbare stappen uitvoeren om toegang tot sleutels of certificaten te configureren.

In het volgende voorbeeld ziet u hoe u het Azure RBAC-machtigingsmodel gebruikt om de pod toegang te verlenen tot de sleutelkluis. Zie Machtigingen verlenen aan toepassingen voor toegang tot Azure Key Vault met behulp van Azure RBAC voor meer informatie over het Azure RBAC-machtigingsmodel voor Azure Key Vault.

Haal de object-id van de aangemelde gebruiker op met behulp van de az ad signed-in-user show opdracht en stel deze in als een omgevingsvariabele:
```
export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id --output tsv)
```

Wijs uzelf de Azure RBAC Key Vault Secrets Officer-rol toe aan de sleutelkluis met behulp van de az role assignment create opdrachtregel.

az role assignment create --assignee $CALLER_OBJECT_ID \
    --role "Key Vault Secrets Officer" \
    --scope $KEY_VAULT_RESOURCE_ID

Maak een geheim in de sleutelkluis met behulp van de az keyvault secret set opdracht.

export KEY_VAULT_SECRET_NAME="my-secret"

az keyvault secret set \
    --vault-name $KEY_VAULT_NAME \
    --name $KEY_VAULT_SECRET_NAME \
    --value "Hello\!"

Wijs de rol Key Vault Secrets User toe aan de UAMI met behulp van de az role assignment create opdracht.

az role assignment create \
    --assignee-object-id $MI_PRINCIPAL_ID \
    --role "Key Vault Secrets User" \
    --scope $KEY_VAULT_RESOURCE_ID \
    --assignee-principal-type ServicePrincipal

Aantekeningen toevoegen aan serviceaccount

Aantekeningen toevoegen aan het serviceaccount met de tenant-id van de beheerde identiteit met behulp van de kubectl annotate opdracht.
```
kubectl annotate sa demo -n demo azure.workload.identity/tenant-id=$MI_TENANT_ID
```
Annoteren het serviceaccount met de client-id van de beheerde identiteit door gebruik te maken van de kubectl annotate opdracht.
```
kubectl annotate sa demo -n demo azure.workload.identity/client-id=$MI_CLIENT_ID
```

Voorbeeldtoepassing implementeren

Implementeer de voorbeeldpod die gebruikmaakt van identiteitsbinding om een toegangstoken voor de beheerde identiteit te verkrijgen voor toegang tot Azure Key Vault met behulp van de volgende kubectl apply opdracht:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: demo
  labels:
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/use-identity-binding: "true"
spec:
  serviceAccount: demo
  containers:
    - name: azure-sdk
      # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go
      image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64
      env:
        - name: KEYVAULT_URL
          value: ${KEYVAULT_URL}
        - name: SECRET_NAME
          value: ${KEY_VAULT_SECRET_NAME}
  restartPolicy: Never
EOF

Toegang tot key vault controleren vanuit voorbeeldtoepassing

Beschrijf de pod en bevestig dat de omgevingsvariabelen en tokenvolumeprojecties aanwezig zijn met behulp van de kubectl describe pod opdracht.
```
kubectl describe pod demo -n demo
```
Verwachte uitvoer moet waarden bevatten voor AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, , AZURE_AUTHORITY_HOST. AZURE_KUBERNETES_TOKEN_PROXY AZURE_KUBERNETES_SNI_NAME, en AZURE_KUBERNETES_CA_FILE.
Controleer of de pod een token kan ophalen en toegang heeft tot de resource met behulp van de kubectl logs opdracht.
```
kubectl logs demo -n demo
```
Als dit lukt, moet de uitvoer er ongeveer uitzien als in het volgende voorbeeld:
```
I1107 20:03:42.865180       1 main.go:77] "successfully got secret" secret="Hello!"
```

Identiteitsbindingen schalen over meerdere clusters

Met identiteitsbindingen kunnen meerdere AKS-clusters aan dezelfde UAMI worden toegewezen terwijl er nog steeds één FIC wordt gebruikt. Als u identiteitsbindingen in meerdere clusters wilt schalen, herhaalt u de stappen van Een identiteitsbinding maken door de toegang tot de sleutelkluis te controleren vanuit de voorbeeldtoepassing voor elk extra cluster dat u wilt toewijzen aan dezelfde UAMI (een nieuwe identiteitsbinding per cluster maken).

De hulpbronnen opschonen

Als u de resources die u in dit artikel hebt gemaakt niet meer nodig hebt, kunt u ze opschonen om toekomstige kosten te voorkomen.

Verwijder de pod met behulp van de kubectl delete pod opdracht.
```
kubectl delete pod demo -n demo
```
Verwijder de naamruimte met behulp van de kubectl delete ns opdracht.
```
kubectl delete ns demo
```
Verwijder de resourcegroep en alle gerelateerde resources met behulp van de az group delete opdracht.
```
az group delete --name $RESOURCE_GROUP --yes --no-wait
```

Concepten voor identiteitsbindingen

Feedback

Is deze pagina nuttig?

Last updated on 2026-01-28