身份验证

此页面概述了身份验证。

Kubernetes 中的用户

所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务帐户和普通用户。

假设一个与集群无关的服务以以下方式管理普通用户

  • 管理员分发私钥
  • 用户存储（如 Keystone 或 Google 帐户）
  • 包含用户名和密码列表的文件

在这方面，Kubernetes 没有表示普通用户帐户的对象。 普通用户无法通过 API 调用添加到集群。

即使普通用户无法通过 API 调用添加，任何提交由集群的证书颁发机构 (CA) 签名的有效证书的用户都被视为已通过身份验证。在此配置中，Kubernetes 从证书的“subject”中的公用名称字段确定用户名（例如，“/CN=bob”）。从那里，基于角色的访问控制 (RBAC) 子系统将确定用户是否有权对资源执行特定操作。有关更多详细信息，请参阅 证书请求 中的普通用户主题。

相比之下，服务帐户是由 Kubernetes API 管理的用户。它们绑定到特定的命名空间，并由 API 服务器自动创建，或通过 API 调用手动创建。服务帐户绑定到一组存储为 Secrets 的凭据，这些凭据被挂载到 Pod 中，允许集群内进程与 Kubernetes API 通信。

API 请求绑定到普通用户或服务帐户，或被视为匿名请求。这意味着集群内部或外部的每个进程，从在工作站上输入 kubectl 的人类用户，到节点上的 kubelets，再到控制平面的成员，在向 API 服务器发出请求时都必须进行身份验证，否则将被视为匿名用户。

身份验证策略

Kubernetes 使用客户端证书、持有者令牌或身份验证代理，通过身份验证插件对 API 请求进行身份验证。当向 API 服务器发出 HTTP 请求时，插件会尝试将以下属性与请求关联

  • 用户名：一个字符串，用于标识最终用户。常见值可能为 kube-admin 或 [email protected]。
  • UID：一个字符串，用于标识最终用户，并尝试比用户名更一致和唯一。
  • 组：一组字符串，每个字符串表示用户在命名的用户逻辑集合中的成员资格。常见值可能为 system:masters 或 devops-team。
  • 额外字段：一个字符串到字符串列表的映射，其中包含授权者可能会觉得有用的其他信息。

所有值对于身份验证系统都是不透明的，仅在被授权器解释时才具有意义。

您可以同时启用多种身份验证方法。您通常至少应使用两种方法

  • 服务帐户的服务帐户令牌
  • 至少一种用于用户身份验证的其他方法。

当启用多个身份验证器模块时，第一个成功验证请求的模块会短路评估。API 服务器不保证身份验证器运行的顺序。

system:authenticated 组包含在所有经过身份验证的用户的组列表中。

可以使用身份验证代理或身份验证 webhook来实现与其他身份验证协议（LDAP、SAML、Kerberos、替代 x509 方案等）的集成。

X509 客户端证书

通过将 --client-ca-file=SOMEFILE 选项传递给 API 服务器来启用客户端证书身份验证。引用的文件必须包含一个或多个证书颁发机构，用于验证提供给 API 服务器的客户端证书。如果提供并验证了客户端证书，则 subject 的公用名称将用作请求的用户名。从 Kubernetes 1.4 开始，客户端证书还可以使用证书的组织字段来指示用户的组成员资格。要为用户包含多个组成员资格，请在证书中包含多个组织字段。

例如，使用 openssl 命令行工具生成证书签名请求

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

这将为属于两个组“app1”和“app2”的用户名“jbeda”创建一个 CSR。

有关如何生成客户端证书，请参阅管理证书。

静态令牌文件

当在命令行上提供 --token-auth-file=SOMEFILE 选项时，API 服务器会从文件中读取持有者令牌。目前，令牌无限期有效，并且令牌列表在不重启 API 服务器的情况下无法更改。

令牌文件是一个 csv 文件，至少包含 3 列：令牌、用户名、用户 uid，后跟可选的组名。

在请求中放置持有者令牌

从 http 客户端使用持有者令牌身份验证时，API 服务器期望 Authorization 标头的值为 Bearer <token>。持有者令牌必须是一个字符序列，可以使用 HTTP 的编码和引用功能放入 HTTP 标头值中。例如：如果持有者令牌为 31ada4fd-adec-460c-809a-9e56ceb75269，则它将如下所示出现在 HTTP 标头中。

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

引导令牌

特性状态： Kubernetes v1.18 [stable]

为了允许简化新集群的引导，Kubernetes 包括一种名为引导令牌的动态管理持有者令牌类型。这些令牌以 Secret 的形式存储在 kube-system 命名空间中，可以在其中动态管理和创建。Controller Manager 包含一个 TokenCleaner 控制器，该控制器会在引导令牌过期时将其删除。

令牌的形式为 [a-z0-9]{6}.[a-z0-9]{16}。第一个组件是令牌 ID，第二个组件是令牌 Secret。您在 HTTP 标头中指定令牌，如下所示

Authorization: Bearer 781292.db7bc3a58fc5f07e

您必须使用 API 服务器上的 --enable-bootstrap-token-auth 标志启用引导令牌身份验证器。您必须通过 Controller Manager 上的 --controllers 标志启用 TokenCleaner 控制器。可以使用类似 --controllers=*,tokencleaner 的方式完成此操作。如果您使用 kubeadm 引导集群，则 kubeadm 会为您执行此操作。

身份验证器将身份验证为 system:bootstrap:<Token ID>。它包含在 system:bootstrappers 组中。命名和组有意限制，以阻止用户在引导后使用这些令牌。用户名和组可用于（并且 kubeadm 使用）制定适当的授权策略以支持引导集群。

有关引导令牌身份验证器和控制器以及如何使用 kubeadm 管理这些令牌的深入文档，请参阅引导令牌。

服务帐户令牌

服务帐户是自动启用的身份验证器，它使用签名持有者令牌来验证请求。该插件采用两个可选标志

  • --service-account-key-file 包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。指定的文件可以包含多个密钥，并且可以使用不同的文件多次指定该标志。如果未指定，则使用 --tls-private-key-file。
  • --service-account-lookup 如果启用，则从 API 中删除的令牌将被撤销。

服务帐户通常由 API 服务器自动创建，并通过 ServiceAccount 准入控制器与集群中运行的 Pod 相关联。持有者令牌被挂载到众所周知的位置的 Pod 中，并允许集群内进程与 API 服务器通信。可以使用 PodSpec 的 serviceAccountName 字段将帐户显式地与 Pod 相关联。

apiVersion: apps/v1 # this apiVersion is relevant as of Kubernetes 1.9
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  template:
    metadata:
    # ...
    spec:
      serviceAccountName: bob-the-bot
      containers:
      - name: nginx
        image: nginx:1.14.2

