Řízení přístupu k prostředkům clusteru pomocí řízení přístupu na základě role Kubernetes a identit Azure Active Directory ve službě Azure KubernetesControl access to cluster resources using Kubernetes role-based access control and Azure Active Directory identities in Azure Kubernetes Service

Službu Azure Kubernetes Service (AKS) je možné nakonfigurovat tak, aby pro ověřování uživatelů používala Azure Active Directory (AD).Azure Kubernetes Service (AKS) can be configured to use Azure Active Directory (AD) for user authentication. V této konfiguraci se přihlašujete ke clusteru AKS pomocí ověřovacího tokenu Azure AD.In this configuration, you sign in to an AKS cluster using an Azure AD authentication token. Můžete taky nakonfigurovat Kubernetes řízení přístupu na základě role (Kubernetes RBAC) a omezit tak přístup k prostředkům clusteru, které jsou založené na identitě nebo členství uživatele ve skupině.You can also configure Kubernetes role-based access control (Kubernetes RBAC) to limit access to cluster resources based a user's identity or group membership.

Tento článek popisuje, jak pomocí členství ve skupině Azure AD řídit přístup k oborům názvů a prostředkům clusteru pomocí Kubernetes RBAC v clusteru AKS.This article shows you how to use Azure AD group membership to control access to namespaces and cluster resources using Kubernetes RBAC in an AKS cluster. Ukázkové skupiny a uživatelé se vytvářejí ve službě Azure AD a pak se v clusteru AKS vytvoří role a RoleBindings, které jim udělí příslušná oprávnění k vytváření a zobrazování prostředků.Example groups and users are created in Azure AD, then Roles and RoleBindings are created in the AKS cluster to grant the appropriate permissions to create and view resources.

Než začneteBefore you begin

V tomto článku se předpokládá, že máte povolený existující cluster AKS s integrací služby Azure AD.This article assumes that you have an existing AKS cluster enabled with Azure AD integration. Pokud potřebujete cluster AKS, přečtěte si téma věnované integraci Azure Active Directory s AKS.If you need an AKS cluster, see Integrate Azure Active Directory with AKS.

Potřebujete nainstalovanou a nakonfigurovanou verzi Azure CLI 2.0.61 nebo novější.You need the Azure CLI version 2.0.61 or later installed and configured. Verzi zjistíte spuštěním příkazu az --version.Run az --version to find the version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.If you need to install or upgrade, see Install Azure CLI.

Vytvoření ukázkových skupin ve službě Azure ADCreate demo groups in Azure AD

V tomto článku vytvoříme dvě role uživatelů, které se dají použít k zobrazení, jak Kubernetes RBAC a Azure AD řídí přístup k prostředkům clusteru.In this article, let's create two user roles that can be used to show how Kubernetes RBAC and Azure AD control access to cluster resources. Používají se následující dvě příklady rolí:The following two example roles are used:

  • Vývojář aplikaceApplication developer
    • Uživatel s názvem aksdev , který je součástí skupiny appdev .A user named aksdev that is part of the appdev group.
  • Inženýr spolehlivosti sítěSite reliability engineer
    • Uživatel s názvem akssre , který je součástí skupiny opssre .A user named akssre that is part of the opssre group.

V produkčních prostředích můžete použít existující uživatele a skupiny v rámci tenanta Azure AD.In production environments, you can use existing users and groups within an Azure AD tenant.

Nejdřív Získejte ID prostředku clusteru AKS pomocí příkazu AZ AKS show .First, get the resource ID of your AKS cluster using the az aks show command. Přiřaďte ID prostředku k proměnné s názvem AKS_ID , aby na ně bylo možné odkazovat v dalších příkazech.Assign the resource ID to a variable named AKS_ID so that it can be referenced in additional commands.

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

Vytvořte první ukázkovou skupinu ve službě Azure AD pro vývojáře aplikací pomocí příkazu AZ AD Group Create .Create the first example group in Azure AD for the application developers using the az ad group create command. Následující příklad vytvoří skupinu s názvem appdev:The following example creates a group named 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 .Now, create an Azure role assignment for the appdev group using the az role assignment create command. Toto přiřazení umožňuje všem členům skupiny kubectl pracovat s clusterem AKS tím, že jim udělí roli uživatele clusteru služby Azure Kubernetes.This assignment lets any member of the group use kubectl to interact with an AKS cluster by granting them the Azure Kubernetes Service Cluster User Role.

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

Tip

Pokud se zobrazí chyba Principal 35bfec9328bd4d8d9b54dea6dac57b82 does not exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5. , třeba, počkejte několik sekund, než se ID objektu skupiny Azure AD rozšíří přes adresář, a potom zkuste az role assignment create příkaz zopakovat.If you receive an error such as Principal 35bfec9328bd4d8d9b54dea6dac57b82 does not exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., wait a few seconds for the Azure AD group object ID to propagate through the directory then try the az role assignment create command again.

