可将 Azure Kubernetes 服务 (AKS) 配置为使用 Microsoft Entra ID 进行用户身份验证。 在此配置中,你使用 Microsoft Entra 身份验证令牌登录到 AKS 群集。 进行身份验证后,可以使用内置的 Kubernetes 基于角色的访问控制(RBAC)根据用户的标识或组成员身份管理对命名空间和群集资源的访问权限。
本文将向您介绍如何操作:
根据 Microsoft Entra 组成员身份,使用 AKS 集群中的 Kubernetes RBAC 来控制访问权限。
在 Microsoft Entra ID 中创建示例组和用户。
在 AKS 群集中创建角色和 RoleBindings,授予相应的权限,例如创建和查看资源。
先决条件
你拥有一个已启用 Microsoft Entra 集成的现有 AKS 群集。 如果需要具有此配置的 AKS 群集,请参阅将 Microsoft Entra ID 与 AKS 集成。
默认情况下,在 AKS 群集创建期间启用 Kubernetes RBAC。 若要使用 Microsoft Entra 集成和 Kubernetes RBAC 升级现有群集,请参阅 在现有 AKS 群集上启用Microsoft Entra 集成。
确保安装并配置了 Azure CLI 2.0.61 或更高版本。 若要查找版本,请运行
az --version。 若要安装或升级,请参阅安装 Azure CLI。
使用 Azure 门户或 Azure CLI 验证是否启用了 Microsoft Entra 与 Kubernetes RBAC 的集成。
- Azure 门户
- Azure CLI
若要使用 Azure 门户验证,请执行以下操作:
- 登录到 Azure 门户 并导航到 AKS 群集资源。
- 在服务菜单中的“设置”下,选择“安全配置”。
- 在“身份验证和授权”部分下,验证是否选择了“使用 Kubernetes RBAC 的 Microsoft Entra 身份验证”选项。
如果计划使用 Terraform 为本文配置 Kubernetes RBAC,则还需要:
- 已安装 Terraform 1.6.0 或更高版本。
- kubectl 已安装并配置为连接到 AKS 群集。
- 在 AKS 群集范围内创建Azure角色分配的权限,以及管理群集上的 Kubernetes 资源的权限。
- 两个现有的 Microsoft Entra 组,以及(可选)两个用于验证访问权限的现有 Microsoft Entra 测试用户。 如果还没有这些资源,请在Microsoft Entra ID中完成创建组,并在Microsoft Entra ID中创建用户,然后再继续操作。 但是,请跳过该部分中的
az role assignment create命令,因为本文中的 Terraform 配置会为你创建角色分配。
注释
如果你还没有可用于测试的、已启用 Microsoft Entra 集成和 Kubernetes RBAC 的 AKS 群集,本文的 Terraform 示例包含一个 prequisite 配置,可为你创建这样一个群集。 有关详细信息,请参阅 使用 Terraform 部署必备 AKS 群集。
在 Microsoft Entra ID 中创建组
本部分介绍如何创建两个用户角色,以显示 Kubernetes RBAC 和 Microsoft Entra ID 控制访问群集资源的方式。 以下两个示例角色包括:
应用开发人员
- 属于 appdev 组的用户名为 aksdev。
站点可靠性工程师 (SRE)
- 名为 akssre 的用户是 opssre 组的一员。
在生产环境中,可以使用 Microsoft Entra 租户中的现有用户和组。
首先,使用
az aks show命令获取 AKS 群集的资源 ID。 然后,将该资源 ID 分配到名为 AKS_ID 的变量,以便可以在其他命令中引用它。AKS_ID=$(az aks show \ --resource-group myResourceGroup \ --name myAKSCluster \ --query id -o tsv)使用
az ad group create命令在 Microsoft Entra ID 中为应用程序开发人员创建第一个示例组。 以下示例创建名为 appdev 的组:APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)使用 命令为 appdev 组创建 Azure 角色分配。 此分配可为该组的任何成员授予“Azure Kubernetes 服务群集用户”角色,因此可让其使用
kubectl与 AKS 群集交互。az role assignment create \ --assignee $APPDEV_ID \ --role "Azure Kubernetes Service Cluster User Role" \ --scope $AKS_IDImportant
指定的角色名称必须与 Azure 角色定义名称完全匹配,包括大写和间距。
小窍门
如果出现类似于
Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.的错误,请等待几秒,让 Microsoft Entra 组对象 ID 传播到整个目录,然后重试az role assignment create命令。跳过此命令。 使用 Terraform 部署 Kubernetes RBAC 中的 Terraform 配置会为你创建此角色分配。
在 Microsoft Entra ID 中创建用户
为应用程序开发人员和 SRE 创建示例Microsoft Entra ID 组后,下一步是创建两个相应的用户帐户。 这些用户用于登录到 AKS 群集,并验证本文后面所述的 Kubernetes RBAC 集成。
在开始之前,必须为应用程序开发人员设置用户主体名称(UPN)和密码。 UPN 必须包含租户的已验证域名。 例如,应用程序开发者用户aksdev@contoso.com。 为了识别或设置租户中的已验证域名,请参阅 管理 Microsoft Entra ID 中的自定义域名。
以下命令提示你输入 UPN 并将其设置为“AAD_DEV_UPN”,以便在以后的命令中使用:
echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN
以下命令提示你输入密码并将其设置为“AAD_DEV_PW”,以便在以后的命令中使用:
echo "Please enter the secure password for application developers: " && read AAD_DEV_PW
创建用户帐户
使用
az ad user create命令在 Microsoft Entra ID 中创建第一个用户帐户。 以下示例使用AAD_DEV_UPN和AAD_DEV_PW中的值创建显示名称 AKS Dev、UPN 和安全密码的用户:AKSDEV_ID=$(az ad user create \ --display-name "AKS Dev" \ --user-principal-name $AAD_DEV_UPN \ --password $AAD_DEV_PW \ --query id -o tsv)使用命令将用户添加到在上一节中创建的
az ad group member add组。az ad group member add --group appdev --member-id $AKSDEV_ID
创建 AKS 群集资源
我们创建了 Microsoft Entra 组、用户和 Azure 角色分配。 现在,将 AKS 群集配置为允许这些不同的组访问特定资源。
使用
az aks get-credentials命令获取群集管理员凭据。 在以下某个部分中,你将获得普通用户群集凭据,以查看 Microsoft Entra 身份验证流的运作方式。az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin使用
kubectl create namespace命令在 AKS 群集中创建一个命名空间。 以下示例创建名为 dev 的命名空间:kubectl create namespace dev注释
在 Kubernetes 中,角色定义要授予的权限,角色绑定将这些权限应用到所需的用户或组。 这些分配可应用于特定命名空间或整个群集。 有关详细信息,请参阅使用 Kubernetes RBAC 授权。
如果授予 Kubernetes RBAC 绑定的用户位于同一Microsoft Entra 租户中,请根据 UPN 分配权限。 如果该用户位于不同的 Microsoft Entra 租户中,请查询并改用 objectId 属性。
为“dev”命名空间创建一个角色,授予对该命名空间的完全访问权限。 在生产环境中,可为不同的用户或组指定更精细的权限。 创建名为
role-dev-namespace.yaml的文件并粘贴以下 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: ["*"]使用
kubectl apply命令创建 Role,并指定 YAML 清单的文件名。kubectl apply -f role-dev-namespace.yaml使用 命令获取
az ad group show组的资源 ID。 此组将在下一步骤中设置为角色绑定的主体。az ad group show --group appdev --query id -o tsv为 appdev 组创建 RoleBinding,以使用前面创建的 Role 来访问命名空间。 创建名为
rolebinding-dev-namespace.yaml的文件并粘贴以下 YAML 清单。 在最后一行中,将“groupObjectId”替换为上一命令输出的组对象 ID。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 # Replace the placeholder below with the group's objectId (GUID) name: groupObjectId小窍门
如果要为单个用户创建 RoleBinding,请指定 类型:用户 并将 groupObjectId 替换为上一示例中的 UPN。
使用
kubectl apply命令创建角色绑定,并指定 YAML 清单的文件名:kubectl apply -f rolebinding-dev-namespace.yaml
查看 Terraform 代码
注释
本文的示例代码位于 Azure Terraform GitHub 存储库中。 你可以查看包含当前和以前 Terraform 版本的测试结果的日志文件。
此示例使用两个 Terraform 配置,每个配置都位于其自己的目录中,其状态为:
- 该
prequisite配置会创建一个资源组和一个启用了 Microsoft Entra 集成及 Kubernetes RBAC 的 AKS 群集,该存储库自身的端到端测试会使用该群集,针对真实群集验证场景配置。 如果你已经有一个满足本文先决条件的 AKS 群集,请跳过此配置,改为在场景配置中使用你自己的资源组名称、群集名称和 Microsoft Entra 组对象 ID。 - 示例根目录中的方案配置将Azure Kubernetes 服务群集用户角色分配给群集范围内的 appdev 和 opssre 组。 它还会创建 dev 和 sre 两个 Kubernetes 命名空间,以及具有命名空间作用域的 Roles 和 RoleBindings,仅允许每个组访问各自的命名空间。
Terraform 使用Azure CLI登录上下文进行身份验证。 继续之前,请确保已使用 az login 登录,并已使用 az account set --subscription <subscription-id> 选择正确的订阅。
使用 Terraform 部署必备 AKS 群集
注释
此阶段是可选的。 仅当你还没有一个可用于测试的 AKS 群集(该群集已启用 Microsoft Entra 集成和 Kubernetes RBAC,并已禁用 Kubernetes 授权的 Azure RBAC)时,才完成此操作。
创建命名
prequisite目录并将其设为当前目录。创建名为
versions.tf的文件并插入下列代码:
terraform {
required_version = ">= 1.6.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
provider "azurerm" {
features {
resource_group {
prevent_deletion_if_contains_resources = false
}
}
}
- 创建一个名为
variables.tf文件的文件,并添加以下代码:
variable "location" {
type = string
default = "eastus"
description = "Location of the resources."
}
variable "node_count" {
type = number
default = 1
description = "Number of nodes in the default node pool of the AKS cluster."
}
- 创建一个名为
main.tf文件的文件,并添加以下代码:
data "azurerm_client_config" "current" {}
resource "random_string" "suffix" {
length = 6
special = false
upper = false
}
resource "azurerm_resource_group" "rg" {
location = var.location
name = "rg-101-aks-entra-k8s-rbac-${random_string.suffix.result}"
}
resource "azurerm_kubernetes_cluster" "aks" {
location = azurerm_resource_group.rg.location
name = "aks-101-entra-k8s-rbac-${random_string.suffix.result}"
resource_group_name = azurerm_resource_group.rg.name
dns_prefix = "aks-${random_string.suffix.result}"
# Kubernetes RBAC is required by the example, Azure RBAC for Kubernetes
# Authorization must stay disabled.
role_based_access_control_enabled = true
default_node_pool {
name = "agentpool"
node_count = var.node_count
vm_size = "Standard_D2s_v3"
}
identity {
type = "SystemAssigned"
}
azure_active_directory_role_based_access_control {
azure_rbac_enabled = false
tenant_id = data.azurerm_client_config.current.tenant_id
}
}
- 创建名为
outputs.tf的文件并插入下列代码:
output "resource_group_name" {
description = "Name of the resource group that contains the AKS cluster."
value = azurerm_resource_group.rg.name
}
output "aks_cluster_name" {
description = "Name of the AKS cluster with Microsoft Entra integration and Kubernetes RBAC enabled."
value = azurerm_kubernetes_cluster.aks.name
}
output "appdev_group_object_id" {
description = "Object ID of the existing test principal used for developer access."
value = data.azurerm_client_config.current.object_id
}
output "opssre_group_object_id" {
description = "Object ID of the existing test principal used for SRE access."
value = azurerm_kubernetes_cluster.aks.identity[0].principal_id
}
初始化、格式化和验证配置。
terraform init terraform fmt terraform validate查看并应用配置。
terraform plan -out main.tfplan terraform apply main.tfplan获取输出结果。 在下一部分中,将这些值用作方案配置的输入。
terraform output -raw resource_group_name terraform output -raw aks_cluster_name terraform output -raw appdev_group_object_id terraform output -raw opssre_group_object_id
Important
来自 prequisite 配置的 appdev_group_object_id 和 opssre_group_object_id 输出是测试主体 ID,而不是真实的 Microsoft Entra 组。 它们会解析为你当前登录的 Azure CLI 帐户的对象 ID 以及 AKS 集群的托管标识主体 ID,它们存在的唯一目的是让该存储库的自动化测试能够验证场景配置是否已成功应用。 若要测试本文中所述的 Microsoft Entra 组和用户体验,请改用 在 Microsoft Entra ID 中创建组中的组对象 ID。
使用 Terraform 部署 Kubernetes RBAC
创建新目录,与
prequisite当前目录分开并使其成为当前目录。 此配置有自己的 Terraform 状态,且不管理也不依赖于prequisite配置的状态。创建一个名为
main.tf文件的文件,并添加以下代码:
terraform {
required_version = ">= 1.6.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
kubernetes = {
source = "hashicorp/kubernetes"
version = "~> 2.30"
}
}
}
provider "azurerm" {
features {}
}
variable "resource_group_name" {
type = string
description = "Name of the resource group that contains the existing AKS cluster."
}
variable "aks_cluster_name" {
type = string
description = "Name of the existing AKS cluster with Microsoft Entra integration and Kubernetes RBAC enabled."
}
variable "appdev_group_object_id" {
type = string
description = "Object ID of an existing Microsoft Entra group used for developer access to the dev namespace."
}
variable "opssre_group_object_id" {
type = string
description = "Object ID of an existing Microsoft Entra group used for SRE access to the sre namespace."
}
data "azurerm_kubernetes_cluster" "aks" {
name = var.aks_cluster_name
resource_group_name = var.resource_group_name
}
provider "kubernetes" {
host = data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].host
client_certificate = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].client_certificate)
client_key = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].client_key)
cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].cluster_ca_certificate)
}
resource "azurerm_role_assignment" "appdev_cluster_user" {
scope = data.azurerm_kubernetes_cluster.aks.id
role_definition_name = "Azure Kubernetes Service Cluster User Role"
principal_id = var.appdev_group_object_id
}
resource "azurerm_role_assignment" "opssre_cluster_user" {
scope = data.azurerm_kubernetes_cluster.aks.id
role_definition_name = "Azure Kubernetes Service Cluster User Role"
principal_id = var.opssre_group_object_id
}
resource "kubernetes_namespace" "dev" {
metadata {
name = "dev"
}
}
resource "kubernetes_namespace" "sre" {
metadata {
name = "sre"
}
}
resource "kubernetes_role" "dev_full_access" {
metadata {
name = "dev-user-full-access"
namespace = kubernetes_namespace.dev.metadata[0].name
}
rule {
api_groups = ["", "extensions", "apps"]
resources = ["*"]
verbs = ["*"]
}
rule {
api_groups = ["batch"]
resources = ["jobs", "cronjobs"]
verbs = ["*"]
}
}
resource "kubernetes_role" "sre_full_access" {
metadata {
name = "sre-user-full-access"
namespace = kubernetes_namespace.sre.metadata[0].name
}
rule {
api_groups = ["", "extensions", "apps"]
resources = ["*"]
verbs = ["*"]
}
rule {
api_groups = ["batch"]
resources = ["jobs", "cronjobs"]
verbs = ["*"]
}
}
resource "kubernetes_role_binding" "dev_user_access" {
metadata {
name = "dev-user-access"
namespace = kubernetes_namespace.dev.metadata[0].name
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = kubernetes_role.dev_full_access.metadata[0].name
}
subject {
kind = "Group"
name = var.appdev_group_object_id
api_group = "rbac.authorization.k8s.io"
}
}
resource "kubernetes_role_binding" "sre_user_access" {
metadata {
name = "sre-user-access"
namespace = kubernetes_namespace.sre.metadata[0].name
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = kubernetes_role.sre_full_access.metadata[0].name
}
subject {
kind = "Group"
name = var.opssre_group_object_id
api_group = "rbac.authorization.k8s.io"
}
}
创建一个名为
terraform.tfvars的文件,并提供要配置的 AKS 群集的资源组名称和群集名称,以及 appdev 和 opssre 组的对象 ID。resource_group_name = "<resource-group-name>" aks_cluster_name = "<aks-cluster-name>" appdev_group_object_id = "<appdev-group-object-id>" opssre_group_object_id = "<opssre-group-object-id>"初始化、格式化和验证配置。
terraform init terraform fmt terraform validate查看并应用配置。
terraform plan -out main.tfplan terraform apply main.tfplan该配置会为这两个组、dev 和 sre Kubernetes 命名空间,以及命名空间作用域的 Role 和 RoleBinding 创建 Azure 角色分配;这些 Role 和 RoleBinding 分别向 appdev 组授予对 dev 的访问权限,并向 opssre 组授予对 sre 的访问权限。
验证命名空间访问
使用
az aks get-credentials命令获取群集管理员凭据。az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin使用
kubectl get namespaces命令验证这两个命名空间是否存在。kubectl get namespaces输出显示 开发 命名空间和 sre 命名空间,以及为群集创建的默认命名空间。
若要测试 appdev 和 opssre 组是否只能访问其分配的命名空间,请继续访问具有Microsoft Entra标识的 AKS 群集资源。
清理 Terraform 资源
Important
在进行 prequisite 配置之前,销毁场景配置。 场景配置的 Kubernetes 提供程序需要 AKS 集群仍然存在,以便 Terraform 可以删除其创建的命名空间、Role 和 RoleBinding。
从方案配置目录中,删除它创建的 Azure 角色分配、命名空间、Role 和 RoleBinding。
terraform destroy如果仅部署
prequisiteAKS 群集以测试此示例,并且不再需要它,请在方案配置完成销毁其资源后将其从prequisite目录中删除。terraform destroy
使用 Microsoft Entra 标识访问 AKS 群集资源
现在,测试在 AKS 群集中创建和管理资源时的预期权限是否有效。 在这些示例中,你将在用户指定的命名空间中调度和查看 Pod,并尝试在指定的命名空间之外调度和查看 Pod。
使用 命令重置
az aks get-credentials上下文。 在上一部分,你已使用群集管理员凭据设置了上下文。 管理员用户会绕过 Microsoft Entra 登录提示。 如果没有--admin参数,应用的用户上下文将要求使用 Microsoft Entra ID 对所有请求进行身份验证。az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing在
kubectl run命名空间中,使用命令调度一个基本的 NGINX Pod:kubectl run nginx-dev --image=mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine --namespace dev在登录提示符下输入 appdev 组帐户的凭据(输入 自己的 凭据)。 成功登录后,帐户令牌将会缓存,供将来的
kubectl命令使用。 NGINX 已成功调度,如以下示例输出所示:$ kubectl run nginx-dev --image=mcr.azk8s.cn/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命令查看dev命名空间中的Pod:kubectl get pods --namespace dev确保 NGINX pod 的状态为“正在运行”。 输出如下所示:
$ kubectl get pods --namespace dev NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
测试对 AKS 群集资源的 SRE 访问
若要确认Microsoft Entra 组成员身份和 Kubernetes RBAC 在不同用户和组之间正常工作,请在以 akssre 用户身份登录时尝试上述命令。
使用 命令重置
az aks get-credentials用户的 kubeconfig 上下文,该命令将清除先前缓存的身份验证令牌。az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing在分配的 SRE 命名空间中计划和查看 Pod。 出现提示时,请使用 opssre 组帐户凭据登录(输入 自己的 凭据)。
kubectl run nginx-sre --image=mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine --namespace sre kubectl get pods --namespace sre如以下示例输出所示,您可以成功创建和查看 pod。
$ kubectl run nginx-sre --image=mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine --namespace sre若要登录,请使用 Web 浏览器打开页面 https://microsoft.com/devicelogin 并输入代码BM4RHP3FD进行身份验证。
pod/nginx-sre created $ kubectl get pods --namespace sre NAME READY STATUS RESTARTS AGE nginx-sre 1/1 Running 0尝试查看或调度在分配的 SRE 命名空间之外的 Pod。
kubectl get pods --all-namespaces kubectl run nginx-sre --image=mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine --namespace dev如以下示例输出中所示,这些
kubectl命令失败: 用户的组成员身份和 Kubernetes Role 与 RoleBinding 无法授予在其他命名空间中创建或管理资源的权限。$ 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.azk8s.cn/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"
在分配的命名空间外部创建和查看群集资源
查看 dev 命名空间外部的 Pod。
kubectl get pods使用以下命令:--all-namespaces
kubectl get pods --all-namespaces
该用户的组成员身份不具备允许此操作的 Kubernetes Role,如以下示例输出所示:
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope
同样,可以在不同的命名空间(例如 SRE 命名空间)中调度 Pod。 该用户的组成员身份与 Kubernetes Role 和 RoleBinding 不相符,无法授予这些权限,如以下示例输出所示:
$ kubectl run nginx-dev --image=mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine --namespace sre
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"
清理群集资源
若要清理所有资源,请运行以下命令。
获取管理员 kubeconfig 上下文并删除 dev 和 sre 命名空间。 此操作还会删除 Pod、角色和角色绑定。
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
kubectl delete namespace dev
kubectl delete namespace sre
如果您使用 Terraform 创建了 dev 和 sre 命名空间、Roles 和 RoleBindings,请参阅 清理 Terraform 资源,而不要运行 kubectl delete namespace。
删除 aksdev 和 akssre 的Microsoft Entra ID用户帐户。
az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID
删除 appdev 和 opssre 的Microsoft Entra ID组。 此操作还会删除任何剩余Azure角色分配。
az ad group delete --group appdev
az ad group delete --group opssre
后续步骤
有关如何保护 Kubernetes 群集的详细信息,请参阅 AKS 的访问和标识选项。
有关标识和资源控制的最佳做法,请参阅 AKS 中的身份验证和授权概念。