使用 Azure 基于角色的访问控制进行 Kubernetes 授权

当你利用 Microsoft Entra ID 和 AKS 之间的集成身份验证时,可以将 Microsoft Entra 用户、组或服务主体用作 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 中的主体。 使用此功能,你无需分别管理 Kubernetes 的用户标识和凭据。 但是,你仍需分别设置和管理 Azure RBAC 和 Kubernetes RBAC。

本文介绍如何使用 Azure RBAC 进行 Kubernetes 授权,该授权允许跨 Azure 资源、AKS 和 Kubernetes 资源进行统一管理和访问控制。 有关详细信息,请参阅用于 Kubernetes 授权的 Azure RBAC

开始之前

  • 需要安装和配置 Azure CLI 版本 2.24.0 或更高版本。 运行 az --version 即可查找版本。 如果需要进行安装或升级,请参阅安装 Azure CLI
  • 你需要版本不低于 kubectl1.18.3
  • 需要先在群集上启用托管 Microsoft Entra 集成,然后才能添加用于 Kubernetes 授权的 Azure RBAC。 如果需要启用托管的 Microsoft Entra 集成,请参阅在 AKS 中使用 Microsoft Entra ID
  • 目前,如果你有 CRD 并且要创建自定义角色定义,则涵盖 CRD 的唯一方法是使用 Microsoft.ContainerService/managedClusters/*/read。 对于剩余的对象,你可以使用特定的 API 组,例如 Microsoft.ContainerService/apps/deployments/read
  • 新角色分配最多可能需要 5 分钟才能传播并由授权服务器更新。
  • Azure RBAC 用于 Kubernetes 授权要求为身份验证配置的 Microsoft Entra 租户与包含 AKS 群集的订阅的租户相同。

新建具有托管 Microsoft Entra 集成并使用 Azure RBAC 进行 Kubernetes 授权的 AKS 群集

使用 az group create 命令创建 Azure 资源组。

az group create --name myResourceGroup --location chinaeast2

使用 az aks create 命令创建具有托管 Microsoft Entra 集成并使用 Azure RBAC 进行 Kubernetes 授权的 AKS 群集。

az aks create -g myResourceGroup -n myManagedCluster --enable-aad --enable-azure-rbac

输出将与以下示例输出类似:

"AADProfile": {
    "adminGroupObjectIds": null,
    "clientAppId": null,
    "enableAzureRbac": true,
    "managed": true,
    "serverAppId": null,
    "serverAppSecret": null,
    "tenantId": "****-****-****-****-****"
}

在现有 AKS 群集上启用 Azure RBAC

使用带 enable-azure-rbac 标志的 az aks update 命令,将用于 Kubernetes 授权的 Azure RBAC 添加到现有 AKS 群集中。

az aks update -g myResourceGroup -n myAKSCluster --enable-azure-rbac

从 AKS 群集禁用用于 Kubernetes 授权的 Azure RBAC

使用带 disable-azure-rbac 标志的 az aks update 命令,从现有 AKS 群集中删除用于 Kubernetes 授权的 Azure RBAC。

az aks update -g myResourceGroup -n myAKSCluster --disable-azure-rbac

创建角色分配以便用户访问群集

AKS 提供以下内置角色:

角色 说明
Azure Kubernetes 服务 RBAC 读取者 允许进行只读访问并查看命名空间中的大多数对象。 不允许查看角色或角色绑定。 此角色不允许查看 Secrets,因为读取机密的内容就可以访问命名空间中的 ServiceAccount 凭据,这样就会允许以命名空间中任何 ServiceAccount 的身份进行 API 访问(一种特权提升形式)。
Azure Kubernetes 服务 RBAC 写入者 允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是,此角色允许以命名空间中任何 ServiceAccount 的身份访问 Secrets 和运行 Pod,因此可用于获取命名空间中任何 ServiceAccount 的 API 访问级别。
Azure Kubernetes 服务 RBAC 管理员 允许要在命名空间内授予的管理员访问权限。 允许对命名空间(或群集范围)中的大多数资源进行读/写访问,包括在命名空间内创建角色和角色绑定。 此角色不允许对资源配额或命名空间本身进行写入访问。
Azure Kubernetes 服务 RBAC 群集管理员 允许超级用户访问权限(对任何资源执行任何操作)。 它提供对群集中每个资源和所有命名空间的完全控制。

整个 AKS 群集为作用域的角色分配可以在 Azure 门户中群集资源的“访问控制 (IAM)”边栏选项卡上执行,也可以通过使用以下 Azure CLI 命令执行:

使用 az aks show 命令获取 AKS 资源 ID。

AKS_ID=$(az aks show -g myResourceGroup -n myManagedCluster --query id -o tsv)

使用 az role assignment create 命令创建角色分配。 <AAD-ENTITY-ID> 可以是服务主体的用户名或客户端 ID。

az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

注意

可以使用 az role assignment create 命令创建 Azure Kubernetes 服务 RBAC 读者Azure Kubernetes 服务 RBAC 写入者角色分配,范围限定为群集中的特定命名空间,并将范围设置为所需的命名空间。

az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>

注意

在 Azure 门户中,创建限定在所需命名空间范围内的角色分配后,将无法看到在某个范围内命名空间的“角色分配”。 可以使用 az role assignment list 命令找到它,也可以列出分配有角色的用户或组的角色分配

az role assignment list --scope $AKS_ID/namespaces/<namespace-name>

创建自定义角色定义

以下自定义角色定义示例仅允许用户读取部署,不允许任何其他操作。 有关可能操作的完整列表,请参阅 Microsoft.ContainerService 操作

若要创建自己的自定义角色定义,请复制以下文件,将 <YOUR SUBSCRIPTION ID> 替换为自己的订阅 ID,然后将其另存为 deploy-view.json

{
    "Name": "AKS Deployment Reader",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.ContainerService/managedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<YOUR SUBSCRIPTION ID>"
    ]
}

使用 az role definition create 命令创建角色定义,并将 --role-definition 设置为在上一步中创建的 deploy-view.json 文件。

az role definition create --role-definition @deploy-view.json 

使用 az role assignment create 命令将角色定义分配给用户或其他标识。

az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

通过 kubectl 使用 Azure RBAC 进行 Kubernetes 授权

请确保你具有 Azure Kubernetes 服务群集用户这一内置角色,然后使用 az aks get-credentials 命令获取 AKS 群集的 kubeconfig。

az aks get-credentials -g myResourceGroup -n myManagedCluster

现在你可以使用 kubectl 管理群集。 例如,可以使用 kubectl get nodes 列出群集中的节点。 首次运行它时,需要登录,如以下示例所示:

kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/deviceloginchina and enter the code AAAAAAAAA to authenticate.

NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-93451573-vmss000000   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000001   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000002   Ready    agent   3h6m   v1.15.11

通过 kubelogin 使用 Azure RBAC 进行 Kubernetes 授权

AKS 创建了 kubelogin 插件,以帮助取消阻止其他方案,例如非交互式登录、旧 kubectl 版本或在不登录到新群集的情况下跨多个群集利用 SSO。

可以通过运行以下命令来使用 kubelogin 插件:

export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig

kubectl 类似,需要在首次运行时登录,如以下示例所示:

kubectl get nodes
To sign in, use a web browser to open the page https://microsoft.com/deviceloginchina and enter the code AAAAAAAAA to authenticate.

NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-93451573-vmss000000   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000001   Ready    agent   3h6m   v1.15.11
aks-nodepool1-93451573-vmss000002   Ready    agent   3h6m   v1.15.11

清理资源

删除角色分配

# List role assignments
az role assignment list --scope $AKS_ID --query [].id -o tsv

# Delete role assignments
az role assignment delete --ids <LIST OF ASSIGNMENT IDS>

删除角色定义

az role definition delete -n "AKS Deployment Reader"

删除资源组和 AKS 群集

az group delete -n myResourceGroup

后续步骤

若要详细了解 AKS 身份验证、授权、Kubernetes RBAC 和 Azure RBAC,请参阅: