Kubernetes 工作负载身份与访问权限

本文介绍 Amazon Elastic Kubernetes 服务 （EKS） 和 Azure Kubernetes 服务 （AKS） 如何为 Kubernetes 工作负载提供标识来访问云平台服务。 有关 Amazon Web Services （AWS） 标识和访问管理（IAM）和Microsoft Entra ID 的详细比较，请参阅以下资源：

• AWS 的 Microsoft Entra 标识管理和访问权限管理
• 将 AWS IAM 概念映射到类似的 Azure 概念

本指南介绍了 AKS 群集、内置服务和加载项如何使用 托管标识 来访问 Azure 资源，例如负载均衡器和托管磁盘。 它还演示如何使用 Microsoft Entra 工作负荷 ID ，以便 AKS 工作负载可以访问 Azure 资源，而无需连接字符串、访问密钥或用户凭据。

注释

本文是一系列文章的一部分，可帮助熟悉 Amazon EKS 的专业人员了解 Azure Kubernetes 服务（AKS）。

Amazon EKS 标识和访问管理

Amazon EKS 提供原生选项来管理 Kubernetes Pod 中的标识和访问。 这些选项包括服务帐户的 IAM 角色和 Amazon EKS 服务链接角色。

服务帐户的 IAM 角色

可以将 IAM 角色与 Kubernetes 服务帐户相关联。 此关联为使用服务帐户的任何 Pod 中的容器提供 AWS 权限。 服务帐户的 IAM 角色具有以下优势：

• 最低特权： 可以将特定的 IAM 权限分配给服务帐户，这可确保只有使用该服务帐户的 Pod 有权访问这些权限。 此配置无需为节点上的所有 Pod 授予节点 IAM 角色的扩展权限。 此方法提供增强的安全性和精细控制，消除了合作伙伴解决方案（如 kube2iam）的需求。 有关详细信息，请参阅 服务帐户的 IAM 角色。

• 凭据隔离： Pod 中的每个容器只能检索与其各自的服务帐户关联的 IAM 角色的凭据。 此隔离可确保容器无法访问属于不同 Pod 中另一个容器的凭据。

• 可审核性： Amazon EKS 使用 AWS CloudTrail 提供访问和事件日志记录，这有助于追溯审核和合规性。

有关详细信息，请参阅 服务帐户的 IAM 角色。

Amazon EKS 服务链接角色

Amazon EKS 服务链接角色是直接链接到 Amazon EKS 的唯一 IAM 角色。 这些预定义角色包括代表关联角色调用 AWS 服务所需的权限。 Amazon EKS 的主要服务链接角色是 Amazon EKS 节点 IAM 角色。

Amazon EKS 节点 kubelet 守护程序使用 Amazon EKS 节点 IAM 角色代表节点对 AWS 服务进行 API 调用。 IAM 实例配置文件和关联的策略为这些 API 调用提供权限。 此设置简化了 EKS 群集中节点的 IAM 角色的管理。

有关详细信息，请参阅 Amazon EKS 的服务关联角色使用指南。

有关标识和访问管理的详细信息

除了服务帐户的 IAM 角色和 Amazon EKS 服务链接角色外，在 Amazon EKS 中管理标识和访问的其他重要方面还包括：

• Amazon EKS RBAC 授权：Amazon EKS 支持基于角色的访问控制（RBAC）。 使用此功能为群集中的 Kubernetes 资源定义精细权限。

• AWS IAM：IAM 为 AWS 服务（包括 EKS）提供了全面的标识管理解决方案。 使用 IAM 创建和管理用户、组和角色，以控制对 EKS 资源的访问。

• Amazon EKS 安全组：使用 Amazon EKS 将安全组规则应用到群集中运行的 pod 上。 使用此功能可以控制入站和出站流量。

有关详细信息，请参阅 什么是 Amazon EKS？。

AKS 群集托管标识

AKS 群集需要 Microsoft Entra 标识 才能访问 Azure 资源，例如负载均衡器和托管磁盘。 建议使用 Azure 资源的托管标识来授权从 AKS 群集访问其他 Azure 服务。