服务帐户持有者令牌完全可以在集群外部使用，并且可以用于为希望与 Kubernetes API 通信的长期作业创建身份。要手动创建服务帐户，请使用 kubectl create serviceaccount (NAME) 命令。这将在当前命名空间中创建一个服务帐户。

kubectl create serviceaccount jenkins

serviceaccount/jenkins created

创建关联的令牌

kubectl create token jenkins

eyJhbGciOiJSUzI1NiIsImtp...

创建的令牌是一个签名的 JSON Web 令牌 (JWT)。

签名的 JWT 可以用作持有者令牌，以给定服务帐户的身份进行身份验证。有关令牌如何在请求中包含的信息，请参阅上面。通常，这些令牌被挂载到 Pod 中以在集群内访问 API 服务器，但也可以从集群外部使用。

服务帐户使用用户名 system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) 进行身份验证，并被分配到组 system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)。

OpenID Connect 令牌

OpenID Connect 是 OAuth2 的一种变体，一些 OAuth2 提供商支持它，尤其是 Microsoft Entra ID、Salesforce 和 Google。该协议对 OAuth2 的主要扩展是在访问令牌中返回一个名为 ID Token 的附加字段。此令牌是一个 JSON Web Token (JWT)，包含一些众所周知的字段（例如用户的电子邮件），并由服务器签名。

为了识别用户，身份验证器使用 OAuth2 令牌响应中的 id_token（而不是 access_token）作为持有者令牌。有关如何在请求中包含令牌，请参见上文。

sequenceDiagram participant user as 用户 participant idp as 身份提供商 participant kube as kubectl participant api as API 服务器 user ->> idp: 1. 登录到 IdP activate idp idp -->> user: 2. 提供 access_token,
id_token 和 refresh_token deactivate idp activate user user ->> kube: 3. 调用 kubectl
使用 --token 参数指定 id_token
或者将令牌添加到 .kube/config deactivate user activate kube kube ->> api: 4. Authorization: Bearer... deactivate kube activate api api ->> api: 5. JWT 签名是否有效？ api ->> api: 6. JWT 是否已过期？ (iat+exp) api ->> api: 7. 用户是否已授权？ api -->> kube: 8. 已授权：执行
操作并返回结果 deactivate api activate kube kube --x user: 9. 返回结果 deactivate kube

  1. 登录到您的身份提供商

  2. 您的身份提供商将为您提供一个 access_token、id_token 和一个 refresh_token

  3. 使用 kubectl 时，请使用带有 --token 标志的 id_token，或将其直接添加到您的 kubeconfig 中

  4. kubectl 在名为 Authorization 的标头中将您的 id_token 发送到 API 服务器

  5. API 服务器将确保 JWT 签名有效

  6. 检查以确保 id_token 没有过期

    如果使用 AuthenticationConfiguration 配置了 CEL 表达式，则执行声明和/或用户验证。

  7. 确保用户已授权

  8. 一旦授权，API 服务器会将响应返回给 kubectl

  9. kubectl 向用户提供反馈

由于验证您身份的所有数据都在 id_token 中，因此 Kubernetes 不需要“打电话回家”给身份提供商。在每个请求都是无状态的模型中，这为身份验证提供了一个非常可扩展的解决方案。它确实带来了一些挑战

  1. Kubernetes 没有“Web 界面”来触发身份验证过程。没有浏览器或界面来收集凭据，这就是为什么您需要先向身份提供商进行身份验证的原因。
  2. id_token 不能被撤销，它就像一个证书，所以它应该是短期的（只有几分钟），因此每隔几分钟就必须获取一个新的令牌可能会非常烦人。
  3. 要对 Kubernetes 仪表板进行身份验证，您必须使用 kubectl proxy 命令或注入 id_token 的反向代理。

配置 API 服务器

使用标志

要启用插件，请在 API 服务器上配置以下标志

参数描述示例必需
--oidc-issuer-url允许 API 服务器发现公共签名密钥的提供商的 URL。只接受使用 https:// 方案的 URL。这通常是提供商的发现 URL，更改为空路径。如果颁发者的 OIDC 发现 URL 是 https://accounts.provider.example/.well-known/openid-configuration，则该值应为 https://accounts.provider.example是
--oidc-client-id所有令牌都必须为其颁发的客户端 ID。kubernetes是
--oidc-username-claim用作用户名的 JWT 声明。默认情况下为 sub，它应该是最终用户的唯一标识符。管理员可以选择其他声明，例如 email 或 name，具体取决于他们的提供商。但是，email 以外的声明将使用颁发者 URL 作为前缀，以防止与其他插件发生命名冲突。sub否
--oidc-username-prefix添加到用户名声明的前缀，以防止与现有名称（例如 system: 用户）发生冲突。例如，值 oidc: 将创建类似 oidc:jane.doe 的用户名。如果未提供此标志且 --oidc-username-claim 的值不是 email，则前缀默认为 (颁发者 URL)#，其中 (颁发者 URL) 是 --oidc-issuer-url 的值。值 - 可用于禁用所有前缀。oidc否
--oidc-groups-claim用作用户组的 JWT 声明。如果存在该声明，则它必须是一个字符串数组。groups否
--oidc-groups-prefix添加到组声明的前缀，以防止与现有名称（例如 system: 组）发生冲突。例如，值 oidc: 将创建类似 oidc:engineering 和 oidc:infra 的组名。oidc否
--oidc-required-claim描述 ID 令牌中必需声明的键值对。如果设置，则会验证该声明是否存在于 ID 令牌中，并且具有匹配的值。重复此标志以指定多个声明。claim=value否
--oidc-ca-file用于签署您的身份提供商的 Web 证书的 CA 证书的路径。默认为主机的根 CA。/etc/kubernetes/ssl/kc-ca.pem否
--oidc-signing-algs接受的签名算法。默认为 "RS256"。RS512否
从文件进行身份验证配置
功能状态： Kubernetes v1.30 [beta]（默认启用：true）

JWT 身份验证器是一个身份验证器，用于使用符合 JWT 的令牌来验证 Kubernetes 用户。身份验证器将尝试解析原始 ID 令牌，验证它是否已由配置的颁发者签名。用于验证签名的公钥是通过使用 OIDC 发现从颁发者的公共端点发现的。

最小有效 JWT 负载必须包含以下声明

{
  "iss": "https://example.com",   // must match the issuer.url
  "aud": ["my-app"],              // at least one of the entries in issuer.audiences must match the "aud" claim in presented JWTs.
  "exp": 1234567890,              // token expiration as Unix time (the number of seconds elapsed since January 1, 1970 UTC)
  "<username-claim>": "user"      // this is the username claim configured in the claimMappings.username.claim or claimMappings.username.expression
}

