API 访问控制

• 1: 用户认证
• 2: 使用启动引导令牌（Bootstrap Tokens）认证
• 3: 鉴权
• 4: 使用 RBAC 鉴权
• 5: 使用 Node 鉴权
• 6: Webhook 模式
• 7: 使用 ABAC 鉴权
• 8: Kubernetes 中的准入控制
• 9: 动态准入控制
• 10: 管理服务账号
• 11: 证书和证书签名请求
• 12: 从 PodSecurityPolicy 映射到 Pod 安全性标准
• 13: Kubelet 认证/鉴权
• 14: TLS 启动引导
• 15: 验证准入策略（ValidatingAdmissionPolicy）

1 - 用户认证

本页提供身份认证有关的概述。

Kubernetes 中的用户

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

Kubernetes 假定普通用户是由一个与集群无关的服务通过以下方式之一进行管理的：

• 负责分发私钥的管理员
• 类似 Keystone 或者 Google Accounts 这类用户数据库
• 包含用户名和密码列表的文件

有鉴于此，Kubernetes 并不包含用来代表普通用户账号的对象。 普通用户的信息无法通过 API 调用添加到集群中。

尽管无法通过 API 调用来添加普通用户， Kubernetes 仍然认为能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。 基于这样的配置，Kubernetes 使用证书中的 'subject' 的通用名称（Common Name）字段 （例如，"/CN=bob"）来确定用户名。 接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对某资源执行特定的操作。 进一步的细节可参阅证书请求 下普通用户主题。

与此不同，服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间， 或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。

API 请求则或者与某普通用户相关联，或者与某服务账号相关联， 亦或者被视作匿名请求。这意味着集群内外的每个进程在向 API 服务器发起请求时都必须通过身份认证，否则会被视作匿名用户。这里的进程可以是在某工作站上输入 kubectl 命令的操作人员，也可以是节点上的 kubelet 组件，还可以是控制面的成员。

身份认证策略

Kubernetes 通过身份认证插件利用客户端证书、持有者令牌（Bearer Token）或身份认证代理（Proxy） 来认证 API 请求的身份。HTTP 请求发给 API 服务器时，插件会将以下属性关联到请求本身：

• 用户名：用来辩识最终用户的字符串。常见的值可以是 kube-admin 或 jane@example.com。
• 用户 ID：用来辩识最终用户的字符串，旨在比用户名有更好的一致性和唯一性。
• 用户组：取值为一组字符串，其中各个字符串用来标明用户是某个命名的用户逻辑集合的成员。 常见的值可能是 system:masters 或者 devops-team 等。
• 附加字段：一组额外的键-值映射，键是字符串，值是一组字符串； 用来保存一些鉴权组件可能觉得有用的额外信息。

所有（属性）值对于身份认证系统而言都是不透明的， 只有被鉴权组件解释过之后才有意义。

你可以同时启用多种身份认证方法，并且你通常会至少使用两种方法：

• 针对服务账号使用服务账号令牌
• 至少另外一种方法对用户的身份进行认证

当集群中启用了多个身份认证模块时，第一个成功地对请求完成身份认证的模块会直接做出评估决定。 API 服务器并不保证身份认证模块的运行顺序。

对于所有通过身份认证的用户，system:authenticated 组都会被添加到其组列表中。

与其它身份认证协议（LDAP、SAML、Kerberos、X509 的替代模式等等） 都可以通过使用一个身份认证代理或身份认证 Webhoook 来实现。

X509 客户证书

通过给 API 服务器传递 --client-ca-file=SOMEFILE 选项，就可以启动客户端证书身份认证。 所引用的文件必须包含一个或者多个证书机构，用来验证向 API 服务器提供的客户端证书。 如果提供了客户端证书并且证书被验证通过，则 subject 中的公共名称（Common Name） 就被作为请求的用户名。 自 Kubernetes 1.4 开始，客户端证书还可以通过证书的 organization 字段标明用户的组成员信息。 要包含用户的多个组成员信息，可以在证书中包含多个 organization 字段。

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

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

此命令将使用用户名 jbeda 生成一个证书签名请求（CSR），且该用户属于 "app1" 和 "app2" 两个用户组。

参阅管理证书了解如何生成客户端证书。

静态令牌文件

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

令牌文件是一个 CSV 文件，包含至少 3 个列：令牌、用户名和用户的 UID。 其余列被视为可选的组名。

token,user,uid,"group1,group2,group3"

在请求中放入持有者令牌

当使用持有者令牌来对某 HTTP 客户端执行身份认证时，API 服务器希望看到一个名为 Authorization 的 HTTP 头，其值格式为 Bearer <token>。 持有者令牌必须是一个可以放入 HTTP 头部值字段的字符序列，至多可使用 HTTP 的编码和引用机制。 例如：如果持有者令牌为 31ada4fd-adec-460c-809a-9e56ceb75269，则其出现在 HTTP 头部时如下所示：

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

启动引导令牌

为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型， 称作 启动引导令牌（Bootstrap Token）。 这些令牌以 Secret 的形式保存在 kube-system 名字空间中，可以被动态管理和创建。 控制器管理器包含的 TokenCleaner 控制器能够在启动引导令牌过期时将其删除。

这些令牌的格式为 [a-z0-9]{6}.[a-z0-9]{16}。第一个部分是令牌的 ID； 第二个部分是令牌的 Secret。你可以用如下所示的方式来在 HTTP 头部设置令牌：

Authorization: Bearer 781292.db7bc3a58fc5f07e

你必须在 API 服务器上设置 --enable-bootstrap-token-auth 标志来启用基于启动引导令牌的身份认证组件。 你必须通过控制器管理器的 --controllers 标志来启用 TokenCleaner 控制器； 这可以通过类似 --controllers=*,tokencleaner 这种设置来做到。 如果你使用 kubeadm 来启动引导新的集群，该工具会帮你完成这些设置。

身份认证组件的认证结果为 system:bootstrap:<令牌 ID>，该用户属于 system:bootstrappers 用户组。 这里的用户名和组设置都是有意设计成这样，其目的是阻止用户在启动引导集群之后继续使用这些令牌。 这里的用户名和组名可以用来（并且已经被 kubeadm 用来）构造合适的鉴权策略， 以完成启动引导新集群的工作。

请参阅启动引导令牌， 以了解关于启动引导令牌身份认证组件与控制器的更深入的信息，以及如何使用 kubeadm 来管理这些令牌。

服务账号令牌

服务账号（Service Account）是一种自动被启用的用户认证机制，使用经过签名的持有者令牌来验证请求。 该插件可接受两个可选参数：

• --service-account-key-file 文件包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥， 用于验证 ServiceAccount 令牌。这样指定的文件可以包含多个密钥， 并且可以使用不同的文件多次指定此参数。若未指定，则使用 --tls-private-key-file 参数。
• --service-account-lookup 如果启用，则从 API 删除的令牌会被回收。

服务账号通常由 API 服务器自动创建并通过 ServiceAccount 准入控制器关联到集群中运行的 Pod 上。 持有者令牌会挂载到 Pod 中可预知的位置，允许集群内进程与 API 服务器通信。 服务账号也可以使用 Pod 规约的 serviceAccountName 字段显式地关联到 Pod 上。

apiVersion: apps/v1 # 此 apiVersion 从 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 <名称> 命令。 此命令会在当前的名字空间中生成一个服务账号。

kubectl create serviceaccount jenkins

serviceaccount/jenkins created

创建相关联的令牌：

kubectl create token jenkins

eyJhbGciOiJSUzI1NiIsImtp...

所创建的令牌是一个已签名的 JWT 令牌。

已签名的 JWT 可以用作持有者令牌，并将被认证为所给的服务账号。 关于如何在请求中包含令牌，请参阅前文。 通常，这些令牌数据会被挂载到 Pod 中以便集群内访问 API 服务器时使用， 不过也可以在集群外部使用。

服务账号被身份认证后，所确定的用户名为 system:serviceaccount:<名字空间>:<服务账号>， 并被分配到用户组 system:serviceaccounts 和 system:serviceaccounts:<名字空间>。

OpenID Connect（OIDC）令牌

