Řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě role Kubernetes a Azure Active Directory identit v Azure Kubernetes Service

Azure Kubernetes Service (AKS) je možné nakonfigurovat tak, aby Azure Active Directory ověřování uživatelů (AD). V této konfiguraci se přihlásíte ke clusteru AKS pomocí ověřovacího tokenu Azure AD. Po ověření můžete použít integrované řízení přístupu na základě role Kubernetes (Kubernetes RBAC) ke správě přístupu k oborům názvů a prostředkům clusteru na základě identity uživatele nebo členství ve skupinách.

Tento článek ukazuje, jak řídit přístup pomocí řízení přístupu na základě role Kubernetes v clusteru AKS na základě členství ve skupině Azure AD. V Azure AD se vytvoří příklady skupin a uživatelů a pak se v clusteru AKS vytvoří vazby rolí a rolí, aby se udělly příslušná oprávnění k vytváření a zobrazování prostředků.

Než začnete

Tento článek předpokládá, že máte existující cluster AKS povolený s integrací Azure AD. Pokud potřebujete cluster AKS, podívejte se na Azure Active Directory s AKS.

Potřebujete mít 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.

Vytvoření ukázkových skupin v Azure AD

V tomto článku vytvoříme dvě role uživatele, které můžete použít k zobrazení toho, jak Řízení přístupu na základě role v Kubernetes a Azure AD řídí přístup k prostředkům clusteru. Používají se následující dvě příklady rolí:

• Vývojář aplikací
  • Uživatel s názvem aksdev, který je součástí skupiny appdev.
• Technik pro spolehlivost webů
  • Uživatel s názvem akssre, který je součástí skupiny opssre.

V produkčních prostředích můžete použít stávající uživatele a skupiny v rámci tenanta Azure AD.

Nejprve pomocí příkazu az aks show získejte ID prostředku clusteru AKS. Přiřaďte ID prostředku proměnné s názvem AKS_ID, aby na něj bylo možné odkazovat v dalších příkazech.

AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)

Vytvořte první příklad skupiny v Azure AD pro vývojáře aplikací pomocí příkazu az ad group create. Následující příklad vytvoří skupinu s názvem appdev:

APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query objectId -o tsv)

Teď vytvořte přiřazení role Azure pro skupinu appdev pomocí příkazu az role assignment create. Toto přiřazení umožňuje, aby každý člen skupiny komunikoval s clusterem AKS tím, že jim udělí kubectl roli uživatele Azure Kubernetes Service clusteru.

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

Vytvořte druhou příkladovou skupinu– tuto skupinu pro SRE s názvem opssre:

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

Znovu vytvořte přiřazení role Azure, která členům skupiny udělí Azure Kubernetes Service role uživatele clusteru:

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 Azure AD

Díky dvěma příkladům skupin vytvořených v Azure AD pro naše vývojáře aplikací a SRE teď vytvoříme dva příklady uživatelů. Pokud chcete otestovat integraci RBAC s Kubernetes na konci článku, přihlaste se ke clusteru AKS pomocí těchto účtů.

Nastavte hlavní název uživatele (UPN) a heslo pro vývojáře aplikací. Následující příkaz vás vyzve k zadání zadat hlavní název uživatele (UPN) a nastaví ho na AAD_DEV_UPN pro použití v pozdějším příkazu (nezapomeňte, že příkazy v tomto článku jsou zadané do prostředí BASH). Hlavní název uživatele musí obsahovat ověřený název domény vašeho tenanta, například aksdev@contoso.com .

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 AAD_DEV_PW pro použití v pozdějším příkazu.

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

Vytvořte první uživatelský účet v Azure AD pomocí příkazu az ad user create.

Následující příklad vytvoří uživatele se zobrazovaným názvem AKS Dev a hlavní název uživatele (UPN) a zabezpečí heslo 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 objectId -o tsv)

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

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

Nastavte hlavní název uživatele (UPN) a heslo pro S SREs. Následující příkaz vás vyzve k zadání zadat hlavní název uživatele (UPN) a nastaví ho na AAD_SRE_UPN pro použití v pozdějším příkazu (nezapomeňte, že příkazy v tomto článku jsou zadané do prostředí BASH). Hlavní název uživatele musí obsahovat ověřený název domény vašeho tenanta, například akssre@contoso.com .

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 AAD_SRE_PW pro použití v pozdějším příkazu.

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 hlavní název uživatele (UPN) a zabezpečí heslo 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 objectId -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 aplikací

Teď se vytvoří skupiny a uživatelé Azure AD. Přiřazení rolí Azure byla vytvořena pro členy skupiny pro připojení ke clusteru AKS jako běžný uživatel. Teď nakonfigurujeme cluster AKS tak, aby těmto různým skupinám umožnil přístup ke konkrétním prostředkům.

