本文描述 Azure Kubernetes 服务（AKS）如何决定经过身份验证的调用方被允许执行哪些对 Kubernetes API 的操作。 它涵盖了 AKS 支持的两种授权模型，以及 Azure ABAC 条件的精细自定义资源控制。
有关 AKS 如何首先对调用方 进行身份验证 ，请参阅 群集身份验证概念。
有关所有四个 AKS 标识方案的方向，请参阅 AKS 的访问和标识选项。
授权 Kubernetes API
对调用方进行身份验证后，AKS 将评估调用方是否有权执行请求的操作。 AKS 支持两个 Kubernetes API 授权模型：
- Kubernetes 基于角色的访问控制（RBAC）。 Kubernetes 原生授权模型。 权限被定义为
Role和ClusterRole对象，并通过存储在每个群集中的RoleBinding和ClusterRoleBinding对象授予主体。 - Microsoft Entra ID 授权 AKS 授权 Webhook，将授权决策委托给Microsoft Entra ID。 权限作为对 Entra ID 标识的 Azure 角色分配授予，并且可以选择性地使用Azure ABAC 条件进行细化。
可以在同一群集上使用这两个模型。 建议Microsoft Entra ID 授权作为默认授权，并保留 Kubernetes RBAC 以获取精细的群集内权限。 本部分的其余部分说明了使用每个内容的原因和时间。
Kubernetes RBAC
Kubernetes RBAC 是上游 Kubernetes 授权模型。 你创建Role或ClusterRole对象，这些对象将谓词（例如get、list、create）授权给资源（例如pods、deployments），并使用RoleBinding或ClusterRoleBinding对象将其绑定到主体（用户、组或服务帐户）。 Kubernetes API 服务器的内置 RBAC 授权程序在每个请求上评估这些绑定。
如果需要，请使用 Kubernetes RBAC：
- 与工作负载一起以 Kubernetes 清单形式创建的细粒度、群集内、按命名空间划分的访问控制。
- GitOps 管理的授权，与应用程序配置位于同一事实依据中。
- 工作负荷用来调用 Kubernetes API 的群集内服务帐户的权限。
Kubernetes RBAC 权限的范围限定为单个群集。 若要向许多群集应用相同的策略，必须将清单应用到每个群集（通常通过 GitOps）。 使用 Microsoft Entra 用户和组作为 Kubernetes RoleBinding 和 ClusterRoleBinding 对象中的主题，以便用户身份依然来自于中心目录。
有关 Kubernetes RBAC 模型的背景信息，请参阅 上游 Kubernetes RBAC 文档。 有关在 AKS 中的设置，请参阅 将 Kubernetes RBAC 与 Microsoft Entra 集成。
Microsoft Kubernetes API 的 Entra ID 授权
使用 Entra ID 授权，AKS 部署授权 Webhook，该 Webhook 将 Kubernetes API 授权决策委托给Microsoft Entra ID。 当请求到达 API 服务器时，Webhook 会调用 Entra ID checkaccess API 来评估调用方 Azure 角色分配（以及任何附加的 ABAC 条件），并返回允许或拒绝决策。
与在每个群集上管理 Kubernetes RBAC 清单相比，Entra ID 授权提供以下优势：
- 单一身份平面。 相同的 Microsoft Entra 用户、组和服务主体不仅管理 Azure 资源的访问，还管理 Kubernetes API 的访问。 没有单独的用户目录可以预配或轮换。
- 分配一次，控制多个群集。 可以在 订阅、管理组或资源组范围内分配 Azure 角色。 资源组范围内的单个角色分配授予对该资源组中每个当前和将来的 AKS 群集的访问权限。 使用 Kubernetes RBAC 时，必须单独将清单应用到每个群集。
- 条件访问和特权身份管理 (PIM)。 群集访问会自动继承组织的现有 Entra ID 条件访问策略（例如多重身份验证或基于位置的限制），并且可以通过 PIM 实时提升。
- 集中式审核。 每个角色分配更改都会与其他 Azure 资源更改一起记录在 Azure 活动日志中，因此有一个用于群集访问治理的审核线索。
- 细粒度自定义资源约束。 使用 ABAC 条件，可以限制对特定自定义资源（CRD）组和类型的访问权限，而无需编写每个群集的 Kubernetes RBAC 清单。
AKS 为 Entra ID 授权提供以下内置角色：
| 角色 | Description |
|---|---|
| Azure Kubernetes 服务 RBAC 读取器 | 对命名空间中大多数对象的只读访问权限。 不允许查看角色、角色绑定或 Secrets。 |
| Azure Kubernetes 服务 RBAC 编写器 | 对命名空间中大多数对象的读/写访问权限。 不允许查看或修改角色或角色绑定。 |
| Azure Kubernetes 服务 RBAC 管理员 | 对命名空间中大多数资源的读/写访问权限，还可以在命名空间中创建角色和角色绑定。 |
| Azure Kubernetes 服务 RBAC 群集管理员 | 在所有命名空间中完全控制群集中的每个资源。 |
对于自定义权限模式，可以使用资源提供程序的数据操作创作面向特定 Kubernetes API 组 Microsoft.ContainerService 的自定义角色定义。 有关分步设置和自定义角色示例，请参阅 为 Kubernetes API 使用 Microsoft Entra ID 授权。
Comparison
| 能力 | Kubernetes RBAC | Entra ID 授权 |
|---|---|---|
| 身份源 | Kubernetes 用户、组、服务帐户 | Microsoft Entra ID 标识 |
| 单个资助的范围 | 一个群集 | 资源、资源组、订阅或管理组 |
| 多群集治理 | 将清单应用于每个群集（通常是 GitOps） | 较高范围内的一个角色分配可控制多个群集 |
| 条件访问/PIM | 不支持 | 继承自 Entra ID |
| 审核线索 | 群集审核日志 | Azure 活动日志 |
| 按 CRD 组或类型筛选访问 | 按每个 CRD Role 对象进行定义 |
在角色分配中使用 ABAC 条件属性 |
使用 ABAC 条件限制自定义资源访问
当您通过 Microsoft Entra ID 授权授予广泛读取访问权限，但希望限制被分配者可以读取的自定义资源（CRD）时，请将 Azure ABAC 条件附加到角色分配中。
如果没有 ABAC 条件，授予对自定义资源的读取权限必须使用通配符Microsoft.ContainerService/managedClusters/*/read，它涵盖每个范围内的群集上的所有 CRD。 使用 ABAC，可以附加一个条件用于限制对特定 CRD 组和类型的访问，例如允许templates.gatekeeper.sh而阻止kyverno.io，无需为每个群集编写 Kubernetes RBAC 清单。
对于 Kubernetes API 授权来说，可以按其 API 组和种类筛选对自定义资源的访问，并使用以下属性进行筛选：
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
有关 Azure ABAC 的背景信息，请参阅 什么是 Azure 角色分配条件？。 有关分步设置，请参阅 使用 ABAC 条件限制自定义资源访问。