Megosztás a következőn keresztül:


A Microsoft Entra ID integrálása az Azure Kubernetes Service-vel (AKS) az Azure CLI (korábbi) használatával

Figyelmeztetés

A jelen dokumentumban ismertetett funkció, a Microsoft Entra Integration (örökölt) 2023. június 1-jén elavult. Jelenleg nem hozhatók létre új csoportok a Microsoft Entra Integration (örökölt) használatával.

Az AKS új továbbfejlesztett , AKS által felügyelt Microsoft Entra-azonosítóval rendelkezik, amely nem igényli a kiszolgáló- vagy ügyfélalkalmazások kezelését. Ha migrálni szeretne, kövesse az itt található utasításokat.

Az Azure Kubernetes Service (AKS) konfigurálható úgy, hogy a Microsoft Entra ID-t használja a felhasználói hitelesítéshez. Ebben a konfigurációban Microsoft Entra hitelesítési token használatával bejelentkezhet az AKS-fürtbe. A fürtüzemeltetők a Kubernetes szerepköralapú hozzáférés-vezérlését (Kubernetes RBAC) is konfigurálhatják a felhasználó identitása vagy címtárcsoport-tagsága alapján.

Ez a cikk bemutatja, hogyan hozhatja létre a szükséges Microsoft Entra-összetevőket, majd hogyan helyezhet üzembe egy Microsoft Entra id-kompatibilis fürtöt, és hogyan hozhat létre alapszintű Kubernetes-szerepkört az AKS-fürtben.

Korlátozások

  • A Microsoft Entra-azonosító csak Kubernetes RBAC-kompatibilis fürtön engedélyezhető.
  • A Microsoft Entra legacy integráció csak a fürt létrehozásakor engedélyezhető.

Mielőtt elkezdené

Telepítenie és konfigurálnia kell az Azure CLI 2.0.61-es vagy újabb verzióját. A verzió azonosításához futtassa a következőt: az --version. Ha telepíteni vagy frissíteni szeretne: Az Azure CLI telepítése.

Nyissa meg a https://shell.azure.com Cloud Shellt a böngészőben.

A konzisztencia érdekében és a jelen cikkben szereplő parancsok futtatásához hozzon létre egy változót a kívánt AKS-fürt nevéhez. Az alábbi példa a myakscluster nevet használja:

aksname="myakscluster"

A Microsoft Entra-hitelesítés áttekintése

A Microsoft Entra-hitelesítés az OpenID Connecttel rendelkező AKS-fürtök számára biztosított. Az OpenID Connect egy identitásréteg, amely az OAuth 2.0 protokollra épül. Az OpenID Connectről további információt az OpenID Connect dokumentációjában talál.

A Kubernetes-fürtben a Webhook Token Authentication a hitelesítési jogkivonatok ellenőrzésére szolgál. A webhook-jogkivonat-hitelesítés az AKS-fürt részeként van konfigurálva és felügyelve. A Webhook-jogkivonatok hitelesítésével kapcsolatos további információkért tekintse meg a webhook-hitelesítés dokumentációját.

Feljegyzés

A Microsoft Entra ID AKS-hitelesítéshez való konfigurálásakor két Microsoft Entra-alkalmazás van konfigurálva. Ezt a műveletet egy Azure-bérlői rendszergazdának kell végrehajtania.

Microsoft Entra-kiszolgáló összetevő létrehozása

Az AKS-vel való integrációhoz létre kell hoznia és használnia kell egy Microsoft Entra-alkalmazást, amely végpontként szolgál az identitáskérésekhez. Az első Microsoft Entra alkalmazás, amire szüksége van, megszerzi egy felhasználó számára a Microsoft Entra csoporttagságot.

Hozza létre a kiszolgálóalkalmazás-összetevőt az az ad app create paranccsal, majd frissítse a csoporttagsági jogcímeket az az ad app update paranccsal. Az alábbi példa a Kezdés előtt szakaszban definiált aksname változót használja, és létrehoz egy változót

# 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

Most hozzon létre egy egyszerű szolgáltatást a kiszolgálóalkalmazáshoz az az ad sp create paranccsal. Ez a szolgáltatásnév az Azure-platformon belüli hitelesítésre szolgál. Ezután kérje le a szolgáltatási főkulcsot az az ad sp credential reset paranccsal, és rendelje hozzá a serverApplicationSecret nevű változóhoz a következő lépések egyikének használatához.

# 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)

A Microsoft Entra szolgáltatásnévnek engedélyekre van szüksége a következő műveletek végrehajtásához:

  • Címtáradatok olvasása
  • Bejelentkezés és felhasználói profil olvasása

Rendelje hozzá ezeket az engedélyeket az az ad app permission add paranccsal:

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