OpenID Connect 是一种 OAuth2 认证方式， 被某些 OAuth2 提供者支持，例如 Microsoft Entra ID、Salesforce 和 Google。 协议对 OAuth2 的主要扩充体现在有一个附加字段会和访问令牌一起返回， 这一字段称作 ID Token（ID 令牌）。 ID 令牌是一种由服务器签名的 JWT 令牌，其中包含一些可预知的字段， 例如用户的邮箱地址，

要识别用户，身份认证组件使用 OAuth2 令牌响应中的 id_token（而非 access_token）作为持有者令牌。 关于如何在请求中设置令牌，可参见前文。

1. 登录到你的身份服务（Identity Provider）

2. 你的身份服务将为你提供 access_token、id_token 和 refresh_token

3. 在使用 kubectl 时，将 id_token 设置为 --token 标志值，或者将其直接添加到 kubeconfig 中

4. kubectl 将你的 id_token 放到一个称作 Authorization 的头部，发送给 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 服务器上配置以下标志：

来自文件的身份认证配置

JWT Authenticator 是一个使用 JWT 兼容令牌对 Kubernetes 用户进行身份认证的认证组件。 认证组件将尝试解析原始 ID 令牌，验证它是否是由所配置的颁发者签名。 用于验证签名的公钥是使用 OIDC 发现从发行者的公共端点发现的。

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

{
  "iss": "https://example.com",   // 必须与 issuer.url 匹配
  "aud": ["my-app"],              // issuer.audiences 中至少一项必须与所提供的 JWT 中的 "aud" 声明相匹配。
  "exp": 1234567890,              // 令牌过期时间为 UNIX 时间（自 1970 年 1 月 1 日 UTC 以来经过的秒数）
  "<username-claim>": "user"      // 这是在 claimMappings.username.claim 或 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 命令行参数来启用结构化身份认证。 下面给出的是一个结构化身份认证配置文件的示例：

---
#
# 注意：这是一个示例配置，不要将其用于你自己的集群！
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# 使用 JWT 兼容令牌对 Kubernetes 用户进行身份认证的认证组件列表，允许的最大认证组件数量为 64。
jwt:
- issuer:
    # url 在所有认证组件中必须是唯一的。
    # url 不得与 --service-account-issuer 中配置的颁发者冲突。
    url: https://example.com # 与 --oidc-issuer-url 一致。
    # discoveryURL（如果指定）将覆盖用于获取发现信息的 URL，而不是使用 “{url}/.well-known/openid-configuration”。
    # 系统会使用所给的配置值，因此如果需要，“/.well-known/openid-configuration” 必须包含在 discoveryURL 中。
    #
    # 取回的发现信息中的 “issuer” 字段必须与 AuthenticationConfiguration 中的
    # “issuer.url” 字段匹配，并被用于验证所呈现的 JWT 中的 “iss” 声明。
    # 这适用于众所周知的端点和 jwks 端点托管在与颁发者不同的位置（例如集群本地）的场景。
    # discoveryURL 必须与 url 不同（如果指定），并且在所有认证组件中必须是唯一的。
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    # PEM 编码的 CA 证书用于在获取发现信息时验证连接。
    # 如果未设置，将使用系统验证程序。
    # 与 --oidc-ca-file 标志引用的文件内容的值相同。
    certificateAuthority: <PEM encoded CA certificates>    
    # audiences 是 JWT 必须发布给的一组可接受的受众。
    # 至少其中一项必须与所提供的 JWT 中的 “aud” 声明相匹配。
    audiences:
    - my-app # 与 --oidc-client-id 一致。
    - my-other-app
    # 当指定多个受众时，需要将此字段设置为 “MatchAny”。
    audienceMatchPolicy: MatchAny
  # 用于验证令牌声明以对用户进行身份认证的规则。
  claimValidationRules:
    # 与 --oidc-required-claim key=value 一致
  - claim: hd
    requiredValue: example.com
    # 你可以使用表达式来验证声明，而不是仅仅靠 claim 和 requiredValue 来执行检查。
    # expression 是一个计算结果为布尔值的 CEL 表达式。
    # 所有表达式的计算结果必须为 true 才能使验证成功。
  - expression: 'claims.hd == "example.com"'
    # message 用来定制验证失败时在 API 服务器日志中看到的错误消息。
    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 表示用户名属性的选项。
    # 这是唯一必需的属性。
    username:
      # 与 --oidc-username-claim 相同，与 username.expression 互斥。
      claim: "sub"
      # 与 --oidc-username-prefix 相同，与 username.expression 互斥。
      # 如果设置了username.claim，则需要username.prefix。
      # 如果不需要前缀，可显式将其设置为 ""。
      prefix: ""
      # 与 username.claim 和 username.prefix 互斥。
      # expression 是计算结果为字符串的 CEL 表达式。
      #
      # 1.  如果 username.expression 使用 “claims.email”，则必须在 username.expression
      #     或 extra[*].valueExpression 或 ClaimValidationRules[*].expression 中使用 “claims.email_verified”。
      #     与 username.claim 设置为 “email” 时自动应用的验证相匹配的示例声明验证规则表达式是
      #     “claims.?email_verified.orValue(true)”。
      # 2.  如果根据 username.expression 断言的用户名是空字符串，则身份认证请求将失败。
      expression: 'claims.username + ":external-user"'
    # groups 代表 groups 属性的一个选项。
    groups:
      # 与 --oidc-groups-claim 相同，与 groups.express 互斥。
      claim: "sub"
      # 与 --oidc-groups-prefix 相同。与 groups.express 互斥。
      # 如果设置了 groups.claim，则需要 groups.prefix。
      # 如果不需要前缀，则显式将其设置为 ""。
      prefix: ""
      # 与 groups.claim 和 groups.prefix 互斥。
      # expression 是一个计算结果为字符串或字符串列表的 CEL 表达式。
      expression: 'claims.roles.split(",")'
    # uid 表示 uid 属性的一个选项。
    uid:
      # 与 uid.expression 互斥。
      claim: 'sub'
      # 与 uid.claim 互斥
      # expression 是计算结果为字符串的 CEL 表达式。
      expression: 'claims.sub'
    # 要添加到 UserInfo 对象的其他属性，键必须是域前缀路径并且必须是唯一的。
    extra:
    - key: 'example.com/tenant'
      # valueExpression 是一个计算结果为字符串或字符串列表的 CEL 表达式。
      valueExpression: 'claims.tenant'
  # 应用于最终用户对象的验证规则。
  userValidationRules:
    # expression 是一个计算结果为布尔值的 CEL 表达式。
    # 所有表达式的计算结果必须为 true，用户才有效。
  - expression: "!user.username.startsWith('system:')"
    # Message 自定义验证失败时在 API 服务器日志中看到的错误消息。
    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](/zh-cn/docs/reference/ generated/kubernetes-api/v1.32/#userinfo-v1-authentication-k8s-io) 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” 示例。

  • Valid token
  • Fails claim validation
  • Fails user validation

  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:')" # 表达式的计算结果为 true，因此验证将成功。
      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"' # 下面的令牌没有此声明，因此验证将失败。
        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:')" # 该表达式的计算结果将为 true，因此验证将会成功。
        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' # 这将为用户名添加前缀 “system:”，并且用户验证将失败。
      groups:
        expression: 'claims.roles.split(",")'
      uid:
        expression: 'claims.sub'
      extra:
      - key: 'example.com/tenant'
        valueExpression: 'claims.tenant'
    userValidationRules:
    - expression: "!user.username.startsWith('system:')" # 用户名将为 system:foo 并且表达式将计算为 false，因此验证将失败。
      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 或者是自签名的）

关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。 如果你部署了自己的身份服务，而不是使用云厂商（如 Google 或 Microsoft）所提供的服务， 你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 CA 标志要设置为 TRUE，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证标准方面有非常严格的要求。 如果你手头没有现成的 CA 证书，可以使用 Dex 团队所开发的证书生成脚本 来创建一个简单的 CA 和被签了名的证书与密钥对。 或者你也可以使用这个类似的脚本， 生成一个合法期更长、密钥尺寸更大的 SHA256 证书。

参阅特定系统的安装指令：

• UAA
• Dex
• OpenUnison

使用 kubectl

选项一：OIDC 身份认证组件

第一种方案是使用 kubectl 的 oidc 身份认证组件，该组件将 id_token 设置为所有请求的持有者令牌， 并且在令牌过期时自动刷新。在你登录到你的身份服务之后， 可以使用 kubectl 来添加你的 id_token、refresh_token、client_id 和 client_secret，以配置该插件。

如果服务在其刷新令牌响应中不包含 id_token，则此插件无法支持该服务。 这时你应该考虑下面的选项二。

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 来刷新你的 id_token，并且在 .kube/config 文件的 client_secret 中存放 refresh_token 和 id_token 的新值。

选项二：使用 --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 用来设定身份认证决定的缓存时间。 默认时长为 2 分钟。
• --authentication-token-webhook-version 决定是使用 authentication.k8s.io/v1beta1 还是 authenticationk8s.io/v1 版本的 TokenReview 对象从 Webhook 发送/接收信息。 默认为“v1beta1”。

配置文件使用 kubeconfig 文件的格式。文件中，clusters 指代远程服务，users 指代远程 API 服务 Webhook。下面是一个例子：

# Kubernetes API 版本
apiVersion: v1
# API 对象类别
kind: Config
# clusters 指代远程服务
clusters:
  - name: name-of-remote-authn-service
    cluster:
      certificate-authority: /path/to/ca.pem         # 用来验证远程服务的 CA
      server: https://authn.example.com/authenticate # 要查询的远程服务 URL。生产环境中建议使用 'https'。

# users 指代 API 服务的 Webhook 配置
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # Webhook 插件要使用的证书
      client-key: /path/to/key.pem          # 与证书匹配的密钥

# kubeconfig 文件需要一个上下文（Context），此上下文用于本 API 服务器
current-context: webhook
contexts:
- context:
    cluster: name-of-remote-authn-service
    user: name-of-api-server
  name: webhook

当客户端尝试在 API 服务器上使用持有者令牌完成身份认证 （如前所述）时， 身份认证 Webhook 会用 POST 请求发送一个 JSON 序列化的对象到远程服务。 该对象是 TokenReview 对象，其中包含持有者令牌。 Kubernetes 不会强制请求提供此 HTTP 头部。

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

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "spec": {
   # 发送到 API 服务器的不透明持有者令牌
    "token": "014fbff9a07c...",
   
    # 提供令牌的服务器的受众标识符的可选列表。
    # 受众感知令牌认证组件（例如，OIDC 令牌认证组件）
    # 应验证令牌是否针对此列表中的至少一个受众，
    # 并返回此列表与响应状态中令牌的有效受众的交集。
    # 这确保了令牌对于向其提供给的服务器进行身份认证是有效的。
    # 如果未提供受众，则应验证令牌以向 Kubernetes API 服务器进行身份认证。
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
    # 发送到 API 服务器的不透明匿名令牌
    "token": "014fbff9a07c...",
   
    # 提供令牌的服务器的受众标识符的可选列表。
    # 受众感知令牌认证组件（例如，OIDC 令牌认证组件）
    # 应验证令牌是否针对此列表中的至少一个受众，
    # 并返回此列表与响应状态中令牌的有效受众的交集。
    # 这确保了令牌对于向其提供给的服务器进行身份认证是有效的。
    # 如果未提供受众，则应验证令牌以向 Kubernetes API 服务器进行身份认证。
    "audiences": ["https://myserver.example.com", "https://myserver.internal.example.com"]
  }
}

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

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # 必要
      "username": "janedoe@example.com",
      # 可选
      "uid": "42",
      # 可选的组成员身份
      "groups": ["developers", "qa"],
      # 认证者提供的可选附加信息。
      # 此字段不可包含机密数据，因为这类数据可能被记录在日志或 API 对象中，
      # 并且可能传递给 admission webhook。
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # 认证组件可以返回的、可选的用户感知令牌列表，
    # 包含令牌对其有效的、包含于 `spec.audiences` 列表中的受众。
    # 如果省略，则认为该令牌可用于对 Kubernetes API 服务器进行身份认证。
    "audiences": ["https://myserver.example.com"]
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": true,
    "user": {
      # 必要
      "username": "janedoe@example.com",
      # 可选
      "uid": "42",
      # 可选的组成员身份
      "groups": ["developers", "qa"],
      # 认证者提供的可选附加信息。
      # 此字段不可包含机密数据，因为这类数据可能被记录在日志或 API 对象中，
      # 并且可能传递给 admission webhook。
      "extra": {
        "extrafield1": [
          "extravalue1",
          "extravalue2"
        ]
      }
    },
    # 认证组件可以返回的、可选的用户感知令牌列表，
    # 包含令牌对其有效的、包含于 `spec.audiences` 列表中的受众。
    # 如果省略，则认为该令牌可用于对 Kubernetes API 服务器进行身份认证。
    "audiences": ["https://myserver.example.com"]
  }
}

