Integrace ID Microsoft Entra se službou Azure Kubernetes Service (AKS) pomocí Azure CLI (starší verze)
Upozorňující
Funkce popsaná v tomto dokumentu byla 1. června 2023 zastaralá . V tuto chvíli není možné vytvářet žádné nové clustery s integrací Microsoft Entra (starší verze).
AKS má nové vylepšené prostředí Microsoft Entra ID spravované službou AKS, které nevyžaduje správu serverových nebo klientských aplikací. Pokud chcete migrovat, postupujte podle zde uvedených pokynů.
Azure Kubernetes Service (AKS) je možné nakonfigurovat tak, aby pro ověřování uživatelů používalo ID Microsoft Entra. V této konfiguraci se můžete přihlásit ke clusteru AKS pomocí ověřovacího tokenu Microsoft Entra. Operátoři clusteru můžou také nakonfigurovat řízení přístupu na základě role Kubernetes (Kubernetes RBAC) na základě identity uživatele nebo členství ve skupině adresářů.
V tomto článku se dozvíte, jak vytvořit požadované komponenty Microsoft Entra, pak nasadit cluster s podporou ID Microsoftu a vytvořit základní roli Kubernetes v clusteru AKS.
Omezení
- ID Microsoft Entra je možné povolit pouze v clusteru s podporou RBAC Kubernetes.
- Starší verze integrace Microsoft Entra je možné povolit pouze při vytváření clusteru.
Než začnete
Potřebujete nainstalovanou a nakonfigurovanou verzi Azure CLI 2.0.61 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.
https://shell.azure.com V prohlížeči otevřete Cloud Shell.
Pokud chcete zajistit konzistenci a pomoct s spuštěním příkazů v tomto článku, vytvořte proměnnou pro požadovaný název clusteru AKS. Následující příklad používá název myakscluster:
aksname="myakscluster"
Přehled ověřování Microsoft Entra
Ověřování Microsoft Entra se poskytuje clusterům AKS s openID Připojení. OpenID Připojení je vrstva identit založená na protokolu OAuth 2.0. Další informace o Připojení OpenID najdete v dokumentaci k Připojení OpenID.
V clusteru Kubernetes se k ověření ověřovacích tokenů používá ověřování tokenů Webhook. Ověřování tokenu Webhooku se konfiguruje a spravuje jako součást clusteru AKS. Další informace o ověřování pomocí tokenu Webhook najdete v dokumentaci k ověřování webhooku.
Poznámka:
Při konfiguraci Microsoft Entra ID pro ověřování AKS jsou nakonfigurovány dvě aplikace Microsoft Entra. Tuto operaci musí dokončit správce tenanta Azure.
Vytvoření součásti serveru Microsoft Entra
K integraci s AKS vytvoříte a použijete aplikaci Microsoft Entra, která funguje jako koncový bod pro žádosti o identitu. První aplikace Microsoft Entra, kterou potřebujete, získá členství ve skupině Microsoft Entra pro uživatele.
Pomocí příkazu az ad app create vytvořte komponentu serverové aplikace a pak pomocí příkazu az ad app update aktualizujte deklarace identity členství ve skupině. Následující příklad používá proměnnou aksname definovanou v části Před zahájením a vytvoří proměnnou.
# 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
Teď vytvořte instanční objekt pro serverovou aplikaci pomocí příkazu az ad sp create . Tento instanční objekt se používá k ověření v rámci platformy Azure. Pak pomocí příkazu az ad sp credential reset získejte tajný kód instančního objektu a přiřaďte proměnnou s názvem serverApplicationSecret pro použití v jednom z následujících kroků:
# 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)
Instanční objekt Microsoft Entra potřebuje oprávnění k provedení následujících akcí:
- Čtení dat adresáře
- Přihlášení a čtení profilu uživatele
Přiřaďte tato oprávnění pomocí příkazu 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
Nakonec pomocí příkazu az ad app permission grant grant udělte oprávnění přiřazená v předchozím kroku pro serverovou aplikaci. Tento krok selže, pokud aktuální účet není správcem tenanta. K vyžádání informací, které můžou jinak vyžadovat souhlas správce pomocí příkazu az ad app permission admin-consent, musíte také přidat oprávnění pro aplikaci Microsoft Entra:
az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id $serverApplicationId
Vytvoření klientské komponenty Microsoft Entra
Druhá aplikace Microsoft Entra se používá, když se uživatel přihlásí ke clusteru AKS pomocí rozhraní příkazového řádku Kubernetes (kubectl). Tato klientská aplikace převezme žádost o ověření od uživatele a ověří své přihlašovací údaje a oprávnění. Pomocí příkazu az ad app create vytvořte aplikaci Microsoft Entra pro klientskou komponentu:
clientApplicationId=$(az ad app create \
--display-name "${aksname}Client" \
--native-app \
--reply-urls "https://${aksname}Client" \
--query appId -o tsv)
Pomocí příkazu az ad sp create vytvořte instanční objekt pro klientskou aplikaci:
az ad sp create --id $clientApplicationId
Získejte ID oAuth2 pro serverovou aplikaci, abyste umožnili tok ověřování mezi dvěma komponentami aplikace pomocí příkazu az ad app show . Toto ID oAuth2 se používá v dalším kroku.
oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)
Pomocí příkazu az ad app permission add přidejte oprávnění pro klientské aplikace a součásti serverové aplikace pro použití komunikačního toku oAuth2. Potom udělte oprávnění klientské aplikaci ke komunikaci se serverovou aplikací pomocí příkazu 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
Nasazení clusteru
Se dvěma vytvořenými aplikacemi Microsoft Entra teď vytvořte samotný cluster AKS. Nejprve vytvořte skupinu prostředků pomocí příkazu az group create . Následující příklad vytvoří skupinu prostředků v oblasti EastUS :
Vytvořte skupinu prostředků pro cluster:
az group create --name myResourceGroup --location EastUS
Pomocí příkazu az account show získejte ID tenanta vašeho předplatného Azure. Pak vytvořte cluster AKS pomocí příkazu az aks create . Příkaz k vytvoření clusteru AKS poskytuje ID serverových a klientských aplikací, tajný klíč instančního objektu aplikace serveru a ID vašeho tenanta:
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
Nakonec pomocí příkazu az aks get-credentials získejte přihlašovací údaje správce clusteru. V jednom z následujících kroků získáte běžné přihlašovací údaje ke clusteru uživatelů , abyste viděli tok ověřování Microsoft Entra v akci.
az aks get-credentials --resource-group myResourceGroup --name $aksname --admin
Vytvoření vazby RBAC Kubernetes
Před použitím účtu Microsoft Entra s clusterem AKS je potřeba vytvořit vazbu role nebo vazbu role clusteru. Role definují oprávnění k udělení a vazby je použijí pro požadované uživatele. Tato přiřazení se dají použít pro daný obor názvů nebo v celém clusteru. Další informace najdete v tématu Použití autorizace RBAC Kubernetes.
Získejte hlavní název uživatele (UPN) uživatele, který je aktuálně přihlášený pomocí příkazu az ad signed-in-user show . Tento uživatelský účet je povolený pro integraci Microsoft Entra v dalším kroku.
az ad signed-in-user show --query userPrincipalName -o tsv
Důležité
Pokud uživatel, kterému udělíte vazbu RBAC Kubernetes, je ve stejném tenantovi Microsoft Entra, přiřaďte oprávnění na základě userPrincipalName. Pokud je uživatel v jiném tenantovi Microsoft Entra, zadejte dotaz a použijte místo toho vlastnost objectId .
Vytvořte manifest YAML s názvem basic-azure-ad-binding.yaml a vložte následující obsah. Na posledním řádku nahraďte userPrincipalName_or_objectId výstupem hlavního názvu uživatele (UPN) nebo ID objektu z předchozího příkazu:
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
Vytvořte clusterRoleBinding pomocí příkazu kubectl apply a zadejte název souboru manifestu YAML:
kubectl apply -f basic-azure-ad-binding.yaml
Přístup ke clusteru s ID Microsoft Entra
Teď otestujeme integraci ověřování Microsoft Entra pro cluster AKS. kubectl Nastavte kontext konfigurace tak, aby používal běžné přihlašovací údaje uživatele. Tento kontext předává všechny žádosti o ověření zpět prostřednictvím ID Microsoft Entra.
az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing
Teď pomocí příkazu kubectl get pods zobrazte pody ve všech oborech názvů:
kubectl get pods --all-namespaces
Zobrazí se výzva k přihlášení k ověření pomocí přihlašovacích údajů Microsoft Entra ve webovém prohlížeči. Po úspěšném ověření zobrazí kubectl příkaz pody v clusteru AKS, jak je znázorněno v následujícím příkladu výstupu:
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
Přijatý ověřovací token je kubectl uložen v mezipaměti. Pokud vypršela platnost tokenu nebo se konfigurační soubor Kubernetes znovu vytvoří, budete se znovu přihlašovat.
Pokud se po úspěšném přihlášení pomocí webového prohlížeče zobrazí chybová zpráva autorizace jako v následujícím příkladu výstupu, zkontrolujte následující možné problémy:
error: You must be logged in to the server (Unauthorized)
- V závislosti na tom, jestli je uživatelský účet ve stejném tenantovi Microsoft Entra nebo ne, jste definovali příslušné ID objektu nebo hlavní název uživatele (UPN).
- Uživatel není členem více než 200 skupin.
- Tajný klíč definovaný v registraci aplikace pro server odpovídá hodnotě nakonfigurované pomocí
--aad-server-app-secret - Ujistěte se, že na počítači je současně nainstalovaná jenom jedna verze kubectl. Konfliktní verze můžou způsobit problémy během autorizace. Pokud chcete nainstalovat nejnovější verzi, použijte az aks install-cli.
Nejčastější dotazy týkající se migrace z integrace Microsoft Entra do AKS spravovaného ID Microsoft Entra
1. Jaký je plán migrace?
Microsoft Entra Integration (starší verze) bude vyřazen z 1. června 2023. Po tomto datu nebudete moct vytvářet nové clustery s ID Microsoft Entra (starší verze). Všechny clustery AKS microsoft Entra Integration (starší verze) migrujeme na ID Microsoft Entra spravované službou Microsoft Entra automaticky počínaje 1. srpnem 2023. Posíláme e-maily s oznámeními, které mají vliv na správce předplatného, a to biweektivně, abychom jim připomněli migraci.
2. Co se stane, když neprojdu žádnou akcí?
Vaše clustery AKS microsoft Entra Integration (starší verze) budou fungovat i po 1. červnu 2023. Vaše clustery automaticky migrujeme na ID Microsoft Entra spravované službou AKS od 1. srpna 2023. Během migrace může dojít k výpadku serveru rozhraní API.
Obsah kubeconfig se po migraci změní. Nové přihlašovací údaje musíte sloučit do souboru kubeconfig pomocí příkazu az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.
Cluster AKS doporučujeme aktualizovat na AKS spravované ID Microsoft Entra ručně před 1. srpnem. Tímto způsobem můžete spravovat výpadky mimo pracovní dobu, když je pohodlnější.
3. Proč po ruční migraci stále dostávám e-mail s oznámením?
Odeslání e-mailu trvá několik dní. Pokud se váš cluster před zahájením procesu odesílání e-mailů nemigroval, může se vám stále zobrazovat oznámení.
4. Jak můžu zkontrolovat, jestli je můj cluster migrovaný na ID Microsoft Entra spravované službou AKS?
Pomocí příkazu ověřte, že se váš cluster AKS migruje do ID Microsoft Entra spravovaného službou az aks show AKS.
az aks show -g <RGName> -n <ClusterName> --query "aadProfile"
Pokud váš cluster používá ID Microsoft Entra spravované službou AKS, zobrazí managedtruese výstup . Příklad:
{
"adminGroupObjectIDs": [
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
],
"adminUsers": null,
"clientAppId": null,
"enableAzureRbac": null,
"managed": true,
"serverAppId": null,
"serverAppSecret": null,
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
Další kroky
Úplný skript, který obsahuje příkazy uvedené v tomto článku, najdete v tématu [Integrační skript Microsoft Entra v úložišti ukázek AKS][complete-script].
Pokud chcete k řízení přístupu k prostředkům clusteru použít uživatele a skupiny Microsoft Entra, přečtěte si téma Řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě role Kubernetes a identit Microsoft Entra v AKS.
Další informace o zabezpečení clusterů Kubernetes najdete v tématu Možnosti přístupu a identit pro AKS.
Osvědčené postupy pro správu identit a prostředků najdete v tématu Osvědčené postupy pro ověřování a autorizaci v AKS.