管理服务账号

_ServiceAccount_ 为在 Pod 中运行的进程提供身份。

Pod 内部的进程可以使用其关联服务账号的身份向集群的 API 服务器进行身份验证。

有关服务账号的介绍，请阅读配置服务账号。

此任务指南解释了 ServiceAccount 背后的一些概念。本指南还解释了如何获取或撤销代表 ServiceAccount 的令牌，以及如何（可选地）将 ServiceAccount 的有效性绑定到 API 对象的生命周期。

准备工作

你需要有一个 Kubernetes 集群，并且 kubectl 命令行工具已配置为与你的集群通信。建议在至少有两个不作为控制平面主机的节点组成的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者使用以下 Kubernetes 演练场之一。

为了能够完全按照这些步骤操作，请确保你有一个名为 `examplens` 的命名空间。如果没有，请通过运行以下命令创建一个：

kubectl create namespace examplens

用户账号与服务账号

Kubernetes 基于多种原因区分用户账号和服务账号的概念：

  • 用户账号供人类使用。服务账号供应用程序进程使用，这些进程（对于 Kubernetes）在属于 Pod 的容器中运行。
  • 用户账号旨在具有全局性：名称在集群的所有命名空间中必须是唯一的。无论你查看哪个命名空间，代表用户的特定用户名都代表同一个用户。在 Kubernetes 中，服务账号是命名空间范围的：两个不同的命名空间可以包含具有相同名称的 ServiceAccount。
  • 通常，集群的用户账号可能与企业数据库同步，其中创建新用户账号需要特殊权限并与复杂的业务流程相关联。相比之下，服务账号的创建旨在更加轻量级，允许集群用户按需为特定任务创建服务账号。将 ServiceAccount 创建与人类用户入职步骤分离，使工作负载更容易遵循最小权限原则。
  • 人类和服务账号的审计考虑可能不同；这种分离使其更容易实现。
  • 复杂系统的配置包可能包含该系统组件的各种服务账号定义。由于服务账号可以在没有许多限制的情况下创建并具有命名空间名称，因此此类配置通常是可移植的。

绑定服务账号令牌

ServiceAccount 令牌可以绑定到 kube-apiserver 中存在的 API 对象。这可以用于将令牌的有效性与另一个 API 对象的存在关联起来。支持的对象类型如下：

  • Pod（用于投射型卷挂载，见下文）
  • Secret（可用于通过删除 Secret 来撤销令牌）
  • Node（可用于在 Node 被删除时自动撤销令牌；创建新的节点绑定令牌在 v1.33+ 中已正式发布）

当令牌绑定到某个对象时，该对象的 `metadata.name` 和 `metadata.uid` 会作为额外的“私有声明”存储在颁发的 JWT 中。

当绑定令牌呈现给 kube-apiserver 时，服务账号认证器将提取并验证这些声明。如果引用的对象或 ServiceAccount 正在等待删除（例如，由于终结器），那么在 `metadata.deletionTimestamp` 日期之后 60 秒（或更长时间）的任何时刻，使用该令牌的认证都将失败。如果引用的对象不再存在（或其 `metadata.uid` 不匹配），则请求将不会通过认证。

Pod 绑定令牌中的额外元数据

特性状态： Kubernetes v1.32 [stable] （默认启用：true）

当一个服务账号令牌绑定到 Pod 对象时，额外元数据也会嵌入到令牌中，该元数据指示绑定 Pod 的 `spec.nodeName` 字段的值，以及该节点的 UID（如果可用）。

当令牌用于认证时，kube-apiserver **不会**验证此节点信息。包含此信息是为了让集成商在检查 JWT 时，无需获取 Pod 或 Node API 对象来检查关联的节点名称和 UID。

验证和检查私有声明

TokenReview API 可用于验证和从令牌中提取私有声明。

  1. 首先，假设你有一个名为 `test-pod` 的 Pod 和一个名为 `my-sa` 的服务账号。

  2. 创建绑定到此 Pod 的令牌

    kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"

  3. 将此令牌复制到一个名为 `tokenreview.yaml` 的新文件中

    apiVersion: authentication.k8s.io/v1