配置文件方法允许您配置多个 JWT 身份验证器，每个身份验证器都有唯一的 issuer.url 和 issuer.discoveryURL。配置文件甚至允许您指定 CEL 表达式，以将声明映射到用户属性，并验证声明和用户信息。API 服务器在配置文件被修改时也会自动重新加载身份验证器。您可以使用 apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds 指标来监视 API 服务器上次重新加载配置的时间。

您必须使用 API 服务器上的 --authentication-config 标志指定身份验证配置的路径。如果要使用命令行标志而不是配置文件，这些标志将继续按原样工作。要访问新功能（如配置多个身份验证器、为颁发者设置多个受众），请切换到使用配置文件。

对于 Kubernetes v1.32，结构化身份验证配置文件格式处于 beta 级别，并且使用该配置的机制也处于 beta 级别。如果您没有为您的集群专门禁用 StructuredAuthenticationConfiguration 功能门，您可以通过为 kube-apiserver 指定 --authentication-config 命令行参数来启用结构化身份验证。下面显示了结构化身份验证配置文件的示例。

---
#
# CAUTION: this is an example configuration.
#          Do not use this for your own cluster!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# list of authenticators to authenticate Kubernetes users using JWT compliant tokens.
# the maximum number of allowed authenticators is 64.
jwt:
- issuer:
    # url must be unique across all authenticators.
    # url must not conflict with issuer configured in --service-account-issuer.
    url: https://example.com # Same as --oidc-issuer-url.
    # discoveryURL, if specified, overrides the URL used to fetch discovery
    # information instead of using "{url}/.well-known/openid-configuration".
    # The exact value specified is used, so "/.well-known/openid-configuration"
    # must be included in discoveryURL if needed.
    #
    # The "issuer" field in the fetched discovery information must match the "issuer.url" field
    # in the AuthenticationConfiguration and will be used to validate the "iss" claim in the presented JWT.
    # This is for scenarios where the well-known and jwks endpoints are hosted at a different
    # location than the issuer (such as locally in the cluster).
    # discoveryURL must be different from url if specified and must be unique across all authenticators.
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    # PEM encoded CA certificates used to validate the connection when fetching
    # discovery information. If not set, the system verifier will be used.
    # Same value as the content of the file referenced by the --oidc-ca-file flag.
    certificateAuthority: <PEM encoded CA certificates>    
    # audiences is the set of acceptable audiences the JWT must be issued to.
    # At least one of the entries must match the "aud" claim in presented JWTs.
    audiences:
    - my-app # Same as --oidc-client-id.
    - my-other-app
    # this is required to be set to "MatchAny" when multiple audiences are specified.
    audienceMatchPolicy: MatchAny
  # rules applied to validate token claims to authenticate users.
  claimValidationRules:
    # Same as --oidc-required-claim key=value.
  - claim: hd
    requiredValue: example.com
    # Instead of claim and requiredValue, you can use expression to validate the claim.
    # expression is a CEL expression that evaluates to a boolean.
    # all the expressions must evaluate to true for validation to succeed.
  - expression: 'claims.hd == "example.com"'
    # Message customizes the error message seen in the API server logs when the validation fails.
    message: the hd claim must be set to example.com
  - expression: 'claims.exp - claims.nbf <= 86400'
    message: total token lifetime must not exceed 24 hours
  claimMappings:
    # username represents an option for the username attribute.
    # This is the only required attribute.
    username:
      # Same as --oidc-username-claim. Mutually exclusive with username.expression.
      claim: "sub"
      # Same as --oidc-username-prefix. Mutually exclusive with username.expression.
      # if username.claim is set, username.prefix is required.
      # Explicitly set it to "" if no prefix is desired.
      prefix: ""
      # Mutually exclusive with username.claim and username.prefix.
      # expression is a CEL expression that evaluates to a string.
      #
      # 1.  If username.expression uses 'claims.email', then 'claims.email_verified' must be used in
      #     username.expression or extra[*].valueExpression or claimValidationRules[*].expression.
      #     An example claim validation rule expression that matches the validation automatically
      #     applied when username.claim is set to 'email' is 'claims.?email_verified.orValue(true)'.
      # 2.  If the username asserted based on username.expression is the empty string, the authentication
      #     request will fail.
      expression: 'claims.username + ":external-user"'
    # groups represents an option for the groups attribute.
    groups:
      # Same as --oidc-groups-claim. Mutually exclusive with groups.expression.
      claim: "sub"
      # Same as --oidc-groups-prefix. Mutually exclusive with groups.expression.
      # if groups.claim is set, groups.prefix is required.
      # Explicitly set it to "" if no prefix is desired.
      prefix: ""
      # Mutually exclusive with groups.claim and groups.prefix.
      # expression is a CEL expression that evaluates to a string or a list of strings.
      expression: 'claims.roles.split(",")'
    # uid represents an option for the uid attribute.
    uid:
      # Mutually exclusive with uid.expression.
      claim: 'sub'
      # Mutually exclusive with uid.claim
      # expression is a CEL expression that evaluates to a string.
      expression: 'claims.sub'
    # extra attributes to be added to the UserInfo object. Keys must be domain-prefix path and must be unique.
    extra:
      # key is a string to use as the extra attribute key.
      # key must be a domain-prefix path (e.g. example.org/foo). All characters before the first "/" must be a valid
      # subdomain as defined by RFC 1123. All characters trailing the first "/" must
      # be valid HTTP Path characters as defined by RFC 3986.
      # k8s.io, kubernetes.io and their subdomains are reserved for Kubernetes use and cannot be used.
      # key must be lowercase and unique across all extra attributes.
    - key: 'example.com/tenant'
      # valueExpression is a CEL expression that evaluates to a string or a list of strings.
      valueExpression: 'claims.tenant'
  # validation rules applied to the final user object.
  userValidationRules:
    # expression is a CEL expression that evaluates to a boolean.
    # all the expressions must evaluate to true for the user to be valid.
  - expression: "!user.username.startsWith('system:')"
    # Message customizes the error message seen in the API server logs when the validation fails.
    message: 'username cannot used reserved system: prefix'
  - expression: "user.groups.all(group, !group.startsWith('system:'))"
    message: 'groups cannot used reserved system: prefix'

  • 声明验证规则表达式

    jwt.claimValidationRules[i].expression 表示将由 CEL 评估的表达式。CEL 表达式可以访问令牌负载的内容，这些内容组织到 claims CEL 变量中。claims 是声明名称（作为字符串）到声明值（任何类型）的映射。

  • 用户验证规则表达式

    jwt.userValidationRules[i].expression 表示将由 CEL 评估的表达式。CEL 表达式可以访问 userInfo 的内容，这些内容组织到 user CEL 变量中。有关 user 的架构，请参阅 UserInfo API 文档。

  • 声明映射表达式

    jwt.claimMappings.username.expression, jwt.claimMappings.groups.expression, jwt.claimMappings.uid.expression, jwt.claimMappings.extra[i].valueExpression 表示将由 CEL 评估的表达式。CEL 表达式可以访问令牌负载的内容，这些内容组织到 claims CEL 变量中。claims 是声明名称（作为字符串）到声明值（任何类型）的映射。

    要了解更多信息，请参阅 CEL 文档

    以下是具有不同令牌负载的 AuthenticationConfiguration 的示例。

    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimMappings:
    username:
      expression: 'claims.username + ":external-user"'
    groups:
      expression: 'claims.roles.split(",")'
    uid:
      expression: 'claims.sub'
    extra:
    - key: 'example.com/tenant'
      valueExpression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')" # the expression will evaluate to true, so validation will succeed.
    message: 'username cannot used reserved system: prefix'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA

    其中令牌负载是

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "iat": 1701107233,
    "iss": "https://example.com",
    "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
    "nbf": 1701107233,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    具有上述 AuthenticationConfiguration 的令牌将生成以下 UserInfo 对象，并成功验证用户身份。

    {
    "username": "foo:external-user",
    "uid": "auth",
    "groups": [
        "user",
        "admin"
    ],
    "extra": {
        "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
    }
}


    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimValidationRules:
  - expression: 'claims.hd == "example.com"' # the token below does not have this claim, so validation will fail.
    message: the hd claim must be set to example.com
  claimMappings:
    username:
      expression: 'claims.username + ":external-user"'
    groups:
      expression: 'claims.roles.split(",")'
    uid:
      expression: 'claims.sub'
    extra:
    - key: 'example.com/tenant'
      valueExpression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')" # the expression will evaluate to true, so validation will succeed.
    message: 'username cannot used reserved system: prefix'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJpYXQiOjE3MDExMDcyMzMsImlzcyI6Imh0dHBzOi8vZXhhbXBsZS5jb20iLCJqdGkiOiI3YzMzNzk0MjgwN2U3M2NhYTJjMzBjODY4YWMwY2U5MTBiY2UwMmRkY2JmZWJlOGMyM2I4YjVmMjdhZDYyODczIiwibmJmIjoxNzAxMTA3MjMzLCJyb2xlcyI6InVzZXIsYWRtaW4iLCJzdWIiOiJhdXRoIiwidGVuYW50IjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjRhIiwidXNlcm5hbWUiOiJmb28ifQ.TBWF2RkQHm4QQz85AYPcwLxSk-VLvQW-mNDHx7SEOSv9LVwcPYPuPajJpuQn9C_gKq1R94QKSQ5F6UgHMILz8OfmPKmX_00wpwwNVGeevJ79ieX2V-__W56iNR5gJ-i9nn6FYk5pwfVREB0l4HSlpTOmu80gbPWAXY5hLW0ZtcE1JTEEmefORHV2ge8e3jp1xGafNy6LdJWabYuKiw8d7Qga__HxtKB-t0kRMNzLRS7rka_SfQg0dSYektuxhLbiDkqhmRffGlQKXGVzUsuvFw7IGM5ZWnZgEMDzCI357obHeM3tRqpn5WRjtB8oM7JgnCymaJi-P3iCd88iu1xnzA

    其中令牌负载是

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "iat": 1701107233,
    "iss": "https://example.com",
    "jti": "7c337942807e73caa2c30c868ac0ce910bce02ddcbfebe8c23b8b5f27ad62873",
    "nbf": 1701107233,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    具有上述 AuthenticationConfiguration 的令牌将无法验证身份，因为 hd 声明未设置为 example.com。API 服务器将返回 401 Unauthorized 错误。

    apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    audiences:
    - my-app
  claimValidationRules:
  - expression: 'claims.hd == "example.com"'
    message: the hd claim must be set to example.com
  claimMappings:
    username:
      expression: '"system:" + claims.username' # this will prefix the username with "system:" and will fail user validation.
    groups:
      expression: 'claims.roles.split(",")'
    uid:
      expression: 'claims.sub'
    extra:
    - key: 'example.com/tenant'
      valueExpression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')" # the username will be system:foo and expression will evaluate to false, so validation will fail.
    message: 'username cannot used reserved system: prefix'

    TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6ImY3dF9tOEROWmFTQk1oWGw5QXZTWGhBUC04Y0JmZ0JVbFVpTG5oQkgxdXMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNzAzMjMyOTQ5LCJoZCI6ImV4YW1wbGUuY29tIiwiaWF0IjoxNzAxMTEzMTAxLCJpc3MiOiJodHRwczovL2V4YW1wbGUuY29tIiwianRpIjoiYjViMDY1MjM3MmNkMjBlMzQ1YjZmZGZmY2RjMjE4MWY0YWZkNmYyNTlhYWI0YjdlMzU4ODEyMzdkMjkyMjBiYyIsIm5iZiI6MTcwMTExMzEwMSwicm9sZXMiOiJ1c2VyLGFkbWluIiwic3ViIjoiYXV0aCIsInRlbmFudCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0YSIsInVzZXJuYW1lIjoiZm9vIn0.FgPJBYLobo9jnbHreooBlvpgEcSPWnKfX6dc0IvdlRB-F0dCcgy91oCJeK_aBk-8zH5AKUXoFTlInfLCkPivMOJqMECA1YTrMUwt_IVqwb116AqihfByUYIIqzMjvUbthtbpIeHQm2fF0HbrUqa_Q0uaYwgy8mD807h7sBcUMjNd215ff_nFIHss-9zegH8GI1d9fiBf-g6zjkR1j987EP748khpQh9IxPjMJbSgG_uH5x80YFuqgEWwq-aYJPQxXX6FatP96a2EAn7wfPpGlPRt0HcBOvq5pCnudgCgfVgiOJiLr_7robQu4T1bis0W75VPEvwWtgFcLnvcQx0JWg

    其中令牌负载是

      {
    "aud": "kubernetes",
    "exp": 1703232949,
    "hd": "example.com",
    "iat": 1701113101,
    "iss": "https://example.com",
    "jti": "b5b0652372cd20e345b6fdffcdc2181f4afd6f259aab4b7e35881237d29220bc",
    "nbf": 1701113101,
    "roles": "user,admin",
    "sub": "auth",
    "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a",
    "username": "foo"
  }

    具有上述 AuthenticationConfiguration 的令牌将生成以下 UserInfo 对象

    {
    "username": "system:foo",
    "uid": "auth",
    "groups": [
        "user",
        "admin"
    ],
    "extra": {
        "example.com/tenant": "72f988bf-86f1-41af-91ab-2d7cd011db4a"
    }
}

    由于用户名以 system: 开头，这将导致用户验证失败。API 服务器将返回 401 Unauthorized 错误。