Végül adja meg az előző lépésben hozzárendelt engedélyeket a kiszolgálóalkalmazáshoz az az ad app permission grant paranccsal. Ez a lépés meghiúsul, ha az aktuális fiók nem bérlői rendszergazda. Engedélyeket is hozzá kell adnia a Microsoft Entra-alkalmazáshoz, hogy olyan információkat kérjen, amelyek egyébként adminisztratív hozzájárulást igényelhetnek a következő paranccsal: 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

Microsoft Entra-ügyfélösszetevő létrehozása

A második Microsoft Entra-alkalmazást akkor használja a rendszer, ha egy felhasználó bejelentkezik az AKS-fürtbe a Kubernetes parancssori felületével (kubectl). Ez az ügyfélalkalmazás átveszi a felhasználó hitelesítési kérését, és ellenőrzi a hitelesítő adatait és engedélyeit. Hozza létre a Microsoft Entra alkalmazást az ügyfélösszetevőhöz az az ad app create paranccsal:

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

Hozzon létre egy szolgáltatási főszereplőt az ügyfélalkalmazáshoz az az ad sp create paranccsal.

az ad sp create --id $clientApplicationId

Szerezze be a kiszolgálóalkalmazás oAuth2 azonosítóját, amely lehetővé teszi a két alkalmazásösszetevő közötti hitelesítési folyamatot az az ad app show paranccsal. Ezt az oAuth2 azonosítót használja a következő lépés.

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

Adja hozzá az ügyfélalkalmazás és a kiszolgálóalkalmazás-összetevők engedélyeit az oAuth2 kommunikációs folyamat használatához az az ad app permission add paranccsal. Ezután adjon engedélyeket az ügyfélalkalmazásnak a kiszolgálóalkalmazással való kommunikációhoz az az ad app permission grant paranccsal:

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

Helyezze üzembe a fürtöt

A két Microsoft Entra-alkalmazás létrehozásával most hozza létre magát az AKS-fürtöt. Először hozzon létre egy erőforráscsoportot a group create paranccsal. Az alábbi példa létrehozza az erőforráscsoportot az EastUS régióban:

Hozzon létre egy erőforráscsoportot a klaszterhez:

az group create --name myResourceGroup --location EastUS

Kérje le az Azure-előfizetés bérlőazonosítóját az az account show paranccsal. Ezután hozza létre az AKS-fürtöt a az aks create paranccsal. Az AKS-fürt létrehozásához használt parancs megadja a kiszolgáló- és ügyfélalkalmazás-azonosítókat, a kiszolgálói alkalmazás szolgáltatási titkos kulcsát, valamint a bérlőazonosítót.

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

Végül kérje le a fürt rendszergazdai hitelesítő adatait az az aks get-credentials paranccsal. Az alábbi lépések egyikében lekérheti a szokásos felhasználói fürt hitelesítő adatait, hogy megtekintse a Microsoft Entra hitelesítési folyamatát működés közben.

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

Kubernetes RBAC-kötés létrehozása

Ahhoz, hogy egy Microsoft Entra-fiók használható legyen az AKS-fürttel, létre kell hozni egy szerepkör-kötést vagy egy fürtszerepkör-kötést. A szerepkörök határozzák meg az engedélyeket, és a kötések a kívánt felhasználókra alkalmazzák őket. Ezek a hozzárendelések alkalmazhatók egy adott névtérre vagy a teljes fürtre. További információ: Kubernetes RBAC-hitelesítés használata.

Kérje le az aktuálisan bejelentkezett felhasználó felhasználói főnevét (UPN) az az ad signed-in-user show paranccsal. Ez a felhasználói fiók a következő lépésben engedélyezve van a Microsoft Entra integrációjához.

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

Fontos

Ha a felhasználó, akinek a Kubernetes RBAC-kötést megadta, ugyanabban a Microsoft Entra-bérlőben van, a userPrincipalName alapján rendeljen hozzá engedélyeket. Ha a felhasználó egy másik Microsoft Entra-bérlőben van, inkább az objectId tulajdonságot kérdezi le és használja.

Hozzon létre egy YAML-jegyzékfájlt, basic-azure-ad-binding.yaml és illessze be a következő tartalmat. Az utolsó sorban cserélje le a userPrincipalName_or_objectId-t az előző parancs UPN- vagy objektumazonosító kimenetére.

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

Hozza létre a ClusterRoleBindinget a kubectl apply paranccsal, és adja meg a YAML-jegyzékfájl fájlnevét:

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

Klaszter elérése Microsoft Entra-azonosítóval

Most teszteljük az AKS-fürt Microsoft Entra hitelesítési integrációját. Állítsa be a kubectl konfigurációs környezetet normál felhasználói hitelesítő adatok használatára. Ez a környezet az összes hitelesítési kérést a Microsoft Entra-azonosítón keresztül továbbítja.

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