Nejprve pomocí příkazu az aks get-credentials získejte přihlašovací údaje správce clusteru. V jedné z následujících částí získáte běžné přihlašovací údaje clusteru uživatelů, abyste viděli tok ověřování Azure AD v akci.

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

Vytvořte obor názvů v clusteru AKS pomocí příkazu kubectl create namespace. Následující příklad vytvoří obor názvů dev:

kubectl create namespace dev

V Kubernetes role definují oprávnění, která se mají udělit, a vazby rolí je aplikují na požadované uživatele nebo skupiny. Tato přiřazení je možné použít pro daný obor názvů nebo napříč celým clusterem. Další informace najdete v tématu Použití autorizace RBAC v Kubernetes.

Nejprve vytvořte roli pro obor názvů dev. Tato role uděluje úplná oprávnění k oboru názvů. V produkčních prostředích můžete pro různé uživatele nebo skupiny zadat podrobnější oprávnění.

Vytvořte soubor s názvem a role-dev-namespace.yaml 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í příkazu kubectl apply a zadejte název souboru manifestu YAML:

kubectl apply -f role-dev-namespace.yaml

Dále pomocí příkazu az ad group show získejte ID prostředku pro skupinu appdev. Tato skupina je v dalším kroku nastavená jako předmět vazby rolí.

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

Teď vytvořte vazby rolí pro skupinu appdev, která bude používat dříve vytvořenou roli pro přístup k oboru názvů. Vytvořte soubor s názvem a rolebinding-dev-namespace.yaml 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

Vytvořte vazby rolí pomocí příkazu kubectl apply a zadejte název souboru manifestu YAML:

kubectl apply -f rolebinding-dev-namespace.yaml

Vytvoření prostředků clusteru AKS pro S SRE

Teď zopakujte předchozí kroky a vytvořte obor názvů, roli a vazby rolí pro S SRE.

Nejprve vytvořte obor názvů pro SRE pomocí příkazu kubectl create namespace:

kubectl create namespace sre

Vytvořte soubor s názvem a role-sre-namespace.yaml 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í příkazu kubectl apply a zadejte název souboru manifestu YAML:

kubectl apply -f role-sre-namespace.yaml

Získejte ID prostředku pro skupinu opssre pomocí příkazu az ad group show:

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

Vytvořte vazby rolí pro skupinu opssre, která bude používat dříve vytvořenou roli pro přístup k oboru názvů. Vytvořte soubor s názvem a rolebinding-sre-namespace.yaml 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

Vytvořte vazby rolí pomocí příkazu kubectl apply a zadejte název souboru manifestu YAML:

kubectl apply -f rolebinding-sre-namespace.yaml

Interakce s prostředky clusteru s využitím identit Azure AD

Teď otestujte, ž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ánujte a zobrazte pody v oboru názvů přiřazeném uživatelem. Pak se pokusíte naplánovat a zobrazit pody mimo přiřazený obor názvů.

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

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

Naplánujte základní pod NGINX pomocí příkazu kubectl run v oboru názvů dev:

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

Po zobrazení výzvy k přihlášení zadejte přihlašovací údaje k vlastnímu appdev@contoso.com účtu vytvořenému na začátku článku. Po úspěšném přihlášení se token účtu 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

Teď pomocí příkazu kubectl get pods zobrazte pody v oboru názvů dev.

kubectl get pods --namespace dev

Jak je znázorněno v následujícím příkladu výstupu, pod NGINX je úspěšně spuštěný:

$ 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ů

Teď se pokuste zobrazit pody mimo obor názvů dev. Znovu použijte příkaz kubectl get pods, tentokrát se podívejte --all-namespaces takto:

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:

$ kubectl get pods --all-namespaces

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í uživatele ve skupinách neodpovídá rolím Kubernetes a vazbám rolí, aby bylo možné tato oprávnění udělit, 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"

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

Pokud chcete potvrdit, že naše členství ve skupině Azure AD a Kubernetes RBAC funguje správně mezi různými uživateli a skupinami, zkuste předchozí příkazy přihlášeni jako uživatel opssre .

Obnovte kontext kubeconfig pomocí příkazu AZ AKS Get-Credentials , který vymaže ověřovací token dříve uložených v mezipaměti pro uživatele aksdev :

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

Zkuste naplánovat a zobrazit lusky v přiřazeném oboru názvů SRE . Po zobrazení výzvy se přihlaste s vlastními opssre@contoso.com přihlašovacími údaji vytvořenými 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 lusky:

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

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

Nyní se pokuste zobrazit nebo naplánovat lusky 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živatelů a role Kubernetes a RoleBindings neudělují oprávnění k vytváření prostředků nebo správce 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 Azure AD. Pro vyčištění všech těchto prostředků 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 tom, jak zabezpečit clustery Kubernetes, najdete v tématu Možnosti přístupu a identit pro AKS).

Osvědčené postupy týkající se identit a řízení prostředků najdete v tématu osvědčené postupy pro ověřování a autorizaci v AKS.