限制
  1. 分布式声明不通过 CEL 表达式起作用。
  2. 对 issuer.url 和 issuer.discoveryURL 的调用不支持出口选择器配置。

Kubernetes 不提供 OpenID Connect 身份提供商。您可以使用现有的公共 OpenID Connect 身份提供商（例如 Google 或 其他提供商）。或者，您可以运行自己的身份提供商，例如 dex、Keycloak、CloudFoundry UAA 或 Tremolo Security 的 OpenUnison。

要使身份提供商与 Kubernetes 一起工作，它必须

  1. 支持 OpenID Connect 发现

    用于验证签名的公钥是通过 OIDC 发现从颁发者的公共端点获取的。如果使用身份验证配置文件，则身份提供者无需公开发现端点。您可以将发现端点托管在与颁发者不同的位置（例如在集群本地），并在配置文件中指定 issuer.discoveryURL。

  2. 使用 TLS 运行，并采用非过时的密码套件

  3. 拥有由 CA 签名的证书（即使 CA 不是商业 CA 或自签名）

关于上述第 3 项要求，即需要 CA 签名的证书。如果您部署自己的身份提供者（而不是像 Google 或 Microsoft 这样的云提供商），则您的身份提供者的 Web 服务器证书必须由设置了 CA 标志为 TRUE 的证书签名，即使它是自签名的。这是因为 GoLang 的 TLS 客户端实现对证书验证的标准非常严格。如果您没有可用的 CA，可以使用 Dex 团队的 gencert 脚本 来创建简单的 CA 以及签名的证书和密钥对。或者，您可以使用 这个类似的脚本，它会生成具有更长有效期和更大密钥大小的 SHA256 证书。

