本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.30：结构化身份验证配置进入 Beta 阶段

作者：Anish Ramasekar (Microsoft) | 2024 年 4 月 25 日，星期四

在 Kubernetes 1.30 中，我们（SIG Auth）将结构化身份认证配置（Structured Authentication Configuration）推进到 Beta 阶段。

今天的文章是关于**身份认证**（Authentication）：查明谁在执行任务，并核实他们是否是其声称的身份。明天再来了解 Kubernetes v1.30 在**授权**（Authorization）（决定某人可以和不可以访问什么）方面的新特性。

动机

Kubernetes 长期以来一直需要一个更灵活、可扩展的身份认证系统。当前的系统虽然强大，但存在一些限制，使其在某些场景下难以使用。例如，无法使用同一类型的多个身份认证器（例如，多个 JWT 认证器），也无法在不重启 API 服务器的情况下更改配置。结构化身份认证配置功能是解决这些限制、并为在 Kubernetes 中配置身份认证提供更灵活和可扩展方式的第一步。

什么是结构化身份认证配置？

Kubernetes v1.30 建立在 Kubernetes v1.29 作为 Alpha 版本添加的、基于文件配置身份认证的实验性支持之上。在这个 Beta 阶段，Kubernetes 仅支持配置 JWT 认证器，这是现有 OIDC 认证器的下一代版本。JWT 认证器是一种使用 JWT 兼容令牌对 Kubernetes 用户进行身份认证的认证器。该认证器将尝试解析原始 ID 令牌，并验证它是否由配置的签发者签名。

Kubernetes 项目增加了从文件进行配置的功能，以便提供比使用命令行选项（这些选项仍然有效，并且继续受到支持）更大的灵活性。支持配置文件也使得在即将发布的版本中更容易实现进一步的改进。

结构化身份认证配置的优势

以下是为什么使用配置文件来配置集群身份认证会带来好处的原因：

多个 JWT 认证器：你可以同时配置多个 JWT 认证器。这使你可以使用多个身份提供程序（例如，Okta、Keycloak、GitLab），而无需使用像 Dex 这样的中间件来处理多个身份提供程序之间的多路复用。
动态配置：你可以在不重启 API 服务器的情况下更改配置。这使你可以在不中断 API 服务器的情况下添加、删除或修改认证器。
任何符合 JWT 规范的令牌：你可以使用任何符合 JWT 规范的令牌进行身份认证。这使你可以使用任何支持 JWT 的身份提供程序提供的令牌。最小有效 JWT 负载必须包含 Kubernetes 文档中结构化身份认证配置页面记录的声明。
CEL（通用表达式语言）支持：你可以使用 CEL 来判断令牌的声明是否与 Kubernetes 中的用户属性（例如，用户名、用户组）匹配。这使你可以使用复杂的逻辑来判断令牌是否有效。
多个受众（Audience）：你可以为单个认证器配置多个受众。这使你可以为多个受众使用相同的认证器，例如为 kubectl 和 Dashboard 使用不同的 OAuth 客户端。
使用不支持 OpenID Connect 发现的身份提供程序：你可以使用不支持 OpenID Connect 发现的身份提供程序。唯一的要求是将发现文档托管在与签发者不同的位置（例如在集群本地），并在配置文件中指定 issuer.discoveryURL。

如何使用结构化身份认证配置

要使用结构化身份认证配置，你需要在 API 服务器中使用 --authentication-config 命令行参数指定身份认证配置文件的路径。该配置文件是一个 YAML 文件，用于指定认证器及其配置。以下是一个配置两个 JWT 认证器的示例配置文件：

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# Someone with a valid token from either of these issuers could authenticate
# against this cluster.
jwt:
- issuer:
    url: https://issuer1.example.com
    audiences:
    - audience1
    - audience2
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"
# second authenticator that exposes the discovery document at a different location
# than the issuer
- issuer:
    url: https://issuer2.example.com
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    audiences:
    - audience3
    - audience4
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"

从命令行参数迁移到配置文件

结构化身份认证配置功能旨在与现有的、基于命令行选项配置 JWT 认证器的方法向后兼容。这意味着你可以继续使用现有的命令行选项来配置 JWT 认证器。但是，我们（Kubernetes SIG Auth）建议迁移到新的基于配置文件的方法，因为它提供了更大的灵活性和可扩展性。

说明

如果你同时指定了 --authentication-config 和任何 --oidc-* 命令行参数，这将是一个错误的配置。在这种情况下，API 服务器会报告一个错误，然后立即退出。

如果你想切换到使用结构化身份认证配置，你必须移除 --oidc-* 命令行参数，并改用配置文件。

以下是一个如何从命令行标志迁移到配置文件的示例：

命令行参数

--oidc-issuer-url=https://issuer.example.com
--oidc-client-id=example-client-id
--oidc-username-claim=username
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:
--oidc-required-claim="hd=example.com"
--oidc-required-claim="admin=true"
--oidc-ca-file=/path/to/ca.pem

配置文件中没有与 --oidc-signing-algs 等效的设置。对于 Kubernetes v1.30，认证器支持 oidc.go 中列出的所有非对称算法。

配置文件

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://issuer.example.com
    audiences:
    - example-client-id
    certificateAuthority: <value is the content of file /path/to/ca.pem>
  claimMappings:
    username:
      claim: username
      prefix: "oidc:"
    groups:
      claim: groups
      prefix: "oidc:"
  claimValidationRules:
  - claim: hd
    requiredValue: "example.com"
  - claim: admin
    requiredValue: "true"

接下来是什么？

对于 Kubernetes v1.31，我们预计该功能将保持在 Beta 阶段，同时我们会收集更多反馈。在未来的版本中，我们希望研究：

通过 CEL 表达式使分布式声明（distributed claims）生效。
为对 issuer.url 和 issuer.discoveryURL 的调用提供出口选择器（egress selector）配置支持。

你可以在 Kubernetes 文档的结构化身份认证配置页面上了解有关此功能的更多信息。你也可以关注 KEP-3331 来跟踪未来 Kubernetes 版本中的进展。

立即试用

在这篇文章中，我介绍了结构化身份认证配置功能在 Kubernetes v1.30 中带来的好处。要使用此功能，你必须使用 --authentication-config 命令行参数指定身份认证配置文件的路径。从 Kubernetes v1.30 开始，该功能处于 Beta 阶段并默认启用。如果你想继续使用命令行参数而不是配置文件，这些参数将继续按原样工作。

我们非常希望听到你对此功能的反馈。请通过 Kubernetes Slack 上的 #sig-auth-authenticators-dev 频道与我们联系（如需邀请，请访问 https://slack.k8s.io/）。

如何参与

如果你有兴趣参与此功能的开发、分享反馈或参与任何其他正在进行的 SIG Auth 项目，请通过 Kubernetes Slack 上的 #sig-auth 频道与我们联系。

也欢迎你参加每隔一个周三举行的SIG Auth 双周会议。