kind: TokenReview
spec:
  token: <token from step 2>

  4. 将此资源提交给 apiserver 进行审查

    # use '-o yaml' to inspect the output
kubectl create -o yaml -f tokenreview.yaml

    你应该看到如下输出：

    apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata:
  creationTimestamp: null
spec:
  token: <token>
status:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    extra:
      authentication.kubernetes.io/credential-id:
      - JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
      authentication.kubernetes.io/node-name:
      - kind-control-plane
      authentication.kubernetes.io/node-uid:
      - 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
      authentication.kubernetes.io/pod-name:
      - test-pod
      authentication.kubernetes.io/pod-uid:
      - e87dbbd6-3d7e-45db-aafb-72b24627dff5
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:default
    - system:authenticated
    uid: f8b4161b-2e2b-11e9-86b7-2afc33b31a7e
    username: system:serviceaccount:default:my-sa

服务账号私有声明的模式

目前，JWT 令牌中 Kubernetes 特定声明的模式尚未文档化，但可以在 Kubernetes 代码库中 ServiceAccount 包中找到相关代码区域。

你可以使用标准的 JWT 解码工具检查 JWT。下面是一个 `my-serviceaccount` 服务账号的 JWT 示例，它绑定到名为 `my-pod` 的 Pod 对象，该 Pod 被调度到 `my-namespace` 命名空间中的 `my-node` 节点：

{
  "aud": [
    "https://my-audience.example.com"
  ],
  "exp": 1729605240,
  "iat": 1729601640,
  "iss": "https://my-cluster.example.com",
  "jti": "aed34954-b33a-4142-b1ec-389d6bbb4936",
  "kubernetes.io": {
    "namespace": "my-namespace",
    "node": {
      "name": "my-node",
      "uid": "646e7c5e-32d6-4d42-9dbd-e504e6cbe6b1"
    },
    "pod": {
      "name": "my-pod",
      "uid": "5e0bd49b-f040-43b0-99b7-22765a53f7f3"
    },
    "serviceaccount": {
      "name": "my-serviceaccount",
      "uid": "14ee3fa4-a7e2-420f-9f9a-dbc4507c3798"
    }
  },
  "nbf": 1729601640,
  "sub": "system:serviceaccount:my-namespace:my-serviceaccount"
}

在 Kubernetes 外部运行并希望执行 JWT 离线验证的服务，可以使用此模式，以及配置了来自 API 服务器的 OpenID Discovery 信息的兼容 JWT 验证器，来验证提交的 JWT，而无需使用 TokenReview API。

以这种方式验证 JWT 的服务**不验证**JWT 令牌中嵌入的声明是否是当前的并且仍然有效。这意味着如果令牌绑定到某个对象，并且该对象不再存在，则该令牌仍将被视为有效（直到配置的令牌过期）。

需要确保令牌的绑定声明仍然有效的客户端，**必须**使用 TokenReview API 将令牌提交给 `kube-apiserver`，以便它验证并扩展嵌入的声明，步骤类似于上述验证和检查私有声明部分，但使用支持的客户端库。有关 JWT 及其结构的更多信息，请参阅 JSON Web Token RFC。

绑定服务账号令牌卷机制

特性状态：`Kubernetes v1.22 [stable]` （默认启用：true）

默认情况下，Kubernetes 控制平面（特别是 ServiceAccount 准入控制器）会向 Pod 添加一个投射型卷，此卷包含用于 Kubernetes API 访问的令牌。

以下是已启动 Pod 的示例：

...
  - name: kube-api-access-<random-suffix>
    projected:
      sources:
        - serviceAccountToken:
            path: token # must match the path the app expects
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