而不成功的请求会返回：

• authentication.k8s.io/v1
• authentication.k8s.io/v1beta1

{
  "apiVersion": "authentication.k8s.io/v1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # 可选地包括有关身份认证失败原因的详细信息。
    # 如果没有提供错误信息，API 将返回一个通用的 Unauthorized 消息。
    # 当 authenticated=true 时，error 字段被忽略。
    "error": "Credentials are expired"
  }
}

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "status": {
    "authenticated": false,
    # 可选地包括有关身份认证失败原因的详细信息。
    # 如果没有提供错误信息，API 将返回一个通用的 Unauthorized 消息。
    # 当 authenticated=true 时，error 字段被忽略。
    "error": "Credentials are expired"
  }
}

身份认证代理

API 服务器可以配置成从请求的头部字段值（如 X-Remote-User）中辩识用户。 这一设计是用来与某身份认证代理一起使用 API 服务器，代理负责设置请求的头部字段值。

• --requestheader-username-headers 必需字段，大小写不敏感。 用来设置要获得用户身份所要检查的头部字段名称列表（有序）。 第一个包含数值的字段会被用来提取用户名。
• --requestheader-group-headers 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。 建议设置为 "X-Remote-Group"。用来指定一组头部字段名称列表，以供检查用户所属的组名称。 所找到的全部头部字段的取值都会被用作用户组名。
• --requestheader-extra-headers-prefix 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。 建议设置为 "X-Remote-Extra-"。用来设置一个头部字段的前缀字符串， API 服务器会基于所给前缀来查找与用户有关的一些额外信息。这些额外信息通常用于所配置的鉴权插件。 API 服务器会将与所给前缀匹配的头部字段过滤出来，去掉其前缀部分，将剩余部分转换为小写字符串， 并在必要时执行百分号解码后， 构造新的附加信息字段键名。原来的头部字段值直接作为附加信息字段的值。

例如，使用下面的配置：

--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 名的、合法的客户端证书。

匿名请求

启用匿名请求支持之后，如果请求没有被已配置的其他身份认证方法拒绝， 则被视作匿名请求（Anonymous Requests）。这类请求获得用户名 system:anonymous 和对应的用户组 system:unauthenticated。

例如，在一个配置了令牌身份认证且启用了匿名访问的服务器上，如果请求提供了非法的持有者令牌， 则会返回 401 Unauthorized 错误。如果请求没有提供持有者令牌，则被视为匿名请求。

在 1.5.1-1.5.x 版本中，匿名访问默认情况下是被禁用的，可以通过为 API 服务器设定 --anonymous-auth=true 来启用。

在 1.6 及之后版本中，如果所使用的鉴权模式不是 AlwaysAllow，则匿名访问默认是被启用的。 从 1.6 版本开始，ABAC 和 RBAC 鉴权模块要求对 system:anonymous 用户或者 system:unauthenticated 用户组执行显式的权限判定，所以之前的为用户 * 或用户组 * 赋予访问权限的策略规则都不再包含匿名用户。

匿名身份认证模块配置

AuthenticationConfiguration 可用于配置匿名身份认证模块。 要通过配置文件启用匿名身份认证配置，你需要启用 AnonymousAuthConfigurableEndpoints 特性门控。 当此特性门控被启用时，你不能设置 --anonymous-auth 标志。

使用身份认证配置文件来配置匿名身份认证模块的主要优点是， 除了启用和禁用匿名身份认证外，你还可以配置哪些端点支持匿名身份认证。

以下是一个身份认证配置文件示例：

---
#
# 注意：这是一个示例配置。
#      请勿将其用于你自己的集群！
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

