Integrera Microsoft Entra-ID med Azure Kubernetes Service (AKS) med hjälp av Azure CLI (äldre)

Azure Kubernetes Service (AKS) kan konfigureras för att använda Microsoft Entra-ID för användarautentisering. I den här konfigurationen kan du logga in på ett AKS-kluster med en Microsoft Entra-autentiseringstoken. Klusteroperatorer kan också konfigurera rollbaserad Åtkomstkontroll för Kubernetes (Kubernetes RBAC) baserat på en användares identitets- eller kataloggruppsmedlemskap.

Den här artikeln visar hur du skapar nödvändiga Microsoft Entra-komponenter, distribuerar sedan ett Microsoft Entra-ID-aktiverat kluster och skapar en grundläggande Kubernetes-roll i AKS-klustret.

Begränsningar

• Microsoft Entra-ID kan bara aktiveras i Kubernetes RBAC-aktiverade kluster.
• Äldre Microsoft Entra-integrering kan bara aktiveras när klustret skapas.

Innan du börjar

Du behöver Azure CLI version 2.0.61 eller senare installerad och konfigurerad. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI.

Gå till för att https://shell.azure.com öppna Cloud Shell i webbläsaren.

För konsekvens och för att köra kommandona i den här artikeln skapar du en variabel för önskat AKS-klusternamn. I följande exempel används namnet myakscluster:

aksname="myakscluster"

Översikt över Microsoft Entra-autentisering

Microsoft Entra-autentisering tillhandahålls till AKS-kluster med OpenID Connect. OpenID Connect är ett identitetslager som bygger på OAuth 2.0-protokollet. Mer information om OpenID Connect finns i OpenID Connect-dokumentationen.

Inifrån Kubernetes-klustret används Webhook Token Authentication för att verifiera autentiseringstoken. Webhook-tokenautentisering konfigureras och hanteras som en del av AKS-klustret. Mer information om Webhook-tokenautentisering finns i dokumentationen för webhook-autentisering.

Skapa Microsoft Entra-serverkomponent

För att integrera med AKS skapar och använder du ett Microsoft Entra-program som fungerar som en slutpunkt för identitetsbegäranden. Det första Microsoft Entra-programmet du behöver får Microsoft Entra-gruppmedlemskap för en användare.

Skapa serverprogramkomponenten med kommandot az ad app create och uppdatera sedan anspråken för gruppmedlemskap med kommandot az ad app update . I följande exempel används aksname-variabeln som definierats i avsnittet Innan du börjar och skapar en variabel

# Create the Azure AD application
serverApplicationId=$(az ad app create \
    --display-name "${aksname}Server" \
    --identifier-uris "https://${aksname}Server" \
    --query appId -o tsv)

# Update the application group membership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All

Skapa nu ett huvudnamn för tjänsten för serverappen med kommandot az ad sp create . Tjänstens huvudnamn används för att autentisera sig själv inom Azure-plattformen. Hämta sedan tjänstens huvudhemlighet med kommandot az ad sp credential reset och tilldela variabeln serverApplicationSecret för användning i något av följande steg:

# Create a service principal for the Azure AD application
az ad sp create --id $serverApplicationId

# Get the service principal secret
serverApplicationSecret=$(az ad sp credential reset \
    --name $serverApplicationId \
    --credential-description "AKSPassword" \
    --query password -o tsv)

Microsoft Entra-tjänstens huvudnamn behöver behörighet för att utföra följande åtgärder:

• Läsa katalogdata
• Logga in och läs användarprofilen

Tilldela dessa behörigheter med hjälp av kommandot az ad app permission add :

az ad app permission add \
    --id $serverApplicationId \
    --api 00000003-0000-0000-c000-000000000000 \
    --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role

Bevilja slutligen de behörigheter som tilldelades i föregående steg för serverprogrammet med hjälp av kommandot az ad app permission grant . Det här steget misslyckas om det aktuella kontot inte är en klientorganisationsadministratör. Du måste också lägga till behörigheter för Microsoft Entra-programmet för att begära information som annars kan kräva administrativt medgivande med hjälp av az ad app permission admin-consent:

az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id  $serverApplicationId

Skapa Microsoft Entra-klientkomponent

Det andra Microsoft Entra-programmet används när en användare loggar till AKS-klustret med Kubernetes CLI (kubectl). Det här klientprogrammet tar autentiseringsbegäran från användaren och verifierar deras autentiseringsuppgifter och behörigheter. Skapa Microsoft Entra-appen för klientkomponenten med kommandot az ad app create :