该清单片段定义了一个由三个源组成的投射型卷。在本例中，每个源也代表该卷内的一个单一路径。这三个源是：

  1. 一个 `serviceAccountToken` 源，其中包含 kubelet 从 kube-apiserver 获取的令牌。kubelet 使用 TokenRequest API 获取有时效的令牌。TokenRequest 提供的令牌在 Pod 删除时或在定义的生命周期（默认情况下为 1 小时）后过期。kubelet 也会在令牌过期之前刷新该令牌。该令牌绑定到特定的 Pod，并将 kube-apiserver 作为其受众。此机制取代了早期基于 Secret 添加卷的机制，其中 Secret 代表 Pod 的 ServiceAccount，但不会过期。
  2. 一个 `configMap` 源。ConfigMap 包含一个证书颁发机构数据包。Pod 可以使用这些证书来确保它们正在连接到集群的 kube-apiserver（而不是中间设备或意外配置错误的对等方）。
  3. 一个 `downwardAPI` 源，用于查找包含 Pod 的命名空间的名称，并将该名称信息提供给 Pod 中运行的应用程序代码。

Pod 中挂载此特定卷的任何容器都可以访问上述信息。

ServiceAccount 的手动 Secret 管理

Kubernetes v1.22 之前的版本会自动创建用于访问 Kubernetes API 的凭据。这种较旧的机制是基于创建令牌 Secret，然后可以将其挂载到运行中的 Pod 中。

在较新版本中，包括 Kubernetes v1.34，API 凭据是使用 TokenRequest API 直接获取的，并通过投射型卷挂载到 Pod 中。通过此方法获取的令牌具有有界生命周期，并在其挂载的 Pod 被删除时自动失效。

你仍然可以手动创建一个 Secret 来保存服务账号令牌；例如，如果你需要一个永不过期的令牌。

一旦你手动创建了一个 Secret 并将其链接到 ServiceAccount，Kubernetes 控制平面会自动将令牌填充到该 Secret 中。

自动生成的旧版 ServiceAccount 令牌清理

在 1.24 版本之前，Kubernetes 会为 ServiceAccount 自动生成基于 Secret 的令牌。为了区分自动生成的令牌和手动创建的令牌，Kubernetes 会检查 ServiceAccount 的 secrets 字段是否有引用。如果 Secret 被 secrets 字段引用，则它被视为自动生成的旧版令牌。否则，它被视为手动创建的旧版令牌。例如：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
  namespace: default
secrets:
  - name: build-robot-secret # usually NOT present for a manually generated token

从 1.29 版本开始，自动生成的旧版 ServiceAccount 令牌如果在一定时期内（默认设置为一年）未使用，将被标记为无效。在此定义周期（默认仍为一年）内仍未使用的令牌随后将被控制平面清除。

如果用户使用无效的自动生成令牌，令牌验证器将：

  1. 为键值对 `authentication.k8s.io/legacy-token-invalidated: /` 添加审计注解，
  2. 递增 `invalid_legacy_auto_token_uses_total` 指标计数，
  3. 使用新日期更新 Secret 标签 `kubernetes.io/legacy-token-last-used`，
  4. 返回一个错误，指示令牌已失效。

收到此验证错误时，用户可以更新 Secret 以移除 `kubernetes.io/legacy-token-invalid-since` 标签，以暂时允许使用此令牌。

这是一个自动生成的旧版令牌的示例，它已被标记为 `kubernetes.io/legacy-token-last-used` 和 `kubernetes.io/legacy-token-invalid-since` 标签：

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  namespace: default
  labels:
    kubernetes.io/legacy-token-last-used: 2022-10-24
    kubernetes.io/legacy-token-invalid-since: 2023-10-25
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token

控制平面细节

ServiceAccount 控制器

ServiceAccount 控制器管理命名空间内的 ServiceAccount，并确保每个活跃命名空间中都存在一个名为“default”的 ServiceAccount。

令牌控制器

服务账号令牌控制器作为 `kube-controller-manager` 的一部分运行。此控制器异步运行。它：

  • 监视 ServiceAccount 删除，并删除所有相应的 ServiceAccount 令牌 Secret。
  • 监视 ServiceAccount 令牌 Secret 的添加，并确保引用的 ServiceAccount 存在，并在需要时向 Secret 添加令牌。
  • 监视 Secret 删除，并在需要时从相应的 ServiceAccount 中移除引用。

你必须使用 `--service-account-private-key-file` 标志将服务账号私钥文件传递给 `kube-controller-manager` 中的令牌控制器。私钥用于签署生成的服务账号令牌。同样，你必须使用 `--service-account-key-file` 标志将相应的公钥传递给 `kube-apiserver`。公钥将用于在身份验证期间验证令牌。