请参阅特定系统的设置说明

使用 kubectl

选项 1 - OIDC 身份验证器

第一个选项是使用 kubectl oidc 身份验证器，它将 id_token 设置为所有请求的持有者令牌，并在令牌过期后刷新令牌。在登录到您的提供程序后，使用 kubectl 添加您的 id_token、refresh_token、client_id 和 client_secret 来配置插件。

此插件不支持在刷新令牌响应中不返回 id_token 的提供程序，应使用下面的“选项 2”。

kubectl config set-credentials USER_NAME \
   --auth-provider=oidc \
   --auth-provider-arg=idp-issuer-url=( issuer url ) \
   --auth-provider-arg=client-id=( your client id ) \
   --auth-provider-arg=client-secret=( your client secret ) \
   --auth-provider-arg=refresh-token=( your refresh token ) \
   --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
   --auth-provider-arg=id-token=( your id_token )

例如，在向您的身份提供者进行身份验证后运行以下命令

kubectl config set-credentials mmosley  \
        --auth-provider=oidc  \
        --auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP  \
        --auth-provider-arg=client-id=kubernetes  \
        --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
        --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
        --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
        --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw

这将产生以下配置

users:
- name: mmosley
  user:
    auth-provider:
      config:
        client-id: kubernetes
        client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
        id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
        idp-certificate-authority: /root/ca.pem
        idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
        refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
      name: oidc

一旦您的 id_token 过期，kubectl 将尝试使用您的 refresh_token 和 client_secret 刷新您的 id_token，并将 refresh_token 和 id_token 的新值存储在您的 .kube/config 中。

选项 2 - 使用 --token 选项

kubectl 命令允许您使用 --token 选项传递令牌。将 id_token 复制并粘贴到此选项中

kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes

Webhook 令牌身份验证

Webhook 身份验证是用于验证持有者令牌的钩子。

  • --authentication-token-webhook-config-file：描述如何访问远程 Webhook 服务的配置文件。
  • --authentication-token-webhook-cache-ttl：缓存身份验证决策的时间长度。默认为两分钟。
  • --authentication-token-webhook-version：确定是使用 authentication.k8s.io/v1beta1 还是 authentication.k8s.io/v1 TokenReview 对象来发送/接收来自 Webhook 的信息。默认为 v1beta1。

配置文件使用 kubeconfig 文件格式。在该文件中，clusters 指的是远程服务，而 users 指的是 API 服务器 Webhook。例如：

# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
      server: https://authn.example.com/authenticate # URL of remote service to query. 'https' recommended for production.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
      client-key: /path/to/key.pem          # key matching the cert

# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-server
  name: webhook

当客户端尝试使用如上文所述的持有者令牌向 API 服务器进行身份验证时，身份验证 Webhook 会将包含令牌的 JSON 序列化 TokenReview 对象 POST 到远程服务。

请注意，Webhook API 对象与其他 Kubernetes API 对象一样，也受相同的版本兼容性规则约束。实现者应检查请求的 apiVersion 字段以确保正确反序列化，并且必须使用与请求相同的版本返回 TokenReview 对象。

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "spec": {
    # Opaque bearer token sent to the API server
    "token": "014fbff9a07c...",

    # Optional list of the audience identifiers for the server the token was presented to.
    # Audience-aware token authenticators (for example, OIDC token authenticators)
    # should verify the token was intended for at least one of the audiences in this list,
    # and return the intersection of this list and the valid audiences for the token in the response status.
    # This ensures the token is valid to authenticate to the server it was presented to.
    # If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}


{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
    # Opaque bearer token sent to the API server
    "token": "014fbff9a07c...",

    # Optional list of the audience identifiers for the server the token was presented to.
    # Audience-aware token authenticators (for example, OIDC token authenticators)
    # should verify the token was intended for at least one of the audiences in this list,
    # and return the intersection of this list and the valid audiences for the token in the response status.
    # This ensures the token is valid to authenticate to the server it was presented to.
    # If no audiences are provided, the token should be validated to authenticate to the Kubernetes API server.
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}

远程服务应填写请求的 status 字段以指示登录是否成功。响应正文的 spec 字段将被忽略，并且可以省略。远程服务必须使用其收到的相同 TokenReview API 版本返回响应。成功验证持有者令牌将返回

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # Required
      "username": "[email protected]",
      # Optional
      "uid": "42",
      # Optional group memberships
      "groups": ["developers", "qa"],
      # Optional additional information provided by the authenticator.
      # This should not contain confidential data, as it can be recorded in logs
      # or API objects, and is made available to admission webhooks.
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # Optional list audience-aware token authenticators can return,
    # containing the audiences from the `spec.audiences` list for which the provided token was valid.
    # If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
    "audiences": ["https://myserver.example.com"]
  }
}


{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # Required
      "username": "[email protected]",
      # Optional
      "uid": "42",
      # Optional group memberships
      "groups": ["developers", "qa"],
      # Optional additional information provided by the authenticator.
      # This should not contain confidential data, as it can be recorded in logs
      # or API objects, and is made available to admission webhooks.
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # Optional list audience-aware token authenticators can return,
    # containing the audiences from the `spec.audiences` list for which the provided token was valid.
    # If this is omitted, the token is considered to be valid to authenticate to the Kubernetes API server.
    "audiences": ["https://myserver.example.com"]
  }
}

