From ea26b67f9896eee3a284a20bc83ed3de2aee4fa9 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 13 Mar 2022 08:17:42 +0800 Subject: [PATCH] [zh] Resync configure service account --- .../configure-service-account.md | 129 +++++++++++------- 1 file changed, 83 insertions(+), 46 deletions(-) diff --git a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md index 46d1c46202..a27261c87f 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md @@ -66,15 +66,14 @@ you can see the `spec.serviceAccountName` field has been 你可以使用自动挂载给 Pod 的服务账户凭据访问 API， -[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod) -中有相关描述。 +[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。 服务账户的 API 许可取决于你所使用的 [鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。 @@ -172,7 +171,7 @@ The output is similar to this: --> 输出类似于： -```yaml +```none apiVersion: v1 kind: ServiceAccount metadata: @@ -237,7 +236,6 @@ metadata: kubernetes.io/service-account.name: build-robot type: kubernetes.io/service-account-token EOF -secret/build-robot-secret created ``` 现在，你可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。 - 令牌控制器将清理不存在的服务帐户的所有令牌。 ```shell @@ -312,10 +309,10 @@ The content of `token` is elided here. 输出类似于： - ``` - NAME TYPE DATA AGE - myregistrykey   kubernetes.io/.dockerconfigjson   1       1d - ``` + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` ### 将镜像拉取 Secret 添加到服务账号 -接着修改命名空间的 `default` 服务帐户，以将该 Secret 用作 imagePullSecret。 +接着修改命名空间的 `default` 服务帐户，以将该 Secret 用作 `imagePullSecret`。 ```shell kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' @@ -394,8 +391,8 @@ Now, when a new Pod is created in the current namespace and using the default Se --> ### 验证镜像拉取 Secret 已经被添加到 Pod 规约 -现在，在当前命名空间中创建的每个使用默认服务账号的新 Pod，新 Pod 都会自动 -设置其 `.spec.imagePullSecrets` 字段： +现在，在当前命名空间中创建使用默认服务账号的新 Pod 时，新 Pod +会自动设置其 `.spec.imagePullSecrets` 字段： ```shell kubectl run nginx --image=nginx --restart=Never @@ -419,22 +416,65 @@ myregistrykey -{{< note >}} 为了启用令牌请求投射，你必须为 `kube-apiserver` 设置以下命令行参数： + * `--service-account-issuer` -* `--service-account-key-file` -* `--service-account-signing-key-file` -* `--api-audiences`（可以省略） -{{< /note >}} + 此参数可作为服务账户令牌发放者的身份标识（Identifier）。你可以多次指定 + `--service-account-issuer` 参数，对于要变更发放者而又不想带来业务中断的场景， + 这样做是有用的。如果这个参数被多次指定，则第一个参数值会被用来生成令牌， + 而所有参数值都会被用来确定哪些发放者是可接受的。你所运行的 Kubernetes + 集群必须是 v1.22 或更高版本，才能多次指定 `--service-account-issuer`。 + + +* `--service-account-key-file` + + 包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥，用来检查 ServiceAccount + 的令牌。所指定的文件中可以包含多个秘钥，并且你可以多次使用此参数， + 每次参数值为不同的文件。多次使用此参数时，由所给的秘钥之一签名的令牌会被 + Kubernetes API 服务器认为是合法令牌。 + + +* `--service-account-signing-key-file` + + 指向包含当前服务账户令牌发放者的私钥的文件路径。 + 此发放者使用此私钥来签署所发放的 ID 令牌。 + + +* `--api-audiences` (can be omitted) + + 服务账号令牌身份检查组件会检查针对 API 访问所使用的令牌， + 确认令牌至少是被绑定到这里所给的受众（audiences）之一。 + 如果此参数被多次指定，则针对所给的多个受众中任何目标的令牌都会被 + Kubernetes API 服务器当做合法的令牌。如果 `--service-account-issuer` + 参数被设置，而这个参数未指定，则这个参数的默认值为一个只有一个元素的列表， + 且该元素为令牌发放者的 URL。 -kubelet 还可以将服务帐户令牌投影到 Pod 中。 -你可以指定令牌的所需属性，例如受众和有效持续时间。 -这些属性在默认服务帐户令牌上无法配置。 +kubelet 还可以将服务帐户令牌投射到 Pod 中。 +你可以指定令牌的期望属性，例如受众和有效期限。 +这些属性在 default 服务帐户令牌上无法配置。 当删除 Pod 或 ServiceAccount 时，服务帐户令牌也将对 API 无效。 -`kubelet` 组件会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的 -路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。 -`kubelet` 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时 -的时候主动轮换它。 +`kubelet` 组件会替 Pod 请求令牌并将其保存起来， +通过将令牌存储到一个可配置的路径使之在 Pod 内可用， +并在令牌快要到期的时候刷新它。 +`kubelet` 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 +24 小时的时候主动轮换它。 -应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言，周期性地 -（例如，每隔 5 分钟）重新加载就足够了。 +应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言， +周期性地（例如，每隔 5 分钟）重新加载就足够了。 -当启用服务账号令牌投射时启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性， -如[上文所述](#service-account-token-volume-projection)。 +当启用服务账号令牌投射时启用发现服务账号分发者（Service Account Issuer Discovery） +这一功能特性，如[上文所述](#service-account-token-volume-projection)。 -{{< note >}} 分发者的 URL 必须遵从 [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)。 这意味着 URL 必须使用 `https` 模式，并且必须在 `{service-account-issuer}/.well-known/openid-configuration` -路径提供 OpenID 提供者（Provider）配置。 +路径给出 OpenID 提供者（Provider）配置。 如果 URL 没有遵从这一规范，`ServiceAccountIssuerDiscovery` 末端就不会被注册， 即使该特性已经被启用。 -{{< /note >}} 发现服务账号分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes -集群（_Identity Provider_，标识提供者）与外部系统（_relying parties_， +集群（“Identity Provider”，标识提供者）与外部系统（“Relying Parties”， 依赖方）所分发的服务账号令牌。 当此功能被启用时，Kubernetes API 服务器会在 `/.well-known/openid-configuration` 提供一个 OpenID 提供者配置文档，并在 `/openid/v1/jwks` 处提供与之关联的 JSON Web Key Set（JWKS）。 -这里的 OpenID 提供者配置有时候也被称作 _发现文档（Discovery Document）_。 +这里的 OpenID 提供者配置有时候也被称作“发现文档（Discovery Document）”。 集群包括一个的默认 RBAC ClusterRole, 名为 `system:service-account-issuer-discovery`。 默认的 RBAC ClusterRoleBinding 将此角色分配给 `system:serviceaccounts` 组， -所有服务帐户隐式属于该组。这使得集群上运行的 Pod 能够通过它们所挂载的服务帐户令牌访问服务帐户发现文档。 +所有服务帐户隐式属于该组。这使得集群上运行的 Pod +能够通过它们所挂载的服务帐户令牌访问服务帐户发现文档。 此外，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到 `system:authenticated` 或 `system:unauthenticated`。 @@ -560,11 +600,9 @@ The responses served at `/.well-known/openid-configuration` and compliant. Those documents contain only the parameters necessary to perform validation of Kubernetes service account tokens. --> -{{< note >}} 对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应 被设计为与 OIDC 兼容，但不是完全与其一致。 返回的文档仅包含对 Kubernetes 服务账号令牌进行验证所必须的参数。 -{{< /note >}} JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。 -依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找 -JWKS。 +依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找 JWKS。