特性状态： Kubernetes v1.34 [beta] （默认启用：true）

设置 `--service-account-private-key-file` 和 `--service-account-key-file` 标志的另一种设置是为外部 ServiceAccount 令牌签名和密钥管理配置一个外部 JWT 签名器。请注意，这些设置是互斥的，不能同时配置。

ServiceAccount 准入控制器

Pod 的修改是通过名为准入控制器的插件实现的。它是 API 服务器的一部分。该准入控制器同步修改 Pod 创建。当此插件处于活动状态（默认在大多数发行版中都处于活动状态）时，当 Pod 创建时，它会执行以下操作：

  1. 如果 Pod 未设置 `spec.serviceAccountName`，准入控制器会将此传入 Pod 的 ServiceAccount 名称设置为 `default`。
  2. 准入控制器确保传入 Pod 引用的 ServiceAccount 存在。如果没有具有匹配名称的 ServiceAccount，准入控制器将拒绝传入的 Pod。此检查甚至适用于 `default` ServiceAccount。
  3. 如果 ServiceAccount 的 `automountServiceAccountToken` 字段和 Pod 的 `automountServiceAccountToken` 字段都没有设置为 `false`：
    • 准入控制器修改传入的 Pod，添加一个额外的卷，其中包含用于 API 访问的令牌。
    • 准入控制器会为 Pod 中的每个容器添加一个 `volumeMount`，跳过任何已经为路径 `/var/run/secrets/kubernetes.io/serviceaccount` 定义了卷挂载的容器。对于 Linux 容器，该卷挂载在 `/var/run/secrets/kubernetes.io/serviceaccount`；在 Windows 节点上，挂载在等效路径。
  4. 如果传入 Pod 的规约中尚未包含任何 `imagePullSecrets`，则准入控制器会添加 `imagePullSecrets`，并将其从 `ServiceAccount` 复制过来。

旧版 ServiceAccount 令牌跟踪控制器

特性状态：`Kubernetes v1.28 [stable]` (默认启用: true)

此控制器在 `kube-system` 命名空间中生成一个名为 `kube-system/kube-apiserver-legacy-service-account-token-tracking` 的 ConfigMap。该 ConfigMap 记录系统开始监控旧版服务账号令牌的时间戳。

旧版 ServiceAccount 令牌清理器

特性状态： Kubernetes v1.30 [stable] (默认启用：true)

旧版 ServiceAccount 令牌清理器作为 `kube-controller-manager` 的一部分运行，每 24 小时检查一次是否有自动生成的旧版 ServiceAccount 令牌在_指定时间_内未使用。如果是，清理器将这些令牌标记为无效。

清理器首先检查控制平面创建的 ConfigMap（前提是启用了 `LegacyServiceAccountTokenTracking`）。如果当前时间在 ConfigMap 中的日期之后_指定时间_，清理器 then 遍历集群中 Secret 列表，并评估每个类型为 `kubernetes.io/service-account-token` 的 Secret。

如果 Secret 满足以下所有条件，清理器会将其标记为无效：

  • 该 Secret 是自动生成的，这意味着它被 ServiceAccount 双向引用。
  • 此 Secret 当前未被任何 Pod 挂载。
  • 该 Secret 自创建或上次使用以来已_指定时间_未使用。

清理器通过向 Secret 添加名为 `kubernetes.io/legacy-token-invalid-since` 的标签并将其值设置为当前日期来将 Secret 标记为无效。如果无效的 Secret 在_指定时间_内未使用，清理器将删除它。

TokenRequest API

特性状态：`Kubernetes v1.22 [stable]`

你可以使用 ServiceAccount 的 TokenRequest 子资源来获取该 ServiceAccount 的有时效的令牌。你不需要调用此 API 来获取在容器内使用的 API 令牌，因为 kubelet 会使用_投射型卷_为你设置好。

如果你想从 `kubectl` 使用 TokenRequest API，请参阅手动为 ServiceAccount 创建 API 令牌。

Kubernetes 控制平面（特别是 ServiceAccount 准入控制器）会向 Pod 添加一个投射型卷，并且 kubelet 确保此卷包含一个令牌，允许容器以正确的 ServiceAccount 身份进行身份验证。