Vytvořte druhou příklad skupiny, který pro SREs s názvem opssre:Create a second example group, this one for SREs named 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 a udělte členům skupiny roli uživatele clusteru služby Azure Kubernetes:Again, create an Azure role assignment to grant members of the group the Azure Kubernetes Service Cluster User Role:

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

Vytváření ukázkových uživatelů v Azure ADCreate demo users in Azure AD

Pomocí dvou ukázkových skupin vytvořených ve službě Azure AD pro naše vývojáře aplikací a SREs teď umožňuje vytvořit dva ukázkové uživatele.With two example groups created in Azure AD for our application developers and SREs, now lets create two example users. Pokud chcete otestovat integraci Kubernetes RBAC na konci článku, přihlaste se pomocí těchto účtů ke clusteru AKS.To test the Kubernetes RBAC integration at the end of the article, you sign in to the AKS cluster with these accounts.

Nastavte hlavní název uživatele (UPN) a heslo pro vývojáře aplikací.Set the user principal name (UPN) and password for the application developers. Následující příkaz vás vyzve k zadání hlavního názvu uživatele (UPN) a nastaví AAD_DEV_UPN pro použití v pozdějším příkazu (Nezapomeňte, že příkazy v tomto článku jsou zadány do prostředí bash).The following command prompts you for the UPN and sets it to AAD_DEV_UPN for use in a later command (remember that the commands in this article are entered into a BASH shell). Hlavní název uživatele (UPN) musí zahrnovat ověřený název domény vašeho tenanta, například aksdev@contoso.com .The UPN must include the verified domain name of your tenant, for example 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í AAD_DEV_PW pro použití v pozdějším příkazu.The following command prompts you for the password and sets it to AAD_DEV_PW for use in a later command.

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

Vytvořte první uživatelský účet ve službě Azure AD pomocí příkazu AZ AD User Create .Create the first user account in Azure AD using the az ad user create command.

Následující příklad vytvoří uživatele se zobrazovaným názvem AKS vývoj a hlavní název uživatele (UPN) a zabezpečené heslo pomocí hodnot v AAD_DEV_UPN a AAD_DEV_PW:The following example creates a user with the display name AKS Dev and the UPN and secure password using the values in AAD_DEV_UPN and 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)

Nyní přidejte uživatele do skupiny appdev vytvořené v předchozí části pomocí příkazu AZ AD Group member Add :Now add the user to the appdev group created in the previous section using the az ad group member add command:

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

Nastavte hlavní název uživatele (UPN) a heslo pro SREs.Set the UPN and password for SREs. Následující příkaz vás vyzve k zadání hlavního názvu uživatele (UPN) a nastaví AAD_SRE_UPN pro použití v pozdějším příkazu (Nezapomeňte, že příkazy v tomto článku jsou zadány do prostředí bash).The following command prompts you for the UPN and sets it to AAD_SRE_UPN for use in a later command (remember that the commands in this article are entered into a BASH shell). Hlavní název uživatele (UPN) musí zahrnovat ověřený název domény vašeho tenanta, například akssre@contoso.com .The UPN must include the verified domain name of your tenant, for example 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í AAD_SRE_PW pro použití v pozdějším příkazu.The following command prompts you for the password and sets it to AAD_SRE_PW for use in a later command.

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

Vytvořte druhý uživatelský účet.Create a second user account. Následující příklad vytvoří uživatele se zobrazovaným názvem AKS SRE a UPN a zabezpečené heslo pomocí hodnot v AAD_SRE_UPN a AAD_SRE_PW:The following example creates a user with the display name AKS SRE and the UPN and secure password using the values in AAD_SRE_UPN and 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 app vývojářiCreate the AKS cluster resources for app devs

Nyní se vytvoří skupiny a uživatelé služby Azure AD.The Azure AD groups and users are now created. Přiřazení rolí Azure se vytvořilo pro členy skupiny pro připojení ke clusteru AKS jako běžnému uživateli.Azure role assignments were created for the group members to connect to an AKS cluster as a regular user. Teď nakonfigurujeme cluster AKS, aby tyto různé skupiny umožňovaly přístup ke konkrétním prostředkům.Now, let's configure the AKS cluster to allow these different groups access to specific resources.

Nejprve pomocí příkazu AZ AKS Get-Credentials Získejte přihlašovací údaje Správce clusteru.First, get the cluster admin credentials using the az aks get-credentials command. V jedné z následujících částí získáte standardní přihlašovací údaje pro uživatele clusteru, abyste viděli tok ověřování Azure AD v akci.In one of the following sections, you get the regular user cluster credentials to see the Azure AD authentication flow in action.

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

