将外部标识提供者与 AKS 结构化身份验证配合使用(预览版)

Azure Kubernetes 服务(AKS)支持结构化身份验证,使你可以配置外部标识提供者,以便将用户进行身份验证到 Kubernetes API 服务器。 此功能基于上游的 Kubernetes 结构化身份验证配置,使组织能够将 AKS 与其现有的 Microsoft Entra ID 之外的标识基础结构集成。

结构化身份验证通过支持行业标准 OpenID Connect (OIDC) 标识提供者,将 AKS 扩展到传统 Microsoft Entra ID 集成之外。 可以使用此功能实现以下操作:

  • 使用外部标识提供者(如 GitHub 或任何符合 OIDC 的提供程序)对用户进行身份验证

  • 在整个组织中维护集中式标识管理

  • 实现自定义声明验证和用户映射规则

  • 在单个群集上同时支持多个标识提供者

此功能基于 Kubernetes 结构化身份验证配置,该配置已移动到 Kubernetes 1.30 中的 beta 版本。 AKS 通过 JSON Web 令牌 (JWT) 验证器实现此功能,这些验证器根据配置验证来自外部标识提供者的令牌。

重要

AKS 预览功能可在自助服务和自愿选择的基础上启用。 预览版按“现状”和“视供应情况”提供,它们不包括在服务级别协议和有限保证范围内。 AKS 预览功能是由客户支持尽最大努力部分覆盖。 因此,这些功能并不适合用于生产。 有关详细信息,请参阅以下支持文章:

外部标识提供者的工作原理

当用户尝试访问 Kubernetes API 服务器时:

  • 身份验证:以下步骤验证用户的标识:

    • 令牌演示:用户从其配置的标识提供者显示 JWT 令牌

    • 令牌验证:API 服务器验证令牌的签名、颁发者、访问群体和到期时间

    • 声明处理:应用自定义声明验证规则以确保令牌满足你的要求

    • 用户映射:将声明映射为 Kubernetes 用户身份(用户名、组和额外属性)

  • 授权:标准 Kubernetes 基于角色的访问控制(RBAC)确定经过身份验证的用户可以执行哪些操作

显示基于外部标识提供者的身份验证如何与 AKS 群集配合使用的概念图。

身份提供者

虽然 AKS 结构化身份验证允许任何符合 OIDC 的标识提供者,但常见示例包括:

  • GitHub:使用 GitHub 标识或 GitHub Actions 进行身份验证

  • 通用 OIDC 提供程序:任何实现 OIDC 标准的提供程序

  • 自定义标识解决方案:特定于组织的 OIDC 实现

注释

通过结构化身份验证不支持 Microsoft Entra ID 作为外部身份提供者。 使用现有的 AKS 托管Microsoft Entra 集成 进行Microsoft Entra ID 身份验证。

身份提供者要求

外部标识提供者必须:

  • 支持 OIDC 标准

  • 提供可公开访问的 OIDC 发现终结点

  • 使用适当的声明颁发 JWT 令牌

  • 可从 AKS 群集节点访问令牌验证

重要概念

JWT 验证器

JWT 验证器是一个配置对象,用于定义 AKS 如何从外部标识提供者验证和处理令牌。 例如,AKS 需要 ID 令牌(JWT),其 aud (受众)声明与为验证器配置的受众值匹配,例如 "my-api" 或 OAuth 客户端 ID。 每个 JWT 验证器包括:

  • 颁发者配置:指定令牌的 OIDC 颁发者 URL 和预期访问群体值。

  • 声明验证规则:使用 CEL(公共表达式语言)表达式对令牌声明强制实施自定义验证逻辑。

  • 声明映射:定义如何将 JWT 声明映射到 Kubernetes 用户属性,例如用户名、组和额外字段。

  • 用户验证规则:在声明映射后应用额外的验证逻辑以进一步限制或允许访问。

CEL 表达式

结构化身份验证使用 CEL 表达式进行灵活的声明验证和映射。 CEL 提供了一个安全的沙盒环境,用于评估针对 JWT 声明的自定义逻辑。

CEL 表达式示例:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

安全最佳做法

  • 使用强声明验证:实施全面的验证规则,以确保仅接受已授权令牌。

  • 限制令牌范围:将标识提供者配置为使用尽可能少的必要声明颁发令牌。

  • 定期轮换:定期轮换客户端机密和证书。

  • 监视访问:启用 资源日志 并启用 kube-apiserver 日志,以检查配置 JWT 验证器的任何潜在问题并跟踪身份验证事件。

  • 测试配置:首先在非生产环境中验证 JWT 验证器配置。

安全注意事项

前缀要求 - 通过结构化身份验证映射的所有用户名和组都必须带有 aks:jwt: 前缀,以防止与其他身份验证方法和系统帐户冲突。

网络访问 - 标识提供者终结点必须能够从以下位置访问:

  • 用于令牌验证的 AKS 群集节点

  • 用于获取令牌的客户端系统

  • 身份验证流中涉及的任何网络路径

验证层 - 结构化身份验证提供多个验证层:

  • 令牌签名验证:确保令牌真实性

  • 标准声明验证:验证颁发者、受众和到期时间

  • 自定义声明验证:应用组织的特定要求

  • 用户验证:声明映射后的最终检查

后续步骤