在上述配置中，只有 /livez、/readyz 和 /healthz 端点可以通过匿名请求进行访问。 即使 RBAC 配置允许进行匿名请求，也不可以访问任何其他端点。

用户伪装

一个用户可以通过伪装（Impersonation）头部字段来以另一个用户的身份执行操作。 使用这一能力，你可以手动重载请求被身份认证所识别出来的用户信息。 例如，管理员可以使用这一功能特性来临时伪装成另一个用户，查看请求是否被拒绝， 从而调试鉴权策略中的问题，

带伪装的请求首先会被身份认证识别为发出请求的用户， 之后会切换到使用被伪装的用户的用户信息。

• 用户发起 API 调用时同时提供自身的凭据和伪装头部字段信息。
• API 服务器对用户执行身份认证。
• API 服务器确认通过认证的用户具有伪装特权。
• 请求用户的信息被替换成伪装字段的值。
• 评估请求，鉴权组件针对所伪装的用户信息执行操作。

以下 HTTP 头部字段可用来执行伪装请求：

• Impersonate-User：要伪装成的用户名
• Impersonate-Group：要伪装成的用户组名。可以多次指定以设置多个用户组。 可选字段；要求 "Impersonate-User" 必须被设置。
• Impersonate-Extra-<附加名称>：一个动态的头部字段，用来设置与用户相关的附加字段。 此字段可选；要求 "Impersonate-User" 被设置。为了能够以一致的形式保留， <附加名称>部分必须是小写字符， 如果有任何字符不是合法的 HTTP 头部标签字符， 则必须是 utf8 字符，且转换为百分号编码。
• Impersonate-Uid：一个唯一标识符，用来表示所伪装的用户。此头部可选。 如果设置，则要求 "Impersonate-User" 也存在。Kubernetes 对此字符串没有格式要求。

伪装带有用户组的用户时，所使用的伪装头部字段示例：

Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins

伪装带有 UID 和附加字段的用户时，所使用的伪装头部字段示例：

Impersonate-User: jane.doe@example.com
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 都位于 "authorization.k8s.io" apiGroup 中。 附加字段会被作为 userextras 资源的子资源来执行权限评估。 如果要允许用户为附加字段 “scopes” 和 UID 设置伪装头部，该用户需要被授予以下角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scopes-and-uid-impersonator
rules:
# 可以设置 "Impersonate-Extra-scopes" 和 "Impersonate-Uid" 头部
- apiGroups: ["authentication.k8s.io"]
  resources: ["userextras/scopes", "uids"]
  verbs: ["impersonate"]

你也可以通过约束资源可能对应的 resourceNames 限制伪装头部的取值：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
  # 可以伪装成用户 "jane.doe@example.com"
  - apiGroups: [""]
    resources: ["users"]
    verbs: ["impersonate"]
    resourceNames: ["jane.doe@example.com"]
  
  # 可以伪装成用户组 "developers" 和 "admins"
  - apiGroups: [""]
    resources: ["groups"]
    verbs: ["impersonate"]
    resourceNames: ["developers","admins"]
  
  # 可以将附加字段 "scopes" 伪装成 "view" 和 "development"
  - apiGroups: ["authentication.k8s.io"]
    resources: ["userextras/scopes"]
    verbs: ["impersonate"]
    resourceNames: ["view", "development"]
  
  # 可以伪装 UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"
  - apiGroups: ["authentication.k8s.io"]
    resources: ["uids"]
    verbs: ["impersonate"]
    resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"]

client-go 凭据插件

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 配置文件 来作为 user 字段的一部分设置。

• client.authentication.k8s.io/v1
• client.authentication.k8s.io/v1beta1

apiVersion: v1
kind: Config
users:
- name: my-user
  user:
    exec:
      # 要执行的命令。必需。
      command: "example-client-go-exec-plugin"

      # 解析 ExecCredentials 资源时使用的 API 版本。必需。
      # 插件返回的 API 版本必需与这里列出的版本匹配。
      #
      # 要与支持多个版本的工具（如 client.authentication.k8s.io/v1beta1）集成，
      # 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本，
      # 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
      apiVersion: "client.authentication.k8s.io/v1"

      # 执行此插件时要设置的环境变量。可选字段。
      env:
      - name: "FOO"
        value: "bar"

      # 执行插件时要传递的参数。可选字段。
      args:
      - "arg1"
      - "arg2"

      # 当可执行文件不存在时显示给用户的文本。可选的。
      installHint: |
        需要 example-client-go-exec-plugin 来在当前集群上执行身份认证。可以通过以下命令安装：

        MacOS: brew install example-client-go-exec-plugin

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

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

        ...        

      # 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
      # 提供集群信息（可能包含非常大的 CA 数据）
      provideClusterInfo: true

      # Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足，
      # 则插件无法运行并会返回错误信息。合法的值包括 "Never" （Exec 插件从不使用标准输入），
      # "IfAvailable" （Exec 插件希望在可以的情况下使用标准输入），
      # 或者 "Always" （Exec 插件需要使用标准输入才能工作）。必需字段。
      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 # 为每个集群 exec 配置保留的扩展名
      extension:
        arbitrary: config
        this: 在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定
        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: "example-client-go-exec-plugin"

      # 解析 ExecCredentials 资源时使用的 API 版本。必需。
      # 插件返回的 API 版本必需与这里列出的版本匹配。
      #
      # 要与支持多个版本的工具（如 client.authentication.k8s.io/v1）集成，
      # 可以设置一个环境变量或者向工具传递一个参数标明 exec 插件所期望的版本，
      # 或者从 KUBERNETES_EXEC_INFO 环境变量的 ExecCredential 对象中读取版本信息。
      apiVersion: "client.authentication.k8s.io/v1beta1"

      # 执行此插件时要设置的环境变量。可选字段。
      env:
      - name: "FOO"
        value: "bar"

      # 执行插件时要传递的参数。可选字段。
      args:
      - "arg1"
      - "arg2"

      # 当可执行文件不存在时显示给用户的文本。可选的。
      installHint: |
        需要 example-client-go-exec-plugin 来在当前集群上执行身份认证。可以通过以下命令安装：

        MacOS: brew install example-client-go-exec-plugin

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

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

        ...        

      # 是否使用 KUBERNETES_EXEC_INFO 环境变量的一部分向这个 exec 插件
      # 提供集群信息（可能包含非常大的 CA 数据）
      provideClusterInfo: true

      # Exec 插件与标准输入 I/O 数据流之间的协议。如果协议无法满足，
      # 则插件无法运行并会返回错误信息。合法的值包括 "Never"（Exec 插件从不使用标准输入），
      # "IfAvailable" （Exec 插件希望在可以的情况下使用标准输入），
      # 或者 "Always" （Exec 插件需要使用标准输入才能工作）。可选字段。
      # 默认值为 "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 # 为每个集群 exec 配置保留的扩展名
      extension:
        arbitrary: config
        this: 在设置 provideClusterInfo 时可通过环境变量 KUBERNETES_EXEC_INFO 指定
        you: ["can", "put", "anything", "here"]
contexts:
- name: my-cluster
  context:
    cluster: my-cluster
    user: my-user
current-context: my-cluster

解析相对命令路径时，kubectl 将其视为与配置文件比较而言的相对路径。 如果 KUBECONFIG 被设置为 /home/jane/kubeconfig，而 exec 命令为 ./bin/example-client-go-exec-plugin，则要执行的可执行文件为 /home/jane/bin/example-client-go-exec-plugin。

- name: my-user
  user:
    exec:
      # 对 kubeconfig 目录而言的相对路径
      command: "./bin/example-client-go-exec-plugin"
      apiVersion: "client.authentication.k8s.io/v1"
      interactiveMode: Never

输出和输出格式

所执行的命令会在 stdout 打印 ExecCredential 对象。 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 中是必需的。

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

• client.authentication.k8s.io/v1
• client.authentication.k8s.io/v1beta1

{
  "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 字段可能包含一些要发送给服务器的中间证书（Intermediate Certificates）。

• client.authentication.k8s.io/v1
• client.authentication.k8s.io/v1beta1

{
  "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 状态码或者进程退出。

• client.authentication.k8s.io/v1
• client.authentication.k8s.io/v1beta1

{
  "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 清单描述的是一个示例集群信息。

• client.authentication.k8s.io/v1
• client.authentication.k8s.io/v1beta1

{
  "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": "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供",
        "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": "可以在设置 provideClusterInfo 时通过 KUBERNETES_EXEC_INFO 环境变量提供",
        "you": ["can", "put", "anything", "here"]
      }
    },
    "interactive": true
  }
}