（此机制取代了早期基于 Secret 添加卷的机制，其中 Secret 代表 Pod 的 ServiceAccount，但不会过期。）

以下是已启动 Pod 的示例：

...
  - name: kube-api-access-<random-suffix>
    projected:
      defaultMode: 420 # decimal equivalent of octal 0644
      sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

该清单片段定义了一个投射型卷，它结合了来自三个源的信息：

  1. 一个 `serviceAccountToken` 源，其中包含 kubelet 从 kube-apiserver 获取的令牌。kubelet 使用 TokenRequest API 获取有时效的令牌。TokenRequest 提供的令牌在 Pod 删除时或在定义的生命周期（默认情况下为 1 小时）后过期。该令牌绑定到特定的 Pod，并将 kube-apiserver 作为其受众。
  2. 一个 `configMap` 源。ConfigMap 包含一个证书颁发机构数据包。Pod 可以使用这些证书来确保它们正在连接到集群的 kube-apiserver（而不是中间设备或意外配置错误的对等方）。
  3. 一个 `downwardAPI` 源。此 `downwardAPI` 卷使包含 Pod 的命名空间的名称可供 Pod 中运行的应用程序代码使用。

Pod 中挂载此卷的任何容器都可以访问上述信息。

创建额外的 API 令牌

要为 ServiceAccount 创建一个永不失效的持久 API 令牌，请创建一个类型为 `kubernetes.io/service-account-token` 的 Secret，并带有一个引用 ServiceAccount 的注解。控制平面随后会生成一个长期有效的令牌，并用生成的令牌数据更新该 Secret。

以下是此类 Secret 的示例清单：

`secret/serviceaccount/mysecretname.yaml` 
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: myserviceaccount

要根据此示例创建 Secret，请运行：

kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml

要查看该 Secret 的详细信息，请运行：

kubectl -n examplens describe secret mysecretname

输出类似于：

Name:           mysecretname
Namespace:      examplens
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=myserviceaccount
                kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1362 bytes
namespace:      9 bytes
token:          ...

如果你在 `examplens` 命名空间中启动一个新 Pod，它可以使用你刚刚创建的 `myserviceaccount` 服务账号令牌 Secret。

删除/失效 ServiceAccount 令牌

删除/失效长期/旧版 ServiceAccount 令牌

如果你知道包含要移除的令牌的 Secret 名称：

kubectl delete secret name-of-secret

否则，首先找到 ServiceAccount 的 Secret。

# This assumes that you already have a namespace named 'examplens'
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml

输出类似于：

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}}      
  creationTimestamp: "2019-07-21T07:07:07Z"
  name: example-automated-thing
  namespace: examplens
  resourceVersion: "777"
  selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
  uid: f23fd170-66f2-4697-b049-e1e266b7f835
secrets:
  - name: example-automated-thing-token-zyxwv

然后，删除你现在知道名称的 Secret：

kubectl -n examplens delete secret/example-automated-thing-token-zyxwv

删除/使短期 ServiceAccount 令牌失效

短期 ServiceAccount 令牌在创建时指定的时限后会自动过期。没有已颁发令牌的中央记录，因此无法撤销单个令牌。

如果你必须在短期令牌过期前撤销它，你可以删除并重新创建与其关联的 ServiceAccount。这将改变其 UID，从而使为其创建的**所有** ServiceAccount 令牌失效。

外部 ServiceAccount 令牌签名和密钥管理

特性状态： Kubernetes v1.34 [beta] （默认启用：true）

kube-apiserver 可以配置为使用外部签名器进行令牌签名和令牌验证密钥管理。此功能使 Kubernetes 发行版能够与他们选择的密钥管理解决方案（例如，HSM、云 KMS）集成，以进行服务账号凭据签名和验证。要将 kube-apiserver 配置为使用 external-jwt-signer，请将 `--service-account-signing-endpoint` 标志设置为文件系统上 Unix 域套接字（UDS）的位置，或以 @ 符号为前缀并命名抽象套接字命名空间中的 UDS。在配置的 UDS 处应有一个实现 `ExternalJWTSigner` gRPC 服务的 RPC 服务器。

