Použití řízení přístupu na základě role Kubernetes s ID Microsoft Entra ve službě Azure Kubernetes Service

Článek
10/24/2023

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 přihlásíte ke clusteru AKS pomocí ověřovacího tokenu Microsoft Entra. Po ověření můžete pomocí integrovaného řízení přístupu na základě role Kubernetes (Kubernetes RBAC) spravovat přístup k oborům názvů a prostředkům clusteru na základě identity uživatele nebo členství ve skupině.

V tomto článku se dozvíte, jak:

Řízení přístupu pomocí RBAC Kubernetes v clusteru AKS na základě členství ve skupině Microsoft Entra
Vytvořte ukázkové skupiny a uživatele v MICROSOFT Entra ID.
Vytvořte role a vazby rolí v clusteru AKS, abyste udělili příslušná oprávnění k vytváření a zobrazení prostředků.

Než začnete

Máte existující cluster AKS s povolenou integrací Microsoft Entra. Pokud potřebujete cluster AKS s touto konfigurací, přečtěte si téma Integrace ID Microsoft Entra s AKS.
Kubernetes RBAC je ve výchozím nastavení povolen během vytváření clusteru AKS. Pokud chcete upgradovat cluster s integrací Microsoft Entra a RBAC Kubernetes, povolte integraci Microsoft Entra ve stávajícím clusteru AKS.
Ujistěte se, že je nainstalované a nakonfigurované Rozhraní příkazového řádku Azure CLI verze 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.
Pokud používáte Terraform, nainstalujte Terraform verze 2.99.0 nebo novější.

Pomocí webu Azure Portal nebo Azure CLI ověřte, že je povolená integrace Microsoft Entra s RBAC Kubernetes.

Azure Portal
Azure CLI

Ověření pomocí webu Azure Portal:

V prohlížeči se přihlaste k webu Azure Portal.
Přejděte ke službám Kubernetes a v levém podokně vyberte konfiguraci clusteru.
V části Ověřování a autorizace ověřte, že je vybraná možnost Microsoft Entra authentication with Kubernetes RBAC (Ověřování a autorizace).

Pomocí příkazu Azure CLI az aks show můžete ověřit. Nahraďte hodnotu myResourceGroup názvem skupiny prostředků hostující prostředek clusteru AKS a nahraďte myAKSCluster skutečným názvem vašeho clusteru AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster

Pokud je tato možnost povolená, zobrazí se ve výstupu hodnota .enableAzureRbacfalse

Vytvoření ukázkových skupin v Microsoft Entra ID

V tomto článku vytvoříme dvě role uživatelů, abychom ukázali, jak Řízení přístupu na základě role Kubernetes a Microsoft Entra ID řídí přístup k prostředkům clusteru. Používají se následující dvě ukázkové role:

Vývojář aplikací
- Uživatel s názvem aksdev , který je součástí skupiny appdev .
Technik spolehlivosti webu
- Uživatel s názvem akssre , který je součástí skupiny opssre .

V produkčních prostředích můžete použít existující uživatele a skupiny v rámci tenanta Microsoft Entra.

Nejprve pomocí příkazu získejte ID prostředku vašeho clusteru az aks show AKS. Pak přiřaďte ID prostředku k proměnné s názvem AKS_ID , aby bylo možné na něj odkazovat v jiných příkazech.
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
Vytvořte první ukázkovou skupinu v Microsoft Entra ID pro vývojáře aplikací pomocí az ad group create příkazu. Následující příklad vytvoří skupinu s názvem appdev:
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
Pomocí příkazu vytvořte přiřazení role Azure pro skupinu az role assignment create appdev. Toto přiřazení umožňuje všem členům skupiny používat kubectl interakci s clusterem AKS tím, že mu udělíte roli uživatele clusteru Azure Kubernetes Service.
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

Tip

Pokud se zobrazí například chyba Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., počkejte několik sekund, než se ID objektu skupiny Microsoft Entra rozšíří do adresáře, zkuste az role assignment create příkaz znovu.

Vytvořte druhou ukázkovou skupinu pro srEs s názvem opssre.

OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)

Vytvořte přiřazení role Azure, které členům skupiny udělí roli uživatele clusteru Azure Kubernetes Service.

az role assignment create \
  --assignee $OPSSRE_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID

Vytvoření ukázkových uživatelů v Microsoft Entra ID

Teď, když máme dvě ukázkové skupiny vytvořené v Microsoft Entra ID pro vývojáře aplikací a srEs, vytvoříme dva ukázkové uživatele. Pokud chcete otestovat integraci RBAC Kubernetes na konci článku, přihlaste se k clusteru AKS pomocí těchto účtů.