为客户端提供的对身份认证信息的 API 访问

如果集群启用了此 API，你可以使用 SelfSubjectReview API 来了解 Kubernetes 集群如何映射你的身份认证信息从而将你识别为某客户端。无论你是作为用户（通常代表一个真的人）还是作为 ServiceAccount 进行身份认证，这一 API 都可以使用。

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

请求示例（主体将是 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"]
      }
    }
  }
}

为了方便，Kubernetes 提供了 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]
  

通过提供 output 标志，也可以打印结果的 JSON 或 YAML 表现形式：

• JSON
• YAML

{
  "apiVersion": "authentication.k8s.io/v1alpha1",
  "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 集群角色允许的操作。

接下来

• 阅读客户端认证参考文档（v1beta1）。
• 阅读客户端认证参考文档（v1）。

2 - 使用启动引导令牌（Bootstrap Tokens）认证

启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群 或者在现有集群中添加新节点时使用的。 它被设计成能够支持 kubeadm， 但是也可以被用在其他的案例中以便用户在不使用 kubeadm 的情况下启动集群。 它也被设计成可以通过 RBAC 策略，结合 kubelet TLS 启动引导 系统进行工作。

启动引导令牌被定义成一个特定类型的 Secret（bootstrap.kubernetes.io/token）， 并存在于 kube-system 名字空间中。 这些 Secret 会被 API 服务器上的启动引导认证组件（Bootstrap Authenticator）读取。 控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。 这些令牌也被用来在节点发现的过程中会使用的一个特殊的 ConfigMap 对象。 BootstrapSigner 控制器也会使用这一 ConfigMap。

令牌格式

启动引导令牌使用 abcdef.0123456789abcdef 的形式。 更加规范地说，它们必须符合正则表达式 [a-z0-9]{6}\.[a-z0-9]{16}。

令牌的第一部分是 “Token ID”，它是一种公开信息，用于引用令牌并确保不会 泄露认证所使用的秘密信息。 第二部分是“令牌秘密（Token Secret）”，它应该被共享给受信的第三方。

启用启动引导令牌

启用启动引导令牌身份认证

启动引导令牌认证组件可以通过 API 服务器上的如下标志启用：

--enable-bootstrap-token-auth

启动引导令牌被启用后，可以作为持有者令牌的凭据，用于 API 服务器请求的身份认证。

Authorization: Bearer 07401b.f395accd246ae52d

令牌认证为用户名 system:bootstrap:<token id> 并且是组 system:bootstrappers 的成员。额外的组信息可以通过令牌的 Secret 来设置。

过期的令牌可以通过启用控制器管理器中的 tokencleaner 控制器来删除。

--controllers=*,tokencleaner

启动引导令牌的 Secret 格式

每个合法的令牌背后对应着 kube-system 名字空间中的某个 Secret 对象。 你可以从 这里 找到完整设计文档。

这是 Secret 看起来的样子。

apiVersion: v1
kind: Secret
metadata:
  # name 必须是 "bootstrap-token-<token id>" 格式的
  name: bootstrap-token-07401b
  namespace: kube-system

# type 必须是 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # 供人阅读的描述，可选。
  description: "The default bootstrap token generated by 'kubeadm init'."

  # 令牌 ID 和秘密信息，必需。
  token-id: 07401b
  token-secret: f395accd246ae52d

  # 可选的过期时间字段
  expiration: 2017-03-10T03:22:11Z

  # 允许的用法
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # 令牌要认证为的额外组，必须以 "system:bootstrappers:" 开头
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

Secret 的类型必须是 bootstrap.kubernetes.io/token，而且名字必须是 bootstrap-token-<token id>。 令牌必须存在于 kube-system 名字空间中。

usage-bootstrap-* 成员表明这个 Secret 的用途。启用时，值必须设置为 true。

• usage-bootstrap-authentication 表示令牌可以作为持有者令牌用于 API 服务器的身份认证。
• usage-bootstrap-signing 表示令牌可被用于 cluster-info ConfigMap 的签名， 就像下面描述的那样。

expiration 字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝，在用于 ConfigMap 签名时会被忽略。 过期时间值是遵循 RFC3339 进行编码的 UTC 时间。启用 TokenCleaner 控制器会自动删除过期的令牌。

使用 kubeadm 管理令牌

你可以使用 kubeadm 工具管理运行中集群上的令牌。 参见 kubeadm token 文档 以了解详细信息。

ConfigMap 签名

除了身份认证，令牌还可以用于签名 ConfigMap。 这一用法发生在集群启动过程的早期，在客户端信任 API 服务器之前。 被签名的 ConfigMap 可以被共享令牌完成身份认证。

通过在控制器管理器上启用 bootstrapsigner 控制器可以启用 ConfigMap 签名特性。

--controllers=*,bootstrapsigner

被签名的 ConfigMap 是 kube-public 名字空间中的 cluster-info。 典型的工作流中，客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。 通过检查 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。

ConfigMap 会是这个样子的：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <非常长的证书数据>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []    

ConfigMap 的 kubeconfig 成员是一个填好了集群信息的配置文件。 这里主要交换的信息是 certificate-authority-data。在将来可能会有扩展。

签名是一个使用 “detached” 模式生成的 JWS 签名。 为了检验签名，用户应该按照 JWS 规则（base64 编码且丢掉结尾的 =）对 kubeconfig 的载荷进行编码。完成编码的载荷会被插入到两个句点中间，形成完整的 JWS。你可以使用完整的令牌（比如 07401b.f395accd246ae52d）作为共享密钥， 通过 HS256 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户必须确保使用了 HS256。

参考 kubeadm 实现细节 了解更多信息。

3 - 鉴权

Kubernetes 鉴权在身份认证之后进行。 通常，发出请求的客户端必须经过身份验证（登录）才能允许其请求； 但是，Kubernetes 在某些情况下也允许匿名请求。

有关鉴权在 API 访问控制中的位置这类进一步的语境信息， 请阅读控制对 Kubernetes API 的访问。

鉴权裁定

Kubernetes 对 API 请求的鉴权在 API 服务器内进行。 API 服务器根据所有策略评估所有请求属性，可能还会咨询外部服务，然后允许或拒绝该请求。

API 请求的所有部分都必须通过某种鉴权机制才能继续， 换句话说：默认情况下拒绝访问。

当系统配置了多个鉴权模块时，Kubernetes 将按顺序使用每个模块。 如果任何鉴权模块批准或拒绝请求，则立即返回该决定，并且不会与其他鉴权模块协商。 如果所有模块对请求没有意见，则拒绝该请求。 总体拒绝裁决意味着 API 服务器拒绝请求并以 HTTP 403（禁止）状态进行响应。

鉴权中使用的请求属性

Kubernetes 仅审查以下 API 请求属性：

• 用户 —— 身份验证期间提供的 user 字符串。
• 组 —— 经过身份验证的用户所属的组名列表。
• 额外信息 —— 由身份验证层提供的任意字符串键到字符串值的映射。
• API —— 指示请求是否针对 API 资源。
• 请求路径 —— 各种非资源端点的路径，如 /api 或 /healthz。
• API 请求动词 —— API 动词 get、list、create、update、patch、watch、 proxy、redirect、delete 和 deletecollection 用于资源请求。 要确定资源 API 端点的请求动词，请参阅请求动词和鉴权。
• HTTP 请求动词 —— HTTP 动词 get、post、put 和 delete 用于非资源请求。
• 资源 —— 正在访问的资源的 ID 或名称（仅限资源请求）- 对于使用 get、update、patch 和 delete 动词的资源请求，你必须提供资源名称。
• 子资源 —— 正在访问的子资源（仅限资源请求）。
• 名字空间 —— 正在访问的对象的名称空间（仅适用于名字空间资源请求）。
• API 组 —— 正在访问的 API 组 （仅限资源请求）。空字符串表示核心 API 组。

请求动词和鉴权

非资源请求

对于 /api/v1/... 或 /apis/<group>/<version>/... 之外的端点的请求被视为非资源请求（Non-Resource Requests）， 并使用该请求的 HTTP 方法的小写形式作为其请求动词。

例如，对 /api 或 /healthz 这类端点的 GET 请求将使用 get 作为其动词。

资源请求

为了确定资源 API 端点的请求动词，Kubernetes 会映射所使用的 HTTP 动词， 并考虑该请求是否作用于单个资源或资源集合：

Kubernetes 有时使用专门的动词以对额外的权限进行鉴权。例如：

• 身份认证的特殊情况
  • 对核心 API 组中 users、groups 和 serviceaccounts 以及 authentication.k8s.io API 组中的 userextras 所使用的 impersonate 动词。
• RBAC
  • 对 rbac.authorization.k8s.io API 组中 roles 和 clusterroles 资源的 bind 和 escalate 动词

鉴权上下文

Kubernetes 需要 REST API 请求所共有的属性， 这意味着 Kubernetes 鉴权可与现有的组织范围或云提供商范围的访问控制系统配合使用， 这些系统可以处理除 Kubernetes API 之外的其他 API。

鉴权模式

AlwaysAllow

此模式允许所有请求，但存在安全风险， 仅当你的 API 请求不需要鉴权时（例如，用于测试），才使用此鉴权模式。

AlwaysDeny

此模式阻止所有请求。此鉴权模式仅适用于测试。

ABAC（基于属性的访问控制）

Kubernetes ABAC 模式定义了一种访问控制范例，通过使用将属性组合在一起的策略向用户授予访问权限， 策略可以使用任何类型的属性（用户属性、资源属性、对象、环境属性等）。

RBAC（基于角色的访问控制）

Kubernetes RBAC 是一种根据企业内各个用户的角色来管理其对计算机或网络资源的访问权限的方法。 在此上下文中，访问权限是单个用户执行特定任务（例如查看、创建或修改文件）的能力。 在这种模式下，Kubernetes 使用 rbac.authorization.k8s.io API 组来驱动鉴权决策， 允许你通过 Kubernetes API 动态配置权限策略。

Node

一种特殊用途的鉴权模式，根据 kubelet 计划运行的 Pod 向其授予权限。 要了解有关 Node 鉴权模式的更多信息，请参阅 Node 鉴权。

Webhook

Kubernetes 的 Webhook 鉴权模式用于鉴权，进行同步 HTTP 调用， 阻塞请求直到远程 HTTP 服务响应查询。你可以编写自己的软件来处理这种向外调用，也可以使用生态系统中的解决方案。

system:masters 组

system:masters 组是 Kubernetes 内置的一个组，授予其成员对 API 服务器的无限制访问权限。 任何被分配到此组的用户都具有完全的集群管理员权限，可以绕过由 RBAC 或 Webhook 机制施加的任何鉴权限制。 请避免将用户添加到此组。 如果你确实需要授予某个用户集群管理员权限，可以通过创建一个 ClusterRoleBinding 将其绑定到内置的 cluster-admin ClusterRole。

鉴权模式配置

你可以仅使用命令行参数， 或使用配置文件来配置 Kubernetes API 服务器的鉴权链，后者目前是 Beta 特性。

你必须选择两种配置方法之一；不允许同时设置 --authorization-config 路径并使用 --authorization-mode 和 --authorization-webhook-* 命令行参数配置鉴权 Webhook。 如果你尝试这样做，API 服务器会在启动期间报告错误消息，然后立即退出。

命令行鉴权模式配置

你可以使用以下模式：

• --authorization-mode=ABAC（基于属性的访问控制模式）
• --authorization-mode=RBAC（基于角色的访问控制模式）
• --authorization-mode=Node（节点鉴权组件）
• --authorization-mode=Webhook（Webhook 鉴权模式）
• --authorization-mode=AlwaysAllow（始终允许请求；存在安全风险)
• --authorization-mode=AlwaysDeny（始终拒绝请求）