托管标识类型

开发人员通常难以管理机密、凭据、证书和密钥，以帮助保护服务之间的通信。 使用托管标识消除了管理这些凭据的必要性。 可以使用托管标识对 AKS 群集进行身份验证，而无需管理凭据或将其包含在代码中。 将 Azure RBAC 角色分配给标识，以向 Azure 中的特定资源授予标识权限。

两种类型的托管身份包括：

• 系统分配。 可以使用某些 Azure 资源（例如虚拟机）直接在资源上启用托管标识。 启用系统分配的托管标识时：

  • Microsoft Entra ID 会为该标识创建一个特殊类型的服务主体。 服务主体与该 Azure 资源的生命周期相关联。 删除 Azure 资源后，Azure 会自动删除服务主体。

  • 只有该 Azure 资源才能使用该标识向 Microsoft Entra ID 请求令牌。

  • 授权托管标识对一个或多个服务的访问权限。

  • 系统分配的服务主体的名称与为其创建的 Azure 资源的名称相同。

• 用户分配。 也可以将托管标识创建为独立的 Azure 资源。 可以 创建用户分配的托管标识 并将其分配给一个或多个 Azure 资源。 启用用户分配的托管标识时：

  • Microsoft Entra ID 会为该标识创建一个特殊类型的服务主体。 该服务主体与使用它的资源是分开管理的。

  • 多个资源可以使用它。

  • 授权托管标识对一个或多个服务的访问权限。

可以使用任一类型的托管标识来授权从 AKS 群集访问 Azure 资源。

有关详细信息，请参阅托管标识类型。

AKS 中的托管标识

可以将以下类型的托管标识用于 AKS 群集：

• 系统分配的托管标识与单个 Azure 资源（例如 AKS 群集）相关联。 它仅适用于群集的生命周期。

• 用户分配的托管标识是独立的 Azure 资源，可用于授权从 AKS 群集访问其他 Azure 服务。 它与群集分开保留，多个 Azure 资源可以使用它。

• 预先创建的 kubelet 托管标识是一种可选的用户分配标识，kubelet 可用于访问 Azure 中的其他资源。 如果未为 kubelet 指定用户分配的托管标识，AKS 会在节点资源组中创建用户分配的 kubelet 标识。

为 AKS 群集配置托管标识

部署 AKS 群集时，系统分配的托管标识会自动创建。 还可以使用用户分配的托管标识来创建群集。 群集使用托管标识向 Microsoft Entra ID 请求令牌。 令牌授权访问 Azure 中运行的其他资源。

在为托管标识分配 Azure RBAC 角色时，可以授予群集访问特定资源的权限。 例如，可以为托管标识分配一个 Azure RBAC 角色，该角色允许它访问 Azure 密钥保管库中的机密。 使用此方法可以轻松授权访问群集，而无需管理凭据。

AKS 中托管标识的优点和管理

在 AKS 中使用托管标识时，无需预配或轮换机密。 Azure 将管理标识的凭据。 因此，你可以授权从应用程序访问，而无需管理任何额外的机密。

如果已有使用托管标识的 AKS 群集，则可以将群集更新为不同类型的托管标识。 但是，当控制平面组件切换到新标识时，此更新可能会引入延迟。 此过程可能需要几小时的时间。 在此期间，控制平面组件将继续使用旧标识，直到其令牌过期。

AKS 中的托管标识类型

AKS 使用不同类型的托管标识来启用各种内置服务和加载项。