Pomocí příkazu kubectl Create Namespace vytvořte v clusteru AKS obor názvů.Create a namespace in the AKS cluster using the kubectl create namespace command. Následující příklad vytvoří název oboru názvů dev:The following example creates a namespace name dev:

kubectl create namespace dev

V Kubernetes role definují oprávnění pro udělení a RoleBindings je použijí pro požadované uživatele nebo skupiny.In Kubernetes, Roles define the permissions to grant, and RoleBindings apply them to desired users or groups. Tato přiřazení lze použít na daný obor názvů nebo v celém clusteru.These assignments can be applied to a given namespace, or across the entire cluster. Další informace najdete v tématu použití autorizace KUBERNETES RBAC.For more information, see Using Kubernetes RBAC authorization.

Nejprve vytvořte roli pro obor názvů pro vývoj .First, create a Role for the dev namespace. Tato role uděluje úplný přístup k oboru názvů.This role grants full permissions to the namespace. V produkčních prostředích můžete zadat podrobnější oprávnění pro různé uživatele nebo skupiny.In production environments, you can specify more granular permissions for different users or groups.

Vytvořte soubor s názvem role-dev-namespace.yaml a vložte následující YAML manifest:Create a file named role-dev-namespace.yaml and paste the following YAML manifest:

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:Create the Role using the kubectl apply command and specify the filename of your YAML manifest:

kubectl apply -f role-dev-namespace.yaml

V dalším kroku Získejte ID prostředku pro skupinu appdev pomocí příkazu AZ AD Group show .Next, get the resource ID for the appdev group using the az ad group show command. Tato skupina se nastaví jako předmět RoleBinding v dalším kroku.This group is set as the subject of a RoleBinding in the next step.

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

Nyní vytvořte RoleBinding pro skupinu appdev a použijte dříve vytvořenou roli pro přístup k oboru názvů.Now, create a RoleBinding for the appdev group to use the previously created Role for namespace access. Vytvořte soubor s názvem rolebinding-dev-namespace.yaml a vložte následující manifest YAML.Create a file named rolebinding-dev-namespace.yaml and paste the following YAML manifest. Na posledním řádku nahraďte groupObjectId číslem ID objektu skupiny z předchozího příkazu:On the last line, replace groupObjectId with the group object ID output from the previous command:

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 RoleBinding pomocí příkazu kubectl Apply a zadejte název souboru manifestu YAML:Create the RoleBinding using the kubectl apply command and specify the filename of your YAML manifest:

kubectl apply -f rolebinding-dev-namespace.yaml

Vytvoření prostředků clusteru AKS pro SREsCreate the AKS cluster resources for SREs

Teď zopakováním předchozích kroků vytvořte obor názvů, roli a RoleBinding pro SREs.Now, repeat the previous steps to create a namespace, Role, and RoleBinding for the SREs.

Nejprve vytvořte obor názvů pro SRE pomocí příkazu kubectl Create Namespace :First, create a namespace for sre using the kubectl create namespace command:

kubectl create namespace sre

Vytvořte soubor s názvem role-sre-namespace.yaml a vložte následující YAML manifest:Create a file named role-sre-namespace.yaml and paste the following YAML manifest:

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:Create the Role using the kubectl apply command and specify the filename of your YAML manifest:

kubectl apply -f role-sre-namespace.yaml

ID prostředku pro skupinu opssre získáte pomocí příkazu AZ AD Group show :Get the resource ID for the opssre group using the az ad group show command:

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

Vytvořte RoleBinding pro skupinu opssre a použijte dříve vytvořenou roli pro přístup k oboru názvů.Create a RoleBinding for the opssre group to use the previously created Role for namespace access. Vytvořte soubor s názvem rolebinding-sre-namespace.yaml a vložte následující manifest YAML.Create a file named rolebinding-sre-namespace.yaml and paste the following YAML manifest. Na posledním řádku nahraďte groupObjectId číslem ID objektu skupiny z předchozího příkazu:On the last line, replace groupObjectId with the group object ID output from the previous command:

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 RoleBinding pomocí příkazu kubectl Apply a zadejte název souboru manifestu YAML:Create the RoleBinding using the kubectl apply command and specify the filename of your YAML manifest:

kubectl apply -f rolebinding-sre-namespace.yaml

Interakce s prostředky clusteru pomocí identit Azure ADInteract with cluster resources using Azure AD identities