你可以选择多种鉴权模式；例如：--authorization-mode=Node,Webhook

Kubernetes 根据你在 API 服务器的命令行上指定鉴权模块的顺序来检查鉴权模块， 因此较早的模块具有更高的优先级来允许或拒绝请求。

你不能将 --authorization-mode 命令行参数与用于使用本地文件配置鉴权的 --authorization-config 命令行参数结合使用。

有关 API 服务器命令行参数的更多信息，请阅读 kube-apiserver 参考。

配置文件方法甚至允许你指定 CEL规则， 在将请求发送到 Webhook 之前对其进行预过滤，从而帮助你防止不必要的调用。 修改配置文件时，API 服务器还会自动重新加载鉴权链。

你可以使用 --authorization-config 命令行参数指定鉴权配置的路径。

如果你想使用命令行参数而不是配置文件，这也是一种有效且受支持的方法。 某些鉴权功能（例如：多个 Webhook、Webhook 失败策略和预过滤规则）仅在使用鉴权配置文件时可用。

示例配置

---
#
# 请勿按原样使用配置，这只是一个示例。
#
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
  - type: Webhook
    # 用于描述鉴权人的名称
    # 这明确用于监控机制的指标
    # 注意
    #   - 该字段的验证与今天的 K8s 标签的验证方式类似。
    # 必填，无默认值
    name: webhook
    webhook:
      # 缓存来自 Webhook 鉴权组件的“鉴权”响应的持续时间
      # 与设置 `--authorization-webhook-cache-authorized-ttl` 标志相同
      # 默认值：5m0s
      authorizedTTL: 30s
      # 缓存来自 Webhook 鉴权组件的“未授权”响应的持续时间。
      # 与设置 `--authorization-webhook-cache-unauthorized-ttl` 标志相同
      # 默认值：30s
      unauthorizedTTL: 30s
      # Webhook 请求超时
      # 允许的最大时间为 30 秒。
      # 必填，没有默认值。
      timeout: 3s
      # 要发送到 Webhook 并期望从 webhook 获得的 authorization.k8s.io SubjectAccessReview 的 API 版本。
      # 与设置 `--authorization-webhook-version` 标志相同
      # 必填，无默认值
      # 有效值：v1beta1、v1
      subjectAccessReviewVersion: v1
      # MatchConditionSubjectAccessReviewVersion 指定评估 CEL 表达式的 SubjectAccessReview 版本
      # 有效值：v1
      # 必填，无默认值
      matchConditionSubjectAccessReviewVersion: v1
      # 当 Webhook 请求无法完成或返回格式错误的响应或评估 matchConditions 时出现错误时，控制鉴权决定。
      # 有效值：
      #   - NoOpinion：继续联系后续鉴权组件，看其中是否有人允许该请求
      #   - Deny：拒绝请求而不咨询后续鉴权组件
      # 必填，没有默认值。
      failurePolicy: Deny
      connectionInfo:
        # 控制 Webhook 如何与服务器通信。
        # 有效值：
        # - KubeConfigFile：使用 kubeConfigFile 中指定的文件来定位服务器。
        # - InClusterConfig：使用集群内配置来调用由 kube-apiserver 托管的 SubjectAccessReview API，kube-apiserver 不允许使用此模式。
        type: KubeConfigFile
        # 连接信息的 KubeConfig 文件的路径
        # 如果 connectionInfo.Type 是 KubeConfig，则为必填项
        kubeConfigFile: /kube-system-authz-webhook.yaml
        # matchConditions 是将请求发送到此 Webhook 必须满足的条件列表。
        # matchConditions 为空列表表示匹配所有请求。
        # 最多允许 64 个匹配条件。
        #
        # 精确匹配逻辑如下（按顺序）：
        # 1. 如果至少一个 matchCondition 计算结果为 FALSE，则跳过 Webhook。
        # 2. 如果所有 matchConditions 计算结果为 TRUE，则调用 Webhook。
        # 3. 如果至少一个 matchCondition 计算结果为错误（但没有一个为 FALSE）：
        # - 如果 FailurePolicy=Deny，则 Webhook 拒绝请求
        # - 如果 FailurePolicy=NoOpinion，则忽略错误并跳过 Webhook
      matchConditions:
        # 表达式表示将由 CEL 评估的表达式。必须评估为布尔值。
        # CEL 表达式可以访问 v1 版本中的 SubjectAccessReview 的内容。
        # 如果请求变量中 subjectAccessReviewVersion 指定的版本是 v1beta1，
        # 在评估 CEL 表达式之前，内容将转换为 v1 版本。
      #
      # CEL 文档：https://kubernetes.io/docs/reference/using-api/cel/
      #
      # 仅向 Webhook 发送资源请求
      - expression: has(request.resourceAttributes)
      # 仅拦截对 kube-system 的请求
      - expression: request.resourceAttributes.namespace == 'kube-system'
      # 不要拦截来自 kube-system 服务账户的请求
      - expression: "!('system:serviceaccounts:kube-system' in request.groups)"
  - type: Node
    name: node
  - type: RBAC
    name: rbac
  - type: Webhook
    name: in-cluster-authorizer
    webhook:
      authorizedTTL: 5m
      unauthorizedTTL: 30s
      timeout: 3s
      subjectAccessReviewVersion: v1
      failurePolicy: NoOpinion
      connectionInfo:
        type: InClusterConfig