托管标识	用例	默认权限
控制平面（系统分配）	AKS 控制平面组件使用此标识来管理群集资源。 这些资源包括入口负载均衡器、AKS 托管的公共 IP 地址、群集自动缩放程序以及 Azure 磁盘、文件和 Blob CSI 驱动程序。	节点资源组的贡献者角色
Kubelet（用户分配）	使用 Azure 容器注册表进行身份验证。	N/A（适用于 Kubernetes 版本 1.15 及更高版本）
附加身份（AzureNPM、AzureCNI 网络监控、Azure 策略和 Calico）	这些加载项不需要标识。	非适用
应用路由	管理 Azure DNS 和 Azure Key Vault 证书。	适用于 Key Vault 的 Key Vault 机密用户角色、适用于 DNS 区域的 DNS 区域参与者角色、适用于专用 DNS 区域的专用 DNS 区域参与者角色
入口应用程序网关	管理所需的网络资源。	节点资源组的贡献者角色
Operations Management Suite (OMS) 代理	将 AKS 指标发送到 Azure Monitor。	“监视指标发布者”角色
虚拟节点（Azure 容器实例连接器）	管理容器实例所需的网络资源。	节点资源组的贡献者角色
成本分析	收集成本分配数据。	非适用
工作负荷标识（工作负荷 ID）	使应用程序能够使用工作负荷 ID 安全地访问云资源。	非适用

有关详细信息，请参阅在 AKS 中使用托管标识。

Kubernetes 的工作负荷 ID

工作负荷 ID 与 Kubernetes 集成，使 AKS 群集部署的工作负载能够访问 Microsoft Entra 保护的资源，例如 Key Vault 和 Microsoft Graph。 工作负荷 ID 使用 Kubernetes 本机功能与外部身份提供程序联合。 有关详细信息，请参阅将工作负荷 ID 与 AKS 配合使用。

若要使用工作负荷 ID，请在 Kubernetes 中配置服务帐户。 Pod 使用此服务帐户安全地对 Azure 资源进行身份验证和访问。 工作负荷 ID 可与 Azure 标识服务客户端库或 Microsoft 身份验证库集合很好地配合使用。 必须在 Microsoft Entra ID 中注册应用程序，以便管理标识的权限和访问控制。

若要在 Kubernetes 群集中充分利用工作负荷 ID，请将 AKS 群集配置为颁发令牌，并发布 OpenID Connect （OIDC） 发现文档进行令牌验证。 有关详细信息，请参阅 在 AKS 上创建 OIDC 提供程序。

您还需要配置 Microsoft Entra 应用程序以信任 Kubernetes 令牌。 然后，开发人员可以将部署配置为使用 Kubernetes 服务帐户来获取令牌。 工作负荷 ID 会将令牌交换为 Microsoft Entra 令牌。 AKS 群集工作负载可以使用这些Microsoft Entra 令牌安全地访问 Azure 中的受保护资源。

下图显示了 Kubernetes 群集如何成为向 Kubernetes 服务帐户颁发令牌的安全令牌颁发者。 可以将这些令牌配置为在 Microsoft Entra 应用程序中受信任。 然后，可以通过 Azure 标识服务 SDK 或 Microsoft 身份验证库交换这些令牌，以获取 Microsoft Entra 访问令牌。

序列图显示了五个组件之间的交互：Kubelet、Kubernetes 工作负载、Microsoft Entra ID、OpenID 发现文档和 Azure 资源。 交互编号为 1 到 5。 箭头指示通信方向。 从 Kubelet 到 Kubernetes 工作负荷的箭头标记为 1。 从 Kubernetes 工作负载到Microsoft Entra ID 的箭头标记为 2。 从 Microsoft Entra ID 到 OpenID 发现文档的箭头标记为 3。 从 Microsoft Entra ID 返回 Kubernetes 工作负荷的箭头标记为 4。 从 Kubernetes 工作负荷到 Azure 资源的箭头标记为 5。

1. kubelet 代理将服务帐户令牌投射到工作负载的可配置文件路径中。

2. Kubernetes 工作负载将计划的签名服务帐户令牌发送到 Microsoft Entra ID 并请求访问令牌。

3. Microsoft Entra ID 使用 OIDC 发现文档来验证对用户定义的托管标识或已注册的应用程序的信任并验证传入令牌。

4. Microsoft Entra ID 颁发安全访问令牌。

5. Kubernetes 工作负荷通过 Microsoft Entra 访问令牌访问 Azure 资源。

有关工作负荷 ID 的详细信息，请参阅以下资源：