Teď otestujeme, že při vytváření a správě prostředků v clusteru AKS budeme fungovat očekávaná oprávnění.Now, let's test the expected permissions work when you create and manage resources in an AKS cluster. V těchto příkladech můžete naplánovat a zobrazit lusky v oboru názvů přiřazené uživateli.In these examples, you schedule and view pods in the user's assigned namespace. Pak se pokusíte naplánovat a zobrazit lusky mimo přiřazený obor názvů.Then, you try to schedule and view pods outside of the assigned namespace.

Nejdříve obnovte kontext kubeconfig pomocí příkazu AZ AKS Get-Credentials .First, reset the kubeconfig context using the az aks get-credentials command. V předchozí části nastavíte kontext pomocí přihlašovacích údajů správce clusteru.In a previous section, you set the context using the cluster admin credentials. Uživatel s rolí správce obchází výzvy přihlášení ke službě Azure AD.The admin user bypasses Azure AD sign in prompts. Bez --admin parametru se použije kontext uživatele, který vyžaduje ověření všech požadavků pomocí Azure AD.Without the --admin parameter, the user context is applied that requires all requests to be authenticated using Azure AD.

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

Naplánujte základní NGINX pod pomocí příkazu kubectl Run v oboru názvů pro vývoj :Schedule a basic NGINX pod using the kubectl run command in the dev namespace:

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

Jako přihlašovací výzvu zadejte přihlašovací údaje k vlastnímu appdev@contoso.com účtu vytvořené na začátku článku.As the sign in prompt, enter the credentials for your own appdev@contoso.com account created at the start of the article. Po úspěšném přihlášení se token účtu ukládá do mezipaměti pro budoucí kubectl příkazy.Once you are successfully signed in, the account token is cached for future kubectl commands. NGINX je úspěšně naplánován, jak je znázorněno v následujícím příkladu výstupu:The NGINX is successfully schedule, as shown in the following example output:

$ 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

Nyní použijte příkaz kubectl Get lusks k zobrazení lusků v oboru názvů pro vývoj .Now use the kubectl get pods command to view pods in the dev namespace.

kubectl get pods --namespace dev

Jak je znázorněno v následujícím příkladu výstupu, je NGINX pod úspěšně spuštěn:As shown in the following example output, the NGINX pod is successfully Running:

$ kubectl get pods --namespace dev

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

Vytváření a zobrazování prostředků clusteru mimo přiřazený obor názvůCreate and view cluster resources outside of the assigned namespace

Nyní se pokuste zobrazit lusky mimo obor názvů pro vývoj .Now try to view pods outside of the dev namespace. Znovu použijte příkaz kubectl získat lusky , tentokrát se podívejte na --all-namespaces následující:Use the kubectl get pods command again, this time to see --all-namespaces as follows:

kubectl get pods --all-namespaces

Členství ve skupině uživatele nemá roli Kubernetes, která umožňuje tuto akci, jak je znázorněno v následujícím příkladu výstupu:The user's group membership does not have a Kubernetes Role that allows this action, as shown in the following example output:

$ 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ů, jako je například obor názvů SRE .In the same way, try to schedule a pod in different namespace, such as the sre namespace. Členství ve skupině uživatele není zarovnáno s rolí Kubernetes a RoleBinding pro udělení těchto oprávnění, jak je znázorněno v následujícím příkladu výstupu:The user's group membership does not align with a Kubernetes Role and RoleBinding to grant these permissions, as shown in the following example output:

$ 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 AKSTest the SRE access to the AKS cluster resources

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 .To confirm that our Azure AD group membership and Kubernetes RBAC work correctly between different users and groups, try the previous commands when signed in as the opssre user.

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 :Reset the kubeconfig context using the az aks get-credentials command that clears the previously cached authentication token for the aksdev user:

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 .Try to schedule and view pods in the assigned sre namespace. 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:When prompted, sign in with your own opssre@contoso.com credentials created at the start of the article:

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:As shown in the following example output, you can successfully create and view the pods:

$ 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:Now, try to view or schedule pods outside of assigned SRE namespace:

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.These kubectl commands fail, as shown in the following example output. Č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ů:The user's group membership and Kubernetes Role and RoleBindings don't grant permissions to create or manager resources in other namespaces:

$ 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ůClean up resources

V tomto článku jste vytvořili prostředky v clusteru AKS a uživatelích a skupinách v Azure AD.In this article, you created resources in the AKS cluster and users and groups in Azure AD. Pro vyčištění všech těchto prostředků spusťte následující příkazy:To clean up all these resources, run the following commands:

# 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ší krokyNext steps

Další informace o tom, jak zabezpečit clustery Kubernetes, najdete v tématu Možnosti přístupu a identit pro AKS).For more information about how to secure Kubernetes clusters, see Access and identity options for 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.For best practices on identity and resource control, see Best practices for authentication and authorization in AKS.