不成功的请求将返回

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # Optionally include details about why authentication failed.
    # If no error is provided, the API will return a generic Unauthorized message.
    # The error field is ignored when authenticated=true.
    "error": "Credentials are expired"
  }
}


{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # Optionally include details about why authentication failed.
    # If no error is provided, the API will return a generic Unauthorized message.
    # The error field is ignored when authenticated=true.
    "error": "Credentials are expired"
  }
}

身份验证代理

可以配置 API 服务器以从请求头值（例如 X-Remote-User）中识别用户。它旨在与身份验证代理结合使用，后者设置请求头值。

  • --requestheader-username-headers：必填，不区分大小写。要检查的用户身份的标头名称，按顺序排列。第一个包含值的标头用作用户名。
  • --requestheader-group-headers：1.6+。可选，不区分大小写。建议使用“X-Remote-Group”。要检查的用户组的标头名称，按顺序排列。所有指定标头中的所有值都用作组名称。
  • --requestheader-extra-headers-prefix：1.6+。可选，不区分大小写。建议使用“X-Remote-Extra-”。要查找的标头前缀，以确定有关用户的额外信息（通常由配置的授权插件使用）。任何以任何指定前缀开头的标头都将删除该前缀。标头名称的其余部分将变为小写并进行 百分比解码，并成为额外的键，标头值是额外的值。

例如，使用此配置

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

此请求

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

将导致以下用户信息

name: fido
groups:
- dogs
- dachshunds
extra:
  acme.com/project:
  - some-project
  scopes:
  - openid
  - profile

为了防止标头欺骗，身份验证代理需要在检查请求头之前，向 API 服务器提供有效的客户端证书，以根据指定的 CA 进行验证。警告：不要 重用在其他上下文中使用的 CA，除非您了解风险以及保护 CA 使用的机制。

  • --requestheader-client-ca-file：必填。PEM 编码的证书捆绑包。在检查请求头以获取用户名之前，必须提供有效的客户端证书并根据指定文件中的证书颁发机构进行验证。
  • --requestheader-allowed-names：可选。通用名称值 (CN) 列表。如果设置，则必须提供在指定列表中具有 CN 的有效客户端证书，然后才能检查请求头以获取用户名。如果为空，则允许任何 CN。

匿名请求

启用后，未被其他配置的身份验证方法拒绝的请求将被视为匿名请求，并被赋予用户名 system:anonymous 和组 system:unauthenticated。

例如，在配置了令牌身份验证并且启用了匿名访问的服务器上，提供无效持有者令牌的请求将收到 401 Unauthorized 错误。不提供持有者令牌的请求将被视为匿名请求。

在 1.5.1-1.5.x 中，默认情况下禁用匿名访问，可以通过将 --anonymous-auth=true 选项传递给 API 服务器来启用。

在 1.6+ 中，如果使用 AlwaysAllow 以外的授权模式，则默认启用匿名访问，并且可以通过将 --anonymous-auth=false 选项传递给 API 服务器来禁用。从 1.6 开始，ABAC 和 RBAC 授权器需要显式授权 system:anonymous 用户或 system:unauthenticated 组，因此向 * 用户或 * 组授予访问权限的旧策略规则不包括匿名用户。

匿名身份验证器配置

功能状态： Kubernetes v1.32 [beta]（默认启用：true）

可以使用 AuthenticationConfiguration 配置匿名身份验证器。如果您在 AuthenticationConfiguration 文件中设置了匿名字段，则不能设置 --anonymous-auth 标志。

使用身份验证配置文件配置匿名身份验证器的主要优点是，除了启用和禁用匿名身份验证之外，您还可以配置哪些端点支持匿名身份验证。

下面是一个示例身份验证配置文件

---
#
# CAUTION: this is an example configuration.
#          Do not use this for your own cluster!
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

在上述配置中，只有 /livez、/readyz 和 /healthz 端点可以由匿名请求访问。即使 RBAC 配置允许，任何其他端点都无法访问。

用户模拟

用户可以通过模拟标头充当另一个用户。这些标头允许请求手动覆盖请求进行身份验证的用户信息。例如，管理员可以使用此功能来调试授权策略，方法是暂时模拟另一个用户，看看是否拒绝了请求。

模拟请求首先以请求用户身份进行身份验证，然后切换到模拟的用户信息。

  • 用户使用其凭据和模拟标头发出 API 调用。
  • API 服务器对用户进行身份验证。
  • API 服务器确保经过身份验证的用户具有模拟权限。
  • 请求用户信息将替换为模拟值。
  • 对请求进行评估，授权操作作用于模拟的用户信息。

可以使用以下 HTTP 标头来执行模拟请求

  • Impersonate-User：要充当的用户名。
  • Impersonate-Group：要充当的组名称。可以多次提供以设置多个组。可选。需要“Impersonate-User”。
  • Impersonate-Extra-( 额外名称 )：用于将额外字段与用户关联的动态标头。可选。需要“Impersonate-User”。为了始终保持一致，( 额外名称 ) 必须是小写的，并且任何不是 HTTP 标头标签中合法的字符 必须是 utf8 且经过 百分比编码。
  • Impersonate-Uid：表示被模拟用户的唯一标识符。可选。需要“Impersonate-User”。Kubernetes 对此字符串不施加任何格式要求。

以下示例展示了在模拟具有组的用户时使用的模拟标头

Impersonate-User: [email protected]
Impersonate-Group: developers
Impersonate-Group: admins

以下示例展示了在模拟具有 UID 和额外字段的用户时使用的模拟标头

Impersonate-User: [email protected]
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-acme.com%2Fproject: some-project
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
Impersonate-Uid: 06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b

当使用 kubectl 时，设置 --as 标志来配置 Impersonate-User 标头，设置 --as-group 标志来配置 Impersonate-Group 标头。

kubectl drain mynode

Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)

设置 --as 和 --as-group 标志

kubectl drain mynode --as=superman --as-group=system:masters

node/mynode cordoned
node/mynode drained

要模拟用户、组、用户标识符 (UID) 或额外字段，模拟用户必须具有对正在模拟的属性类型（“user”、“group”、“uid” 等）执行 “impersonate” 动词的能力。对于启用 RBAC 授权插件的集群，以下 ClusterRole 包含设置用户和组模拟标头所需的规则

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: impersonator
rules:
- apiGroups: [""]
  resources: ["users", "groups", "serviceaccounts"]
  verbs: ["impersonate"]

