本文介绍了 Amazon Elastic Kubernetes 服务 (Amazon EKS) 和 Azure Kubernetes 服务 (AKS) 如何为 Kubernetes 工作负载提供标识以访问云平台服务。 有关 Amazon Web Services (AWS) 身份验证和访问控制管理 (IAM) 和 Microsoft Entra ID 的详细比较，请参阅：
本指南介绍了 AKS 群集、内置服务和加载项如何使用托管标识来访问负载均衡器和托管磁盘等 Azure 资源。 本文还演示了如何使用 Microsoft Entra 工作负载 ID，以便 AKS 工作负载无需连接字符串、访问密钥或用户凭据即可访问 Azure 资源。
注意
本文是系列文章之一，可帮助熟悉 Amazon EKS 的专业人员了解 Azure Kubernetes 服务 (AKS)。
Amazon EKS 标识和访问管理
Amazon EKS 有两个本地选项可以从 Kubernetes Pod 调用 AWS 服务：服务帐户的 IAM 角色和 Amazon EKS 服务相关角色。
服务帐户的 IAM 角色将 IAM 角色与 Kubernetes 服务帐户相关联。 此服务帐户为使用服务帐户的任何 Pod 中的容器提供 AWS 权限。 服务帐户的 IAM 角色具有以下优势：
最低特权：您不需要为了让节点上的 Pod 调用 AWS API 而为节点 IAM 角色提供扩展权限。 可以将 IAM 权限限定为服务帐户，并且只有使用该服务帐户的 Pod 有权访问这些权限。 此功能还消除了第三方解决方案（如
kiam或kube2iam）的需求。凭证隔离：容器只能检索与其所属服务帐户关联的 IAM 角色的凭证。 容器永远不得访问属于另一个 Pod 的另一个容器的凭据。
可审核性：Amazon CloudTrail 提供访问和事件日志记录，以帮助确保追溯审核。
Amazon EKS 服务链接角色 是直接链接到 Amazon EKS 的唯一 IAM 角色。 服务链接角色由 Amazon EKS 预定义，并包括代表该角色调用其他 AWS 服务所需的所有权限。 对于 Amazon EKS 节点 IAM 角色，Amazon EKS 节点 kubelet 守护程序代表节点调用 AWS API。 节点从 IAM 实例配置文件和相关策略中获取这些 API 调用的权限。
AKS 群集托管标识
AKS 群集需有一个标识才能访问负载均衡器和托管磁盘等 Azure 资源。 此标识可以是托管标识或服务主体。 默认情况下，创建 AKS 群集会自动创建系统分配的托管标识。 Azure 平台负责管理标识，因此你无需预配或轮换任何机密。 有关 Microsoft Entra 托管标识的详细信息，请参阅 Azure 资源的托管标识。
AKS 不会自动创建服务主体，如果要使用服务主体，你必须自行创建。 服务主体最终会过期，你必须更新它以保持群集正常工作。 管理服务主体会增加复杂性，因此使用托管标识会更方便。
托管标识本质上是简化管理的服务主体的包装器。 相同的权限要求同时适用于服务主体和托管标识。 托管标识使用基于证书的身份验证。 每个托管标识的凭据的有效期为 90 天，在 45 天后轮换。
AKS 使用系统分配和用户分配的托管标识类型，这些标识是不可变的。 当你使用节点资源组之外的资源创建或使用 AKS 虚拟网络、附加的 Azure 磁盘、静态 IP 地址、路由表或用户分配的 kubelet 标识时，Azure CLI 会自动添加角色分配。
如果使用其他方法创建 AKS 群集（例如，Bicep 模板、Azure 资源管理器模板或 Terraform 模块），则需要使用群集托管标识的主体 ID 来执行一次角色分配。 AKS 群集标识在虚拟网络中的子网上必须至少具有网络参与者角色。 要定义自定义角色，而不是使用内置的网络参与者角色，则需要以下权限：
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/read
当群集标识需要访问现有资源时，例如当你将 AKS 群集部署到现有虚拟网络时，你应该使用用户分配的托管标识。 如果使用系统分配的控制平面标识，资源提供程序在创建群集之前无法获取其主体 ID，因此无法在群集预配之前创建适当的角色分配。
托管标识摘要
AKS 将以下用户分配的托管标识用于内置服务和加载项。
| 标识 | 名称 | 使用案例 | 默认权限 | 自带标识 |
|---|---|---|---|---|
| 控制面板 | AKS 群集名称 | 管理群集资源，包括入口负载均衡器和 AKS 管理的公共 IP、群集自动缩放器以及 Azure 磁盘和 Azure 文件 CSI 驱动程序 | 节点资源组的参与者角色 | 支持 |
| Kubelet | AKS Cluster Name-agentpool | 使用 Azure 容器注册表进行身份验证 | NA（对于 kubernetes v1.15+） | 支持 |
| 加载项 | HTTPApplicationRouting | 管理所需的网络资源 | 节点资源组的读取者角色，DNS 区域的参与者角色 | 否 |
| 加载项 | 入口应用程序网关 | 管理所需的网络资源 | 节点资源组的参与者角色 | 否 |
| 加载项 | omsagent | 将 AKS 指标发送到 Azure Monitor | “监视指标发布者”角色 | 否 |
| 加载项 | Virtual-Node (ACIConnector) | 管理 Azure 容器实例所需的网络资源 | 节点资源组的参与者角色 | 否 |
有关详细信息，请参阅在 Azure Kubernetes 服务中使用托管标识。
适用于 Kubernetes 的 Microsoft Entra 工作负载 ID
Kubernetes 工作负荷需要 Microsoft Entra 应用程序凭据才能访问 Microsoft Entra 保护的资源，例如 Azure Key Vault 和 Microsoft Graph。 开发人员面临的一个共同挑战是管理密码和凭据，以确保解决方案的不同组件之间的通信安全。
有了适用于 Kubernetes 的 Microsoft Entra 工作负载 ID，无需管理凭据即可访问 Azure Cosmos DB、Azure Key Vault 或 Azure Blob 存储等云服务。 AKS 托管的工作负载应用程序可以使用 Microsoft Entra 工作负载 ID 通过 Microsoft Entra 安全令牌（而不是连接字符串、用户名和密码或主键等显式凭据）来访问 Azure 托管服务。
如下图所示， Kubernetes 群集成为安全令牌颁发者，将令牌颁发给 Kubernetes 服务帐户。 可以将这些令牌配置为在 Microsoft Entra 应用程序中受信任。 然后可以使用 Azure 标识 SDK 或 Microsoft 身份验证库 (MSAL) 将令牌交换为 Microsoft Entra 访问令牌。
kubelet代理将服务帐户令牌投射到可配置文件路径中的工作负载。- Kubernetes 工作负载将计划的签名服务帐户令牌发送到 Microsoft Entra ID 并请求访问令牌。
- Microsoft Entra ID 使用 OIDC 发现文档检查对用户定义的托管标识或注册应用程序的信任并验证传入令牌。
- Microsoft Entra ID 颁发安全访问令牌。
- Kubernetes 工作负载使用 Microsoft Entra 访问令牌访问 Azure 资源。
目前，适用于 Kubernetes 的 Microsoft Entra 工作负载 ID 联合身份验证仅支持 Microsoft Entra 应用程序，但同一模型可能会扩展到 Azure 托管标识。
有关 Microsoft Entra 工作负载 ID 的详细信息、自动化和文档，请参阅：
- Azure 工作负载标识开源项目。
- 工作负荷联合身份验证
- Kubernetes 的 Microsoft Entra 工作负载 ID 联合身份验证
- 外部 OIDC 标识提供者的 Microsoft Entra 工作负载 ID 联合身份验证
- 最低 Microsoft Entra 工作负载 ID 联合身份验证
- Microsoft Entra 工作负载 ID
- Microsoft Entra 工作负载 ID 快速入门
- 在.NET Standard 应用程序中使用适用于具有用户分配托管标识的 Kubernetes 的 Microsoft Entra Workload ID
示例工作负荷
示例工作负载在 AKS群集上运行前端和后端服务。 工作负载服务使用 Microsoft Entra 工作负载 ID 通过 Microsoft Entra 安全令牌访问以下 Azure 服务：
- Azure Key Vault
- Azure Cosmos DB
- Azure 存储帐户
- Azure 服务总线命名空间
先决条件
- 在启用 OIDC 颁发者的情况下设置 AKS 群集。
- 安装可变许可 Webhook。
- 为工作负载创建 Kubernetes 服务帐户。
- 创建 Microsoft Entra 应用程序，如快速入门中所示。
- 将具有正确权限的角色分配给所需的 Microsoft Entra 注册应用程序。
- 在 Microsoft Entra 应用程序与服务帐户颁发者和使用者之间建立联合标识凭据。
- 将工作负载应用程序部署到 AKS 群集。
Microsoft Entra 工作负载 ID 消息流
AKS 应用程序从 AKS 群集的 OIDC 颁发者处获取其服务帐户的安全令牌。 Microsoft Entra 工作负载 ID 将安全令牌与 Microsoft Entra ID 颁发的安全令牌交换，应用程序使用 Microsoft Entra ID 颁发的安全令牌来访问 Azure 资源。
下图显示了前端和后端应用程序如何获取 Microsoft Entra 安全令牌以使用 Azure 平台即服务 (PaaS) 服务。
下载此体系结构的 Visio 文件。
- Kubernetes 根据 Pod 或部署规范，在节点上调度 Pod 时向 Pod 发出令牌。
- Pod 将 OIDC 颁发的令牌发送到 Microsoft Entra ID，以请求特定
appId和资源的 Microsoft Entra 令牌。 - Microsoft Entra ID 检查应用程序上的信任并验证传入令牌。
- Microsoft Entra ID 颁发安全令牌：
{sub: appId, aud: requested-audience}。 - Pod 使用 Microsoft Entra 令牌访问目标 Azure 资源。
在 Kubernetes 群集中使用 Microsoft Entra 工作负载 ID 端到端：
- 将 AKS 群集配置为颁发令牌并发布 OIDC 发现文档以允许验证这些令牌。
- 将 Microsoft Entra 应用程序配置为信任 Kubernetes 令牌。
- 开发人员将部署配置为使用 Kubernetes 服务帐户来获取 Kubernetes 令牌。
- Microsoft Entra 工作负载 ID 将 Kubernetes 令牌交换为 Microsoft Entra 令牌。
- AKS 群集工作负载使用 Microsoft Entra 令牌访问受保护的资源，例如 Microsoft Graph。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Paolo Salvatori | 首席服务工程师
- Martin Gjoshevski | 高级服务工程师
其他参与者：
- Laura Nicolas | 高级软件工程师
- Chad Kittel | 首席软件工程师
- Ed Price | 高级内容项目经理
- Theano Petersen | 技术文档撰写人
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- 适用于 Amazon EKS 专业人员的 AKS
- Kubernetes 监视和日志记录
- 保护对 Kubernetes 的网络访问
- Kubernetes 群集的存储选项
- Kubernetes 的成本管理
- Kubernetes 节点和节点池管理
- 群集治理
- AWS 的 Microsoft Entra 标识管理和访问权限管理