AKS 的标识和访问管理注意事项

重要

弃用通知： 本文已弃用，不再更新。 为了确保仅显示最佳指南，本文将于 2026 年 5 月删除。

有关替代指南，请参阅 Azure 体系结构中心中的 Azure Kubernetes 服务 体系结构指南。

若要保存本指南，可以选择本页左下角的 Download a PDF，或从 GitHub。

本文提供有关使用Azure Kubernetes 服务 (AKS)时标识和访问管理的设计注意事项和建议。 标识和访问管理有多个方面，包括群集标识、工作负荷标识和作员访问。

设计注意事项

• 确定要使用的群集标识（托管标识或服务主体）。
• 决定如何对群集访问进行身份验证：基于客户端证书或通过 Microsoft Entra ID。
• 决定 多租户群集 以及如何在 Kubernetes 中设置基于角色的访问控制（RBAC）。
  • 选择隔离方法。 方法包括命名空间、网络策略（此仅适用于Azure CNI）、计算资源（节点池）和集群。
  • 确定每个应用程序团队的 Kubernetes RBAC 角色和计算分配，以便隔离。
  • 确定应用程序团队是否可以在其群集或其他群集中读取其他工作负荷。
• 确定 AKS 着陆区中自定义 Azure RBAC 角色的权限。
  • 确定站点可靠性工程（SRE）角色所需的权限，使该角色能够管理和排查整个群集问题。
  • 确定 SecOps 所需的权限。
  • 确定登陆区域所有者需要哪些权限。
  • 确定应用程序团队需要部署到群集中的权限。
• 确定是否需要工作负荷标识（Microsoft Entra Workload ID）。 可能需要它们用于Azure 密钥保管库集成和Azure Cosmos DB等服务。

设计建议

• 集群标识。
  • 为 AKS 群集使用自己的 托管标识 。
  • 为 AKS 登陆区域定义自定义Azure RBAC 角色，以简化群集托管标识所需权限的管理。
• 群集访问。
  • 使用 Kubernetes RBAC 与 Microsoft Entra ID 来限制特权，并最大限度地减少管理员权限。 这样做有助于保护配置和机密访问。
  • 使用 AKS 托管的Microsoft Entra集成，以便可以使用Microsoft Entra ID进行身份验证和操作员和开发人员访问。
• 在 Kubernetes 中定义所需的 RBAC 角色和角色绑定。
  • 使用 Kubernetes 角色和角色绑定为 Microsoft Entra 组提供站点可靠性工程（SRE）、SecOps 和开发人员的访问权限。
  • 请考虑使用 Azure RBAC for Kubernetes，以便跨 Azure 资源、AKS 和 Kubernetes 资源实现统一管理和访问控制。 启用 Azure Kubernetes 的 RBAC 时，无需单独管理 Kubernetes 的用户标识和凭据。 Microsoft Entra 主体将由 Azure RBAC 进行独家验证，而常规 Kubernetes 用户和服务账户将由 Kubernetes RBAC 独立验证。
• 根据需要给 SRE 及时授予完整的访问权限。
  • 使用 Microsoft Entra ID 中的 Privileged Identity Management 和 Azure 着陆区中的身份和访问管理。
• 使用 Microsoft Entra Workload ID for Kubernetes. 实现此联合身份验证时，开发人员可以使用本机 Kubernetes 服务帐户和联合身份验证访问由Microsoft Entra ID管理的资源，例如Azure和Microsoft Graph。