对于模拟，额外的字段和被模拟的 UID 都属于 "authentication.k8s.io" apiGroup。额外字段被评估为资源 “userextras” 的子资源。要允许用户对额外字段 “scopes” 和 UID 使用模拟标头，应授予用户以下角色

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scopes-and-uid-impersonator
rules:
# Can set "Impersonate-Extra-scopes" header and the "Impersonate-Uid" header.
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes", "uids"]
  verbs: ["impersonate"]

模拟标头的值也可以通过限制资源可以采用的 resourceNames 集合来限制。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
# Can impersonate the user "[email protected]"
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["[email protected]"]

# Can impersonate the groups "developers" and "admins"
- apiGroups: [""]
  resources: ["groups"]
  verbs: ["impersonate"]
  resourceNames: ["developers","admins"]

# Can impersonate the extras field "scopes" with the values "view" and "development"
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes"]
  verbs: ["impersonate"]
  resourceNames: ["view", "development"]

# Can impersonate the uid "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
- apiGroups: ["authentication.k8s.io"]
  resources: ["uids"]
  verbs: ["impersonate"]
  resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]

client-go 凭据插件

功能状态： Kubernetes v1.22 [稳定版]

k8s.io/client-go 和使用它的工具（如 kubectl 和 kubelet）能够执行外部命令以接收用户凭据。

此功能旨在用于与 k8s.io/client-go 本机不支持的身份验证协议（LDAP、Kerberos、OAuth2、SAML 等）的客户端集成。该插件实现特定于协议的逻辑，然后返回要使用的不透明凭据。几乎所有凭据插件用例都需要服务器端组件，该组件支持 webhook 令牌身份验证器来解释客户端插件生成的凭据格式。

用例示例

在一个假设的用例中，组织将运行一个外部服务，该服务将 LDAP 凭据交换为用户特定的签名令牌。该服务还能够响应 webhook 令牌身份验证器请求以验证令牌。用户将需要在其工作站上安装凭据插件。

要针对 API 进行身份验证

  • 用户发出 kubectl 命令。
  • 凭据插件提示用户输入 LDAP 凭据，与外部服务交换凭据以获取令牌。
  • 凭据插件将令牌返回给 client-go，后者将其用作针对 API 服务器的持有者令牌。
  • API 服务器使用 webhook 令牌身份验证器向外部服务提交 TokenReview。
  • 外部服务验证令牌上的签名，并返回用户的用户名和组。

配置

凭据插件通过 kubectl 配置文件配置为用户字段的一部分。

apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # Command to execute. Required.
      command: "example-client-go-exec-plugin"

      # API version to use when decoding the ExecCredentials resource. Required.
      #
      # The API version returned by the plugin MUST match the version listed here.
      #
      # To integrate with tools that support multiple versions (such as client.authentication.k8s.io/v1beta1),
      # set an environment variable, pass an argument to the tool that indicates which version the exec plugin expects,
      # or read the version from the ExecCredential object in the KUBERNETES_EXEC_INFO environment variable.
      apiVersion: "client.authentication.k8s.io/v1"

      # Environment variables to set when executing the plugin. Optional.
      env:
      - name: "FOO"
        value: "bar"

      # Arguments to pass when executing the plugin. Optional.
      args:
      - "arg1"
      - "arg2"

      # Text shown to the user when the executable doesn't seem to be present. Optional.
      installHint: |
        example-client-go-exec-plugin is required to authenticate
        to the current cluster.  It can be installed:

        On macOS: brew install example-client-go-exec-plugin

        On Ubuntu: apt-get install example-client-go-exec-plugin

        On Fedora: dnf install example-client-go-exec-plugin

        ...        

      # Whether or not to provide cluster information, which could potentially contain
      # very large CA data, to this exec plugin as a part of the KUBERNETES_EXEC_INFO
      # environment variable.
      provideClusterInfo: true

      # The contract between the exec plugin and the standard input I/O stream. If the
      # contract cannot be satisfied, this plugin will not be run and an error will be
      # returned. Valid values are "Never" (this exec plugin never uses standard input),
      # "IfAvailable" (this exec plugin wants to use standard input if it is available),
      # or "Always" (this exec plugin requires standard input to function). Required.
      interactiveMode: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
      extension:
        arbitrary: config
        this: can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo
        you: ["can", "put", "anything", "here"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster


apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # Command to execute. Required.
      command: "example-client-go-exec-plugin"

      # API version to use when decoding the ExecCredentials resource. Required.
      #
      # The API version returned by the plugin MUST match the version listed here.
      #
      # To integrate with tools that support multiple versions (such as client.authentication.k8s.io/v1),
      # set an environment variable, pass an argument to the tool that indicates which version the exec plugin expects,
      # or read the version from the ExecCredential object in the KUBERNETES_EXEC_INFO environment variable.
      apiVersion: "client.authentication.k8s.io/v1beta1"

      # Environment variables to set when executing the plugin. Optional.
      env:
      - name: "FOO"
        value: "bar"

      # Arguments to pass when executing the plugin. Optional.
      args:
      - "arg1"
      - "arg2"

      # Text shown to the user when the executable doesn't seem to be present. Optional.
      installHint: |
        example-client-go-exec-plugin is required to authenticate
        to the current cluster.  It can be installed:

        On macOS: brew install example-client-go-exec-plugin

        On Ubuntu: apt-get install example-client-go-exec-plugin

        On Fedora: dnf install example-client-go-exec-plugin

        ...        

      # Whether or not to provide cluster information, which could potentially contain
      # very large CA data, to this exec plugin as a part of the KUBERNETES_EXEC_INFO
      # environment variable.
      provideClusterInfo: true

      # The contract between the exec plugin and the standard input I/O stream. If the
      # contract cannot be satisfied, this plugin will not be run and an error will be
      # returned. Valid values are "Never" (this exec plugin never uses standard input),
      # "IfAvailable" (this exec plugin wants to use standard input if it is available),
      # or "Always" (this exec plugin requires standard input to function). Optional.
      # Defaults to "IfAvailable".
      interactiveMode: Never
clusters:
- name: my-cluster
  cluster:
    server: "https://172.17.4.100:6443"
    certificate-authority: "/etc/kubernetes/ca.pem"
    extensions:
    - name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
      extension:
        arbitrary: config
        this: can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo
        you: ["can", "put", "anything", "here"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster

相对命令路径被解释为相对于配置文件的目录。如果 KUBECONFIG 设置为 /home/jane/kubeconfig，并且 exec 命令是 ./bin/example-client-go-exec-plugin，则会执行二进制文件 /home/jane/bin/example-client-go-exec-plugin。

- name: my-user
  user:
    exec:
      # Path relative to the directory of the kubeconfig
      command: "./bin/example-client-go-exec-plugin"
      apiVersion: "client.authentication.k8s.io/v1"
      interactiveMode: Never

输入和输出格式

执行的命令将 ExecCredential 对象打印到 stdout。k8s.io/client-go 使用 status 中返回的凭据针对 Kubernetes API 进行身份验证。执行的命令通过 KUBERNETES_EXEC_INFO 环境变量传递一个 ExecCredential 对象作为输入。此输入包含有用的信息，例如返回的 ExecCredential 对象的预期 API 版本，以及插件是否可以使用 stdin 与用户交互。

从交互式会话（即终端）运行时，可以将 stdin 直接暴露给插件。插件应使用来自 KUBERNETES_EXEC_INFO 环境变量的输入 ExecCredential 对象的 spec.interactive 字段，以确定是否提供了 stdin。插件的 stdin 要求（即，为了插件成功运行，stdin 是可选的、严格要求的还是从不使用的）通过 kubeconfig 中的 user.exec.interactiveMode 字段声明（有关有效值，请参见下表）。user.exec.interactiveMode 字段在 client.authentication.k8s.io/v1beta1 中是可选的，在 client.authentication.k8s.io/v1 中是必需的。

interactiveMode 值
interactiveMode 值含义
Never此 exec 插件永远不需要使用标准输入，因此无论标准输入是否可用于用户输入，都将运行该 exec 插件。
IfAvailable如果标准输入可用，则此 exec 插件希望使用标准输入，但如果标准输入不可用，仍然可以运行。因此，无论标准输入是否可用于用户输入，都将运行该 exec 插件。如果标准输入可用于用户输入，则会将其提供给此 exec 插件。
Always此 exec 插件需要标准输入才能运行，因此只有当标准输入可用于用户输入时，才会运行该 exec 插件。如果标准输入不可用于用户输入，则不会运行该 exec 插件，并且 exec 插件运行器将返回错误。

要使用持有者令牌凭据，插件会在 ExecCredential 的状态中返回一个令牌。

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}

或者，可以返回 PEM 编码的客户端证书和密钥以使用 TLS 客户端身份验证。如果插件在后续调用中返回不同的证书和密钥，k8s.io/client-go 将关闭与服务器的现有连接，以强制执行新的 TLS 握手。

如果指定，则 clientKeyData 和 clientCertificateData 都必须存在。

clientCertificateData 可以包含要发送到服务器的其他中间证书。

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "clientCertificateData": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    "clientKeyData": "-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
  }
}