Nastavení hlavního názvu uživatele a hesla pro vývojáře aplikací

Nastavte hlavní název uživatele (UPN) a heslo pro vývojáře aplikací. Hlavní název uživatele (UPN) musí obsahovat ověřený název domény vašeho tenanta, například aksdev@contoso.com.

Následující příkaz vás vyzve k zadání hlavního názvu uživatele (UPN) a nastaví ho na AAD_DEV_UPN , aby ho bylo možné použít v pozdějším příkazu:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

Následující příkaz vás vyzve k zadání hesla a nastaví ho na AAD_DEV_PW pro pozdější použití:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Vytvoření uživatelských účtů

Pomocí příkazu vytvořte první uživatelský účet v Microsoft Entra ID az ad user create . Následující příklad vytvoří uživatele se zobrazovaným názvem AKS Dev a upN a zabezpečeným heslem pomocí hodnot v AAD_DEV_UPN a AAD_DEV_PW:

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

Přidejte uživatele do skupiny appdev vytvořené v předchozí části pomocí az ad group member add příkazu.

az ad group member add --group appdev --member-id $AKSDEV_ID

Nastavte hlavní název uživatele (UPN) a heslo pro rozhraní SRE. Hlavní název uživatele (UPN) musí obsahovat ověřený název domény vašeho tenanta, například akssre@contoso.com. Následující příkaz vás vyzve k zadání hlavního názvu uživatele (UPN) a nastaví ho na AAD_SRE_UPN pro pozdější použití:

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

Následující příkaz vás vyzve k zadání hesla a nastaví ho na AAD_SRE_PW pro pozdější použití:

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

Vytvořte druhý uživatelský účet. Následující příklad vytvoří uživatele se zobrazovaným názvem AKS SRE a upN a zabezpečeným heslem pomocí hodnot v AAD_SRE_UPN a AAD_SRE_PW:

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

Vytvoření prostředků clusteru AKS pro vývojáře aplikací

Vytvořili jsme skupiny Microsoft Entra, uživatele a přiřazení rolí Azure. Teď nakonfigurujeme cluster AKS tak, aby těmto různým skupinám umožňoval přístup ke konkrétním prostředkům.

Pomocí příkazu získejte přihlašovací údaje správce clusteru az aks get-credentials . V jedné z následujících částí získáte přihlašovací údaje k běžnému uživatelskému clusteru, abyste viděli tok ověřování Microsoft Entra v akci.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

Pomocí příkazu vytvořte obor názvů v clusteru kubectl create namespace AKS. Následující příklad vytvoří vývoj názvu oboru názvů:

kubectl create namespace dev

Poznámka:

V Kubernetes role definují oprávnění k udělení a vazby rolí je aplikují na požadované uživatele nebo skupiny. 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.

Pokud uživatel, pro který udělíte vazbu RBAC Kubernetes, je ve stejném tenantovi Microsoft Entra, přiřaďte oprávnění na základě userPrincipalName (UPN). Pokud je uživatel v jiném tenantovi Microsoft Entra, zadejte dotaz a použijte místo toho vlastnost objectId .

Vytvořte roli pro vývojový obor názvů, který uděluje úplná oprávnění k oboru názvů. Vprodukčních Vytvořte soubor s názvem role-dev-namespace.yaml a vložte následující manifest YAML:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

Vytvořte roli pomocí kubectl apply příkazu a zadejte název souboru manifestu YAML.

kubectl apply -f role-dev-namespace.yaml

Pomocí příkazu získejte ID prostředku pro skupinu az ad group show appdev. Tato skupina se v dalším kroku nastaví jako předmět vazby rolí.

az ad group show --group appdev --query id -o tsv

Vytvořte pro skupinu Appdev vazby rolí pro použití dříve vytvořené role pro přístup k oboru názvů. Vytvořte soubor s názvem rolebinding-dev-namespace.yaml a vložte následující manifest YAML. Na posledním řádku nahraďte groupObjectId výstupem ID objektu skupiny z předchozího příkazu.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

Tip

Pokud chcete vytvořit vazbu rolí pro jednoho uživatele, zadejte druh: User a replace groupObjectId hlavním názvem uživatele (UPN) v předchozí ukázce.

Pomocí příkazu vytvořte vazbu kubectl apply rolí a zadejte název souboru manifestu YAML:

kubectl apply -f rolebinding-dev-namespace.yaml

Vytvoření prostředků clusteru AKS pro srEs

Teď zopakujeme předchozí kroky a vytvoříme obor názvů, roli a vazbu rolí pro srEs.

Vytvořte obor názvů pro sre pomocí kubectl create namespace příkazu.

kubectl create namespace sre

Vytvořte soubor s názvem role-sre-namespace.yaml a vložte následující manifest YAML:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