使用配置文件配置鉴权链时，请确保所有控制平面节点具有相同的文件内容。升级/降级集群时，请记下 API 服务器配置。 例如，如果从 Kubernetes 1.31 升级到 Kubernetes 1.32，则需要确保配置文件的格式是 Kubernetes 1.32 可以理解的，然后再升级集群。 如果降级到 1.31，则需要适当设置配置。

鉴权配置和重新加载

当 API 服务器观察到文件的更改时，Kubernetes 会重新加载鉴权配置文件， 如果没有观察到更改事件，则也会按照 60 秒的计划重新加载。

通过创建或编辑工作负载来提升权限

能够直接或通过启用间接工作负载管理的对象在命名空间中创建/编辑 Pod 的用户可能能够在该命名空间中提升其权限。 权限提升的潜在途径包括 Kubernetes API 扩展及其相关的 控制器。

权限提升路径

如果你允许攻击者或不值得信任的用户在该命名空间中运行任意 Pod， 则他们可以通过不同的方式在命名空间内获得额外的权限：

• 在该命名空间中挂载任意 Secret
  • 可用于访问其他工作负载的机密信息
  • 可用于获取更具特权的 ServiceAccount 的服务帐户令牌
• 在该命名空间中使用任意 ServiceAccount
  • 可以作为另一个工作负载执行 Kubernetes API 操作（模拟）
  • 可以执行 ServiceAccount 拥有的任何特权操作
• 在该命名空间中挂载或使用其他工作负载的 ConfigMap
  • 可用于获取其他工作负载的信息，例如数据库主机名。
• 在该命名空间中挂载其他工作负载的卷
  • 可用于获取其他工作负载的信息并进行更改。

检查 API 访问

kubectl 提供 auth can-i 子命令，用于快速查询 API 鉴权。 该命令使用 SelfSubjectAccessReview API 来确定当前用户是否可以执行给定操作， 无论使用何种鉴权模式该命令都可以工作。

kubectl auth can-i create deployments --namespace dev

输出类似于：

yes

kubectl auth can-i create deployments --namespace prod

输出类似于：

no

管理员可以将此与用户扮演（User Impersonation） 结合使用，以确定其他用户可以执行的操作。

kubectl auth can-i list secrets --namespace dev --as dave

输出类似于：

no

类似地，检查名字空间 dev 里的 dev-sa 服务账户是否可以列举名字空间 target 里的 Pod：

kubectl auth can-i list pods \
	--namespace target \
	--as system:serviceaccount:dev:dev-sa

输出类似于：

yes

SelfSubjectAccessReview 是 authorization.k8s.io API 组的一部分，它将 API 服务器鉴权公开给外部服务。该组中的其他资源包括：

• SubjectAccessReview : 对任意用户的访问进行评估，而不仅仅是当前用户。 当鉴权决策被委派给 API 服务器时很有用。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。

• LocalSubjectAccessReview : 与 SubjectAccessReview 类似，但仅限于特定的名字空间。

• SelfSubjectRulesReview : 返回用户可在名字空间内执行的操作集的审阅。 用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。

可以通过创建普通的 Kubernetes 资源来查询这些 API，其中返回对象的响应 status 字段是查询的结果，例如：

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    name: deployments
    verb: create
    namespace: dev
EOF

生成的 SelfSubjectAccessReview 类似于：

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    name: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

接下来

• 要了解有关身份验证的更多信息， 请参阅身份认证。
• 有关概述，请阅读控制对 Kubernetes API 的访问。
• 要了解有关准入控制的更多信息，请参阅使用准入控制器。
• 阅读更多关于 Kubernetes 中的通用表达语言。

4 - 使用 RBAC 鉴权

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。

RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定， 允许你通过 Kubernetes API 动态配置策略。

要启用 RBAC，在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保其中包含 RBAC。

kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项>

API 对象

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。你可以像使用其他 Kubernetes 对象一样， 通过类似 kubectl 这类工具描述或修补 RBAC 对象。

Role 和 ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一组代表相关权限的规则。 这些权限是纯粹累加的（不存在拒绝某操作的规则）。

Role 总是用来在某个名字空间内设置访问权限； 在你创建 Role 时，你必须指定该 Role 所属的名字空间。

与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole） 是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

1. 定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限；
2. 为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限；
3. 为集群作用域的资源定义访问权限。

如果你希望在名字空间内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。

Role 示例

下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 Pod 的读访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole 示例

ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：

• 集群范围资源（比如节点（Node））

• 非资源端点（比如 /healthz）

• 跨名字空间访问的名字空间作用域的资源（如 Pod）

  比如，你可以使用 ClusterRole 来允许某特定用户执行 kubectl get pods --all-namespaces

下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 Secret 授予读访问权限， 或者跨名字空间的访问权限（取决于该角色是如何绑定的）：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Role 或 ClusterRole 对象的名称必须是合法的路径分段名称。

RoleBinding 和 ClusterRoleBinding

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体（Subject）（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。

RoleBinding 或 ClusterRoleBinding 对象的名称必须是合法的 路径分段名称。

RoleBinding 示例

下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 这样，用户 "jane" 就具有了读取 "default" 名字空间中所有 Pod 的权限。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod
# 你需要在该名字空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
  name: jane # "name" 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role        # 此字段必须是 Role 或 ClusterRole
  name: pod-reader  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: rbac.authorization.k8s.io

RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个名字空间中复用。

例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，"dave"（这里的主体， 区分大小写）只能访问 "development" 名字空间中的 Secret 对象，因为 RoleBinding 所在的名字空间（由其 metadata 决定）是 "development"。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secret
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名字空间决定了访问权限的授予范围。
  # 这里隐含授权仅在 "development" 名字空间内的访问权限。
  namespace: development
subjects:
- kind: User
  name: dave # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 示例

要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secret。

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager      # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

创建了绑定之后，你不能再修改绑定对象所引用的 Role 或 ClusterRole。 试图改变绑定对象的 roleRef 将导致合法性检查错误。 如果你想要改变现有绑定对象中 roleRef 字段的内容，必须删除重新创建绑定对象。

这种限制有两个主要原因：

1. 将 roleRef 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 update 权限， 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。

2. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 roleRef， 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改了 roleRef 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。

命令 kubectl auth reconcile 可以创建或者更新包含 RBAC 对象的清单文件， 并且在必要的情况下删除和重新创建绑定对象，以改变所引用的角色。 更多相关信息请参照命令用法和示例。

对资源的引用

在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。 例如，对于 Pod 应使用 "pods"。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 有一些 Kubernetes API 涉及子资源（subresource），例如 Pod 的日志。 对 Pod 日志的请求看起来像这样：

GET /api/v1/namespaces/{namespace}/pods/{name}/log

在这里，pods 对应名字空间作用域的 Pod 资源，而 log 是 pods 的子资源。 在 RBAC 角色表达子资源时，使用斜线（/）来分隔资源和子资源。 要允许某主体读取 pods 同时访问这些 Pod 的 log 子资源，你可以这样写：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

对于某些请求，也可以通过 resourceNames 列表按名称引用资源。 在指定时，可以将请求限定为资源的单个实例。 下面的例子中限制可以 get 和 update 一个名为 my-configmap 的 ConfigMap：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

