Sdílet prostřednictvím


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

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.

Ověření pomocí webu Azure Portal:

  1. Přihlaste se k webu Azure Portal a přejděte k prostředku clusteru AKS.
  2. V nabídce služby v části Nastavení vyberte Konfigurace clusteru.
  3. 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).

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.

  1. 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)
    
  2. 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)
    
  3. 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.

  1. 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)
    
  2. 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ů

  1. 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)
  1. 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
  1. 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
  1. 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
  1. 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.

  1. 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
  1. 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 .

  1. 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: ["*"]
  1. Vytvořte roli pomocí kubectl apply příkazu a zadejte název souboru manifestu YAML.
kubectl apply -f role-dev-namespace.yaml
  1. 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
  1. 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.

  1. 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.

  1. Vytvořte obor názvů pro sre pomocí kubectl create namespace příkazu.
kubectl create namespace sre
  1. 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: ["*"]
  1. Vytvořte roli pomocí kubectl apply příkazu a zadejte název souboru manifestu YAML.
kubectl apply -f role-sre-namespace.yaml
  1. 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
  1. 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
  1. 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ů.

  1. 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
  1. 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
  1. 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
  1. kubectl get pods Pomocí příkazu můžete zobrazit pody v oboru názvů pro vývoj.
kubectl get pods --namespace dev
  1. 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 .

  1. 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
  1. 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
  1. 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