clientApplicationId=$(az ad app create \
    --display-name "${aksname}Client" \
    --native-app \
    --reply-urls "https://${aksname}Client" \
    --query appId -o tsv)

Skapa ett huvudnamn för tjänsten för klientprogrammet med kommandot az ad sp create :

az ad sp create --id $clientApplicationId

Hämta oAuth2-ID:t för serverappen för att tillåta autentiseringsflödet mellan de två appkomponenterna med kommandot az ad app show . Det här oAuth2-ID:t används i nästa steg.

oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)

Lägg till behörigheterna för klientprogrammet och serverprogramkomponenterna för att använda kommunikationsflödet oAuth2 med hjälp av kommandot az ad app permission add . Bevilja sedan behörigheter för klientprogrammet till kommunikation med serverprogrammet med hjälp av kommandot az ad app permission grant :

az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions ${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId

Distribuera klustret

När de två Microsoft Entra-programmen har skapats skapar du nu själva AKS-klustret. Skapa först en resursgrupp med kommandot az group create . I följande exempel skapas resursgruppen i regionen EastUS :

Skapa en resursgrupp för klustret:

az group create --name myResourceGroup --location EastUS

Hämta klient-ID:t för din Azure-prenumeration med kommandot az account show . Skapa sedan AKS-klustret med kommandot az aks create . Kommandot för att skapa AKS-klustret innehåller server- och klientprogram-ID:t, serverprogrammets huvudhemlighet och ditt klient-ID:

tenantId=$(az account show --query tenantId -o tsv)

az aks create \
    --resource-group myResourceGroup \
    --name $aksname \
    --node-count 1 \
    --generate-ssh-keys \
    --aad-server-app-id $serverApplicationId \
    --aad-server-app-secret $serverApplicationSecret \
    --aad-client-app-id $clientApplicationId \
    --aad-tenant-id $tenantId

Slutligen hämtar du autentiseringsuppgifterna för klusteradministratören med kommandot az aks get-credentials . I något av följande steg får du autentiseringsuppgifterna för det vanliga användarklustret för att se microsoft Entra-autentiseringsflödet i praktiken.

az aks get-credentials --resource-group myResourceGroup --name $aksname --admin

Skapa Kubernetes RBAC-bindning

Innan ett Microsoft Entra-konto kan användas med AKS-klustret måste en rollbindning eller klusterrollbindning skapas. Roller definierar behörigheter att bevilja och bindningar tillämpar dem på önskade användare. Dessa tilldelningar kan tillämpas på ett givet namnområde eller i hela klustret. Mer information finns i Använda Kubernetes RBAC-auktorisering.

Hämta användarens huvudnamn (UPN) för den användare som för närvarande är inloggad med kommandot az ad signed-in-user show . Det här användarkontot är aktiverat för Microsoft Entra-integrering i nästa steg.

az ad signed-in-user show --query userPrincipalName -o tsv

Skapa ett YAML-manifest med namnet basic-azure-ad-binding.yaml och klistra in följande innehåll. På den sista raden ersätter du userPrincipalName_or_objectId med UPN- eller objekt-ID-utdata från föregående kommando:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: contoso-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: userPrincipalName_or_objectId

Skapa ClusterRoleBinding med kommandot kubectl apply och ange filnamnet för YAML-manifestet:

kubectl apply -f basic-azure-ad-binding.yaml

Komma åt kluster med Microsoft Entra-ID

Nu ska vi testa integreringen av Microsoft Entra-autentisering för AKS-klustret. Ange konfigurationskontexten kubectl så att den använder vanliga användarautentiseringsuppgifter. Den här kontexten skickar tillbaka alla autentiseringsbegäranden via Microsoft Entra-ID.

az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing

Använd nu kommandot kubectl get pods för att visa poddar i alla namnområden:

kubectl get pods --all-namespaces

Du får en inloggningsprompt för att autentisera med Microsoft Entra-autentiseringsuppgifter med hjälp av en webbläsare. När du har autentiserats kubectl visas poddarna i AKS-klustret enligt följande exempelutdata:

kubectl get pods --all-namespaces

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BYMK7UXVD to authenticate.

NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kube-system   coredns-754f947b4-2v75r                 1/1     Running   0          23h
kube-system   coredns-754f947b4-tghwh                 1/1     Running   0          23h
kube-system   coredns-autoscaler-6fcdb7d64-4wkvp      1/1     Running   0          23h
kube-system   heapster-5fb7488d97-t5wzk               2/2     Running   0          23h
kube-system   kube-proxy-2nd5m                        1/1     Running   0          23h
kube-system   kube-svc-redirect-swp9r                 2/2     Running   0          23h
kube-system   kubernetes-dashboard-847bb4ddc6-trt7m   1/1     Running   0          23h
kube-system   metrics-server-7b97f9cd9-btxzz          1/1     Running   0          23h
kube-system   tunnelfront-6ff887cffb-xkfmq            1/1     Running   0          23h

Den autentiseringstoken som tas emot för kubectl cachelagras. Du kan bara logga in igen när token har upphört att gälla eller kubernetes-konfigurationsfilen återskapas.

Om du ser ett auktoriseringsfel när du har loggat in med en webbläsare som i följande exempelutdata kontrollerar du följande möjliga problem:

error: You must be logged in to the server (Unauthorized)

• Du har definierat lämpligt objekt-ID eller UPN, beroende på om användarkontot finns i samma Microsoft Entra-klientorganisation eller inte.
• Användaren är inte medlem i fler än 200 grupper.
• Hemligheten som definieras i programregistreringen för servern matchar det värde som konfigurerats med hjälp av --aad-server-app-secret
• Se till att endast en version av kubectl är installerad på datorn i taget. Motstridiga versioner kan orsaka problem under auktoriseringen. Om du vill installera den senaste versionen använder du az aks install-cli.

Vanliga frågor och svar om migrering från Microsoft Entra-integrering till AKS-hanterat Microsoft Entra-ID

1. Vad är planen för migrering?

Microsoft Entra-integrering (äldre) kommer att bli inaktuell den 1 juni 2023. Efter det här datumet kan du inte skapa nya kluster med Microsoft Entra-ID (äldre). Vi migrerar alla Microsoft Entra-integreringskluster (äldre) AKS till AKS-hanterade Microsoft Entra-ID automatiskt från och med den 1 augusti 2023. Vi skickar e-postmeddelanden till prenumerationsadministratörer som påverkas varannan vecka för att påminna dem om migrering.

2. Vad händer om jag inte vidtar några åtgärder?

Dina AKS-kluster för Microsoft Entra-integrering (äldre) fortsätter att fungera efter den 1 juni 2023. Vi migrerar automatiskt dina kluster till AKS-hanterat Microsoft Entra-ID från och med den 1 augusti 2023. Det kan uppstå avbrott i API-servern under migreringen.

Kubeconfig-innehållet ändras efter migreringen. Du måste sammanfoga de nya autentiseringsuppgifterna i kubeconfig-filen med hjälp av az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.

Vi rekommenderar att du uppdaterar ditt AKS-kluster till AKS-hanterat Microsoft Entra-ID manuellt före den 1 augusti. På så sätt kan du hantera stilleståndstiden under andra tider än kontorstid när det är bekvämare.

3. Varför får jag fortfarande e-postmeddelandet efter manuell migrering?

Det tar flera dagar innan e-postmeddelandet skickas. Om klustret inte migrerades innan vi initierade e-postsändningsprocessen kan du fortfarande få ett meddelande.

4. Hur kan jag kontrollera om mitt kluster migreras till AKS-hanterat Microsoft Entra-ID?

Bekräfta att ditt AKS-kluster migreras till det AKS-hanterade Microsoft Entra-ID:t az aks show med hjälp av kommandot .

az aks show -g <RGName> -n <ClusterName>  --query "aadProfile"

Om klustret använder DET AKS-hanterade Microsoft Entra-ID:t är managed trueutdata . Till exempel:

    {
      "adminGroupObjectIDs": [
        "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      ],
      "adminUsers": null,
      "clientAppId": null,
      "enableAzureRbac": null,
      "managed": true,
      "serverAppId": null,
      "serverAppSecret": null,
      "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }

Nästa steg

Det fullständiga skriptet som innehåller kommandona som visas i den här artikeln finns i [Microsoft Entra-integreringsskriptet i AKS-exempelrepo][complete-script].

Information om hur du använder Microsoft Entra-användare och -grupper för att styra åtkomsten till klusterresurser finns i Kontrollera åtkomsten till klusterresurser med kubernetes rollbaserad åtkomstkontroll och Microsoft Entra-identiteter i AKS.

Mer information om hur du skyddar Kubernetes-kluster finns i Åtkomst- och identitetsalternativ för AKS).

Metodtips för identitets- och resurskontroll finns i Metodtips för autentisering och auktorisering i AKS.