外部 JWT 签名器必须是健康的，并准备好为 kube-apiserver 启动提供支持的服务账号密钥。

外部签名器提供了一个实现 3 种方法的 `v1.ExternalJWTSigner` gRPC 服务：

元数据

Metadata 旨在由 `kube-apiserver` 在启动时调用一次。这使外部签名器能够与 kube-apiserver 共享元数据，例如签名器支持的最大令牌生命周期。

rpc Metadata(MetadataRequest) returns (MetadataResponse) {}

message MetadataRequest {}

message MetadataResponse {
  // used by kube-apiserver for defaulting/validation of JWT lifetime while accounting for configuration flag values:
  // 1. `--service-account-max-token-expiration`
  // 2. `--service-account-extend-token-expiration`
  //
  // * If `--service-account-max-token-expiration` is greater than `max_token_expiration_seconds`, kube-apiserver treats that as misconfiguration and exits.
  // * If `--service-account-max-token-expiration` is not explicitly set, kube-apiserver defaults to `max_token_expiration_seconds`.
  // * If `--service-account-extend-token-expiration` is true, the extended expiration is `min(1 year, max_token_expiration_seconds)`.
  //
  // `max_token_expiration_seconds` must be at least 600s.
  int64 max_token_expiration_seconds = 1;
}

获取密钥

FetchKeys 返回一组受信任用于签署 Kubernetes 服务账号令牌的公钥。Kube-apiserver 将调用此 RPC：

  • 每次尝试使用未知密钥 ID 验证来自服务账号颁发者的 JWT 时，以及
  • 定期，以便它可以从 OIDC JWKs 端点提供合理最新的密钥。
rpc FetchKeys(FetchKeysRequest) returns (FetchKeysResponse) {}

message FetchKeysRequest {}

message FetchKeysResponse {
  repeated Key keys = 1;

  // The timestamp when this data was pulled from the authoritative source of
  // truth for verification keys.
  // kube-apiserver can export this from metrics, to enable end-to-end SLOs.
  google.protobuf.Timestamp data_timestamp = 2;

  // refresh interval for verification keys to pick changes if any.
  // any value <= 0 is considered a misconfiguration.
  int64 refresh_hint_seconds = 3;
}

message Key {
  // A unique identifier for this key.
  // Length must be <=1024.
  string key_id = 1;

  // The public key, PKIX-serialized.
  // must be a public key supported by kube-apiserver (currently RSA 256 or ECDSA 256/384/521)
  bytes key = 2;

  // Set only for keys that are not used to sign bound tokens.
  // eg: supported keys for legacy tokens.
  // If set, key is used for verification but excluded from OIDC discovery docs.
  // if set, external signer should not use this key to sign a JWT.
  bool exclude_from_oidc_discovery = 3;
}

签名

Sign 接收一个序列化的 JWT 负载，并返回序列化的头部和签名。`kube-apiserver` 然后从头部、负载和签名组装 JWT。

rpc Sign(SignJWTRequest) returns (SignJWTResponse) {}

message SignJWTRequest {
  // URL-safe base64 wrapped payload to be signed.
  // Exactly as it appears in the second segment of the JWT
  string claims = 1;
}

message SignJWTResponse {
  // header must contain only alg, kid, typ claims.
  // typ must be “JWT”.
  // kid must be non-empty, <=1024 characters, and its corresponding public key should not be excluded from OIDC discovery.
  // alg must be one of the algorithms supported by kube-apiserver (currently RS256, ES256, ES384, ES512).
  // header cannot have any additional data that kube-apiserver does not recognize.
  // Already wrapped in URL-safe base64, exactly as it appears in the first segment of the JWT.
  string header = 1;

  // The signature for the JWT.
  // Already wrapped in URL-safe base64, exactly as it appears in the final segment of the JWT.
  string signature = 2;
}

清理

如果你创建了 `examplens` 命名空间进行实验，你可以将其移除：

kubectl delete namespace examplens

下一步

最后修改时间：2025 年 7 月 29 日下午 2:30（太平洋标准时间）：KEP-740：将 grpc 文档移至网站 (c6c320d7d4)