Vytvořte roli pomocí kubectl apply příkazu a zadejte název souboru manifestu YAML.

kubectl apply -f role-sre-namespace.yaml

Pomocí příkazu az ad group show získejte ID prostředku pro skupinu opssre.

az ad group show --group opssre --query id -o tsv

Vytvořte pro skupinu opssre vazby rolí pro použití dříve vytvořené role pro přístup k oboru názvů. Vytvořte soubor s názvem rolebinding-sre-namespace.yaml a vložte následující manifest YAML. Na posledním řádku nahraďte groupObjectId výstupem ID objektu skupiny z předchozího příkazu.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-access
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  namespace: sre
  name: groupObjectId

Pomocí příkazu vytvořte vazbu kubectl apply rolí a zadejte název souboru manifestu YAML.

kubectl apply -f rolebinding-sre-namespace.yaml

Interakce s prostředky clusteru pomocí identit Microsoft Entra

Teď otestujeme, že očekávaná oprávnění fungují při vytváření a správě prostředků v clusteru AKS. V těchto příkladech naplánujeme a zobrazíme pody v přiřazeném oboru názvů uživatele a pokusíme se naplánovat a zobrazit pody mimo přiřazený obor názvů.

Pomocí příkazu resetujte kontext az aks get-credentials kubeconfig. V předchozí části nastavíte kontext pomocí přihlašovacích údajů správce clusteru. Uživatel s oprávněním správce obchází výzvy k přihlášení microsoftu Entra. Bez parametru --admin se použije kontext uživatele, který vyžaduje ověření všech požadavků pomocí ID Microsoft Entra.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

Pomocí příkazu v oboru názvů dev naplánujte základní pod kubectl run NGINX.

kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

Jako výzvu k přihlášení zadejte přihlašovací údaje pro vlastní appdev@contoso.com účet vytvořený na začátku článku. Po úspěšném přihlášení se token účtu do mezipaměti ukládá do mezipaměti pro budoucí kubectl příkazy. Server NGINX je úspěšně naplánován, jak je znázorněno v následujícím příkladu výstupu:

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

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

pod/nginx-dev created

kubectl get pods Pomocí příkazu můžete zobrazit pody v oboru názvů pro vývoj.

kubectl get pods --namespace dev

Ujistěte se, že je spuštěný pod NGINX. Výstup bude vypadat podobně jako následující výstup:

$ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

Vytvoření a zobrazení prostředků clusteru mimo přiřazený obor názvů

Zkuste zobrazit pody mimo vývoj oboru názvů. kubectl get pods Znovu použijte příkaz, tentokrát se zobrazí --all-namespaces.

kubectl get pods --all-namespaces

Členství uživatele ve skupině nemá roli Kubernetes, která tuto akci umožňuje, jak je znázorněno v následujícím příkladu výstupu:

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

Stejným způsobem se pokuste naplánovat pod v jiném oboru názvů, například v oboru názvů sre . Členství ve skupině uživatele není v souladu s rolí Kubernetes a vazbou rolí za účelem udělení těchto oprávnění, jak je znázorněno v následujícím příkladu výstupu:

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Otestování přístupu SRE k prostředkům clusteru AKS

Pokud chcete ověřit, že členství v naší skupině Microsoft Entra a Kubernetes RBAC správně fungují mezi různými uživateli a skupinami, zkuste předchozí příkazy, když jste přihlášeni jako uživatel opssre .

Pomocí příkazu, který vymaže dříve uložený ověřovací token pro uživatele aksdev, resetujte kontext az aks get-credentials kubeconfig.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

Pokuste se naplánovat a zobrazit pody v přiřazeného oboru názvů sre . Po zobrazení výzvy se přihlaste pomocí vlastních opssre@contoso.com přihlašovacích údajů vytvořených na začátku článku.

kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre

Jak je znázorněno v následujícím příkladu výstupu, můžete úspěšně vytvořit a zobrazit pody:

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

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

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

Zkuste zobrazit nebo naplánovat pody mimo přiřazený obor názvů SRE.

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

Tyto kubectl příkazy selžou, jak je znázorněno v následujícím příkladu výstupu. Členství ve skupinách uživatele a role Kubernetes a role RoleBindings neudělují oprávnění k vytváření nebo nadřízeným prostředkům v jiných oborech názvů.

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

Vyčištění prostředků

V tomto článku jste vytvořili prostředky v clusteru AKS a uživatelích a skupinách v Microsoft Entra ID. Pokud chcete vyčistit všechny prostředky, spusťte následující příkazy:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Další kroky

Další informace o zabezpečení clusterů Kubernetes najdete v tématu Možnosti přístupu a identity 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.