你可以使用通配符 * 批量引用所有的 resources、apiGroups 和 verbs 对象，无需逐一引用。 对于 nonResourceURLs，你可以将通配符 * 作为后缀实现全局通配， 对于 resourceNames，空集表示没有任何限制。 下面的示例对 example.com API 组中所有当前和未来资源执行所有动作。 这类似于内置的 cluster-admin。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: example.com-superuser # 此角色仅作示范，请勿使用
rules:
- apiGroups: ["example.com"]
  resources: ["*"]
  verbs: ["*"]

聚合的 ClusterRole

你可以将若干 ClusterRole 聚合（Aggregate） 起来，形成一个复合的 ClusterRole。 作为集群控制面的一部分，控制器会监视带有 aggregationRule 的 ClusterRole 对象集合。aggregationRule 为控制器定义一个标签选择算符供后者匹配应该组合到当前 ClusterRole 的 roles 字段中的 ClusterRole 对象。

下面是一个聚合 ClusterRole 的示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自动填充这里的规则

如果你创建一个与某个已存在的聚合 ClusterRole 的标签选择算符匹配的 ClusterRole， 这一变化会触发新的规则被添加到聚合 ClusterRole 的操作。 下面的例子中，通过创建一个标签同样为 rbac.example.com/aggregate-to-monitoring: true 的 ClusterRole，新的规则可被添加到 "monitoring" ClusterRole 中。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时，
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

默认的面向用户的角色使用 ClusterRole 聚合。 这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则， 比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。

例如，下面的 ClusterRoles 让默认角色 "admin" 和 "edit" 拥有管理自定义资源 "CronTabs" 的权限， "view" 角色对 CronTab 资源拥有读操作权限。 你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 "crontabs"。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # 添加以下权限到默认角色 "admin" 和 "edit" 中
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # 添加以下权限到 "view" 默认角色中
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Role 示例

以下示例均为从 Role 或 ClusterRole 对象中截取出来，我们仅展示其 rules 部分。

允许读取在核心 API 组下的 "pods"：

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

允许在 "apps" API 组中读/写 Deployment（在 HTTP 层面，对应 URL 中资源部分为 "deployments"）：

rules:
- apiGroups: ["apps"]
  #
  # 在 HTTP 层面，用来访问 Deployment 资源的名称为 "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取核心 API 组中的 Pod 和读/写 "batch" API 组中的 Job 资源：

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  # 在 HTTP 层面，用来访问 Job 资源的名称为 "jobs"
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以限制为某名字空间中特定的 ConfigMap）：

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

允许读取在核心组中的 "nodes" 资源（因为 Node 是集群作用域的，所以需要 ClusterRole 绑定到 ClusterRoleBinding 才生效）：

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Node 资源的名称为 "nodes"
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

允许针对非资源端点 /healthz 和其子路径上发起 GET 和 POST 请求 （必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）：

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符
  verbs: ["get", "post"]

对主体的引用

RoleBinding 或者 ClusterRoleBinding 可绑定角色到某主体（Subject） 上。 主体可以是组，用户或者服务账户。

Kubernetes 用字符串来表示用户名。 用户名可以是普通的用户名，像 "alice"；或者是邮件风格的名称，如 "bob@example.com"， 或者是以字符串形式表达的数字 ID。你作为 Kubernetes 管理员负责配置身份认证模块， 以便后者能够生成你所期望的格式的用户名。

在 Kubernetes 中，身份认证（Authenticator）模块提供用户组信息。 与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， 只是不能使用保留的前缀 system:。

服务账户（ServiceAccount） 的用户名前缀为 system:serviceaccount:，属于前缀为 system:serviceaccounts: 的用户组。

RoleBinding 示例

下面示例是 RoleBinding 中的片段，仅展示其 subjects 的部分。

对于名称为 alice@example.com 的用户：

subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io

对于名称为 frontend-admins 的用户组：

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

对于 kube-system 名字空间中的默认服务账户：

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

对于 "qa" 名称空间中的所有服务账户：

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

对于在任何名字空间中的服务账户：

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

对于所有已经过身份认证的用户：

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

对于所有未通过身份认证的用户：

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

对于所有用户：

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

默认 Roles 和 Role Bindings

API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 这其中许多是以 system: 为前缀的，用以标识对应资源是直接由集群控制面管理的。 所有的默认 ClusterRole 和 ClusterRoleBinding 都有 kubernetes.io/bootstrapping=rbac-defaults 标签。

自动协商

在每次启动时，API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限， 并更新默认的 ClusterRoleBinding 以增加缺失的各类主体。 这种自动协商机制允许集群去修复一些不小心发生的修改， 并且有助于保证角色和角色绑定在新的发行版本中有权限或主体变更时仍然保持最新。

如果要禁止此功能，请将默认 ClusterRole 以及默认 ClusterRoleBinding 的 rbac.authorization.kubernetes.io/autoupdate 注解设置成 false。 注意，缺少默认权限和角色绑定主体可能会导致集群无法正常工作。

如果基于 RBAC 的鉴权机制被启用，则自动协商功能默认是被启用的。

API 发现角色

无论是经过身份验证的还是未经过身份验证的用户， 默认的集群角色绑定都授权他们读取被认为是可安全地公开访问的 API（包括 CustomResourceDefinitions）。 如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中添加 --anonymous-auth=false 的配置选项。

通过运行命令 kubectl 可以查看这些角色的配置信息:

kubectl get clusterroles system:discovery -o yaml

面向用户的角色

一些默认的 ClusterRole 不是以前缀 system: 开头的。这些是面向用户的角色。 它们包括超级用户（Super-User）角色（cluster-admin）、 使用 ClusterRoleBinding 在集群范围内完成授权的角色（cluster-status）、 以及使用 RoleBinding 在特定名字空间中授予的角色（admin、edit、view）。

面向用户的 ClusterRole 使用 ClusterRole 聚合以允许管理员在这些 ClusterRole 上添加用于定制资源的规则。如果想要添加规则到 admin、edit 或者 view， 可以创建带有以下一个或多个标签的 ClusterRole：

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

核心组件角色

其他组件角色

内置控制器的角色

Kubernetes 控制器管理器运行内建于 Kubernetes 控制面的控制器。 当使用 --use-service-account-credentials 参数启动时，kube-controller-manager 使用单独的服务账户来启动每个控制器。 每个内置控制器都有相应的、前缀为 system:controller: 的角色。 如果控制管理器启动时未设置 --use-service-account-credentials， 它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 这些角色包括：

• system:controller:attachdetach-controller
• system:controller:certificate-controller
• system:controller:clusterrole-aggregation-controller
• system:controller:cronjob-controller
• system:controller:daemon-set-controller
• system:controller:deployment-controller
• system:controller:disruption-controller
• system:controller:endpoint-controller
• system:controller:expand-controller
• system:controller:generic-garbage-collector
• system:controller:horizontal-pod-autoscaler
• system:controller:job-controller
• system:controller:namespace-controller
• system:controller:node-controller
• system:controller:persistent-volume-binder
• system:controller:pod-garbage-collector
• system:controller:pv-protection-controller
• system:controller:pvc-protection-controller
• system:controller:replicaset-controller
• system:controller:replication-controller
• system:controller:resourcequota-controller
• system:controller:root-ca-cert-publisher
• system:controller:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

初始化与预防权限提升

RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。

对角色创建或更新的限制

只有在符合下列条件之一的情况下，你才能创建/更新角色:

1. 你已经拥有角色中包含的所有权限，且其作用域与正被修改的对象作用域相同。 （对 ClusterRole 而言意味着集群范围，对 Role 而言意味着相同名字空间或者集群范围）。
2. 你被显式授权在 rbac.authorization.k8s.io API 组中的 roles 或 clusterroles 资源使用 escalate 动词。

例如，如果 user-1 没有列举集群范围所有 Secret 的权限，他将不能创建包含该权限的 ClusterRole。 若要允许用户创建/更新角色：

1. 根据需要赋予他们一个角色，允许他们根据需要创建/更新 Role 或者 ClusterRole 对象。
2. 授予他们在所创建/更新角色中包含特殊权限的权限:
   • 隐式地为他们授权（如果它们试图创建或者更改 Role 或 ClusterRole 的权限， 但自身没有被授予相应权限，API 请求将被禁止）。
   • 通过允许他们在 Role 或 ClusterRole 资源上执行 escalate 动作显式完成授权。 这里的 roles 和 clusterroles 资源包含在 rbac.authorization.k8s.io API 组中。