（可选）响应可以包括凭据的到期时间，格式为 RFC 3339 时间戳。

是否存在到期时间有以下影响

  • 如果包含到期时间，则持有者令牌和 TLS 凭据将缓存到达到到期时间，或者如果服务器响应 401 HTTP 状态代码，或者当进程退出时为止。
  • 如果省略到期时间，则持有者令牌和 TLS 凭据将缓存到服务器响应 401 HTTP 状态代码或直到进程退出为止。

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token",
    "expirationTimestamp": "2018-03-05T17:30:20-08:00"
  }
}

要使 exec 插件能够获取特定于集群的信息，请在 kubeconfig 中的 user.exec 字段上设置 provideClusterInfo。然后，插件将在此 KUBERNETES_EXEC_INFO 环境变量中获得此特定于集群的信息。来自此环境变量的信息可用于执行特定于集群的凭据获取逻辑。以下 ExecCredential 清单描述了集群信息示例。

{
  "apiVersion": "client.authentication.k8s.io/v1",
  "kind": "ExecCredential",
  "spec": {
    "cluster": {
      "server": "https://172.17.4.100:6443",
      "certificate-authority-data": "LS0t...",
      "config": {
        "arbitrary": "config",
        "this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
        "you": ["can", "put", "anything", "here"]
      }
    },
    "interactive": true
  }
}


{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "spec": {
    "cluster": {
      "server": "https://172.17.4.100:6443",
      "certificate-authority-data": "LS0t...",
      "config": {
        "arbitrary": "config",
        "this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
        "you": ["can", "put", "anything", "here"]
      }
    },
    "interactive": true
  }
}

客户端对身份验证信息的 API 访问

功能状态： Kubernetes v1.28 [稳定版]

如果您的集群启用了 API，则可以使用 SelfSubjectReview API 来查找 Kubernetes 集群如何将您的身份验证信息映射以将您识别为客户端。无论您是以用户（通常代表真实的人）还是以 ServiceAccount 进行身份验证，这都有效。

SelfSubjectReview 对象没有任何可配置的字段。在收到请求时，Kubernetes API 服务器会使用用户属性填充状态并将其返回给用户。

请求示例（正文将是 SelfSubjectReview）

POST /apis/authentication.k8s.io/v1/selfsubjectreviews

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview"
}

响应示例

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "name": "jane.doe",
      "uid": "b6c7cfd4-f166-11ec-8ea0-0242ac120002",
      "groups": [
        "viewers",
        "editors",
        "system:authenticated"
      ],
      "extra": {
        "provider_id": ["token.company.example"]
      }
    }
  }
}

为方便起见，提供了 kubectl auth whoami 命令。执行此命令将产生以下输出（但会显示不同的用户属性）

  • 简单输出示例

    ATTRIBUTE         VALUE
Username          jane.doe
Groups            [system:authenticated]

  • 包含额外属性的复杂示例

    ATTRIBUTE         VALUE
Username          jane.doe
UID               b79dbf30-0c6a-11ed-861d-0242ac120002
Groups            [students teachers system:authenticated]
Extra: skills     [reading learning]
Extra: subjects   [math sports]

通过提供输出标志，还可以打印结果的 JSON 或 YAML 表示形式

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "SelfSubjectReview",
  "status": {
    "userInfo": {
      "username": "jane.doe",
      "uid": "b79dbf30-0c6a-11ed-861d-0242ac120002",
      "groups": [
        "students",
        "teachers",
        "system:authenticated"
      ],
      "extra": {
        "skills": [
          "reading",
          "learning"
        ],
        "subjects": [
          "math",
          "sports"
        ]
      }
    }
  }
}


apiVersion: authentication.k8s.io/v1
kind: SelfSubjectReview
status:
  userInfo:
    username: jane.doe
    uid: b79dbf30-0c6a-11ed-861d-0242ac120002
    groups:
    - students
    - teachers
    - system:authenticated
    extra:
      skills:
      - reading
      - learning
      subjects:
      - math
      - sports

当 Kubernetes 集群中使用复杂的身份验证流程时，此功能非常有用，例如，如果您使用 webhook 令牌身份验证或 身份验证代理。

默认情况下，当启用 APISelfSubjectReview 功能时，所有经过身份验证的用户都可以创建 SelfSubjectReview 对象。system:basic-user 集群角色允许这样做。

下一步

上次修改时间为太平洋标准时间 2024 年 9 月 4 日下午 2:48：KEP-4633：晋升为 BETA。(7a1cdab150)