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

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

在 Kubernetes 1.30 中，我们（SIG Auth）正在将结构化身份验证配置移至 Beta 阶段。

今天的文章是关于身份验证：找出谁在执行任务，并检查他们是否是他们所说的那个人。明天回来查看 Kubernetes v1.30 中关于授权（决定某人可以访问和不能访问的内容）的新功能。

动机

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

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

Kubernetes v1.30 基于 Kubernetes v1.30 中添加的基于文件的身份验证配置的实验性支持构建。在这个 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 中用户的属性（例如，用户名、组）匹配。这允许您使用复杂的逻辑来确定令牌是否有效。
多个受众：您可以为单个身份验证器配置多个受众。这允许您将相同的身份验证器用于多个受众，例如为 kubectl 和仪表板使用不同的 OAuth 客户端。
使用不支持 OpenID 连接发现的身份提供者：您可以使用不支持 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 表达式使分布式声明工作。
为对 issuer.url 和 issuer.discoveryURL 的调用提供出口选择器配置支持。

您可以在 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 会议。