Most használja a kubectl get pods parancsot a podok megtekintéséhez az összes névtérben:

kubectl get pods --all-namespaces

Bejelentkezési kérést kap a Microsoft Entra hitelesítő adataival való hitelesítéshez egy webböngésző használatával. A sikeres hitelesítés után a kubectl parancs megjeleníti a podokat az AKS-környezetben, ahogyan az alábbi példakimenetben látható.

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

A kubectl számára kapott hitelesítési jogkivonat gyorsítótárba lett helyezve. Csak akkor kérjük újra a bejelentkezést, ha a jogkivonat lejárt, vagy a Kubernetes konfigurációs fájl újból létrejön.

Ha a böngészővel való sikeres bejelentkezés után engedélyezési hibaüzenet jelenik meg, mint az alábbi példakimenetben, ellenőrizze az alábbi lehetséges problémákat:

error: You must be logged in to the server (Unauthorized)
  • Meghatározta a megfelelő objektumazonosítót vagy UPN-t attól függően, hogy a felhasználói fiók ugyanabban a Microsoft Entra-bérlőben van-e, vagy sem.
  • A felhasználó nem tagja több mint 200 csoportnak.
  • A kiszolgáló alkalmazásregisztrációjában definiált titkos kód megegyezik a következővel konfigurált értékkel: --aad-server-app-secret
  • Győződjön meg arról, hogy egyszerre csak egy kubectl-verzió van telepítve a gépen. Az ütköző verziók problémákat okozhatnak az engedélyezés során. A legújabb verzió telepítéséhez használja az aks install-cli parancsot.

Gyakori kérdések a Microsoft Entra-integrációról az AKS által felügyelt Microsoft Entra-azonosítóra való migrálással kapcsolatban

1. Mi a migráció terve?

A Microsoft Entra Integration (korábbi) 2023. június 1-jén elavult lesz. Ezen dátum után nem hozhat létre új fürtöket a Microsoft Entra ID (korábbi) használatával. 2023. augusztus 1-től automatikusan áttelepítjük az összes Microsoft Entra-integráció (legacy) AKS-fürtöt az AKS által felügyelt Microsoft Entra ID-be. Az érintett előfizetés-rendszergazdáknak kéthetes értesítési e-maileket küldünk, hogy emlékeztesse őket a migrálásra.

2. Mi fog történni, ha nem teszek semmit?

A Microsoft Entra-integrációs (örökölt) AKS-fürtök 2023. június 1. után is működni fognak. 2023. augusztus 1-től automatikusan migráljuk a fürtöket (clusters) az AKS által felügyelt Microsoft Entra ID-ba. Az API-kiszolgáló leállása a migrálás során előfordulhat.

A kubeconfig-tartalom a migrálás után megváltozik. Az új hitelesítő adatokat a kubeconfig fájlba kell egyesítenie a az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.

Azt javasoljuk, hogy augusztus 1-ig manuálisan frissítse az AKS-fürtöt az AKS által felügyelt Microsoft Entra-azonosítóra . Így a munkaidőn kívüli időszakokban is kezelheti az állásidőt, amikor kényelmesebb.

3. Miért kapom meg továbbra is az értesítési e-mailt a manuális migrálás után?

Az e-mail elküldése több napig tart. Ha a klasztert nem migrálták, mielőtt elindítanánk az e-mail-küldési folyamatot, akkor is előfordulhat, hogy értesítést kap.

4. Hogyan ellenőrizhetim, hogy a fürtöm migrálva van-e az AKS által felügyelt Microsoft Entra-azonosítóra?

Ellenőrizze, hogy az AKS-fürt migrálva van-e az AKS által felügyelt Microsoft Entra ID rendszerbe a az aks show parancs használatával.

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

Ha a fürt az AKS által felügyelt Microsoft Entra-azonosítót használja, a kimenet az managedtrue. Példa:

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

Következő lépések

A cikkben bemutatott parancsokat tartalmazó teljes szkriptért lásd a [Microsoft Entra integrációs szkriptet az AKS-minták adattárában][complete-script].

Ha a Microsoft Entra felhasználóit és csoportjait szeretné használni a fürterőforrásokhoz való hozzáférés szabályozásához, olvassa el a Fürterőforrások hozzáférésének szabályozása a Kubernetes szerepköralapú hozzáférés-vezérléssel és a Microsoft Entra-identitásokkal az AKS-ben című témakört.

A Kubernetes-fürtök biztonságára vonatkozó további információkért lásd az AKS-hez kapcsolódó Hozzáférési és identitásbeállítási lehetőségek.

Az identitás- és erőforrás-vezérléssel kapcsolatos ajánlott eljárásokért tekintse meg az AKS-ben való hitelesítés és engedélyezés ajánlott eljárásait.