• 工作负荷 ID 开源项目
• 工作负荷标识联合
• 与 Kubernetes 的工作负荷 ID 联合
• 与外部 OIDC 身份提供程序的工作负荷 ID 联合
• 最小化工作负荷 ID 联合
• 工作量标识文档
• 工作负荷 ID 快速入门
• 在 .NET Standard 应用程序中使用适用于具有用户分配托管标识的 Kubernetes 的 Microsoft Entra Workload ID

示例工作负荷

以下示例工作负荷在 AKS 群集上运行，由前端和后端服务组成。 这些服务使用工作负荷 ID 访问 Azure 服务，包括 Key Vault、Azure Cosmos DB、Azure 存储帐户和 Azure 服务总线命名空间。 若要设置此示例工作负荷，请执行以下步骤：

1. 设置启用了 OIDC 颁发者和工作负荷标识的 AKS 群集。

2. 在工作负荷 命名空间中创建 Kubernetes 服务帐户。

3. 创建Microsoft Entra 用户分配的托管标识或已注册的应用程序。

4. 在 Microsoft Entra 托管标识或已注册的应用程序与工作负荷服务帐户之间建立联合标识凭据。

5. 为 Microsoft Entra 托管标识或注册的应用程序分配具有适当权限的必要角色。

6. 部署工作负载并使用工作负载标识验证身份。

工作负荷 ID 消息流

在此示例工作负荷中，前端和后端应用程序获取 Microsoft Entra 安全令牌，以访问 Azure 平台即服务（PaaS）解决方案。 下图显示了消息流。

主要部分是 AKS 群集设置，其中包括 NGINX 入口控制器和 Todolist 命名空间及其组件。 部署容器指示整个工作流中的步骤 1。 流程 2 从部署容器到 Microsoft Entra ID。 流程 3 从 Microsoft Entra ID 到 OIDC 颁发者 URL。 流程 4 从 Microsoft Entra ID 到部署容器。 流 5 从部署容器转到 Azure Key Vault、Azure 服务总线、Azure Cosmos DB 和 Azure 存储帐户。

下载此体系结构的 Visio 文件。

1. 当 Pod 被调度到一个节点上时，Kubernetes 会向 Pod 颁发一个令牌。 此令牌基于 pod 或部署规范。

2. Pod 将 OIDC 颁发的令牌发送到 Microsoft Entra ID，以请求特定 appId 和资源的 Microsoft Entra 令牌。

3. Microsoft Entra ID 验证应用程序的信任并验证传入令牌。

4. Microsoft Entra ID 颁发安全令牌：{sub: appId, aud: requested-audience}。

5. Pod 使用 Microsoft Entra 令牌访问目标 Azure 资源。

要在 Kubernetes 群集中端到端使用 Workload ID：

1. 将 AKS 群集配置为颁发令牌并发布 OIDC 发现文档，以允许验证这些令牌。

2. 配置 Microsoft Entra 应用程序以信任 Kubernetes 令牌。

3. 开发人员将部署配置为使用 Kubernetes 服务帐户来获取 Kubernetes 令牌。

4. 工作负荷 ID 会将 Kubernetes 令牌交换为 Microsoft Entra 令牌。

5. AKS 群集工作负荷使用 Microsoft Entra 令牌访问受保护的资源，例如 Microsoft Graph。

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• Paolo Salvatori | 首席服务工程师
• Martin Gjoshevski | 高级服务工程师

其他参与者：

• Laura Nicolas | 高级软件工程师
• 查德·基特尔 |首席软件工程师 - Azure 模式和做法
• Ed Price | 高级内容项目经理
• Theano Petersen | 技术文档撰写人

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

后续步骤

• 将服务主体与 AKS 结合使用
• 在 AKS 中使用托管标识
• 学习路径：在 Microsoft Entra ID 中管理标识和访问

相关资源

• 适用于 Amazon EKS 专业人员的 AKS
• Kubernetes 监视和日志记录
• 保护对 Kubernetes 的网络访问
• Kubernetes 群集的存储选项
• Kubernetes 的成本管理
• Kubernetes 节点和节点池管理
• 群集治理
• AWS 的 Microsoft Entra 标识管理和访问权限管理