Merge pull request #47334 from my-git9/pp-23100

[zh-cn] sync bootstrap-tokens certificate-signing-requests

Author: k8s-ci-robot

content/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -17,18 +17,18 @@ weight: 20
 
 <!--
 Bootstrap tokens are a simple bearer token that is meant to be used when
-creating new clusters or joining new nodes to an existing cluster.  It was built
-to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts
+creating new clusters or joining new nodes to an existing cluster.
+It was built to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts
 for users that wish to start clusters without `kubeadm`. It is also built to
 work, via RBAC policy, with the
-[Kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system.
+[kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system.
 -->
 启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群
 或者在现有集群中添加新节点时使用的。
 它被设计成能够支持 [`kubeadm`](/zh-cn/docs/reference/setup-tools/kubeadm/)，
 但是也可以被用在其他的案例中以便用户在不使用 `kubeadm` 的情况下启动集群。
 它也被设计成可以通过 RBAC 策略，结合
-[Kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+[kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
 系统进行工作。
 
 <!-- body -->
@@ -37,9 +37,9 @@ work, via RBAC policy, with the
 
 Bootstrap Tokens are defined with a specific type
 (`bootstrap.kubernetes.io/token`) of secrets that lives in the `kube-system`
-namespace.  These Secrets are then read by the Bootstrap Authenticator in the
-API Server.  Expired tokens are removed with the TokenCleaner controller in the
-Controller Manager.  The tokens are also used to create a signature for a
+namespace. These Secrets are then read by the Bootstrap Authenticator in the
+API Server. Expired tokens are removed with the TokenCleaner controller in the
+Controller Manager. The tokens are also used to create a signature for a
 specific ConfigMap used in a "discovery" process through a BootstrapSigner
 controller.
 -->
@@ -53,11 +53,11 @@ BootstrapSigner 控制器也会使用这一 ConfigMap。
 <!--
 ## Token Format
 
-Bootstrap Tokens take the form of `abcdef.0123456789abcdef`.  More formally,
-they must match the regular expression `[a-z0-9]{6}\.[a-z0-9]{16}`.
+Bootstrap Tokens take the form of `abcdef.0123456789abcdef`.
+More formally, they must match the regular expression `[a-z0-9]{6}\.[a-z0-9]{16}`.
 
 The first part of the token is the "Token ID" and is considered public
-information.  It is used when referring to a token without leaking the secret
+information. It is used when referring to a token without leaking the secret
 part used for authentication. The second part is the "Token Secret" and should
 only be shared with trusted parties.
 -->
@@ -97,8 +97,8 @@ Authorization: Bearer 07401b.f395accd246ae52d
 ```
 <!--
 Tokens authenticate as the username `system:bootstrap:<token id>` and are members
-of the group `system:bootstrappers`.  Additional groups may be specified in the
-token's Secret.
+of the group `system:bootstrappers`.
+Additional groups may be specified in the token's Secret.
 
 Expired tokens can be deleted automatically by enabling the `tokencleaner`
 controller on the controller manager.
@@ -115,7 +115,7 @@ controller on the controller manager.
 <!--
 ## Bootstrap Token Secret Format
 
-Each valid token is backed by a secret in the `kube-system` namespace.  You can
+Each valid token is backed by a secret in the `kube-system` namespace. You can
 find the full design doc
 [here](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md).
 
@@ -161,11 +161,10 @@ stringData:
 
 <!--
 The type of the secret must be `bootstrap.kubernetes.io/token` and the name must
-be `bootstrap-token-<token id>`.  It must also exist in the `kube-system`
-namespace.
+be `bootstrap-token-<token id>`. It must also exist in the `kube-system` namespace.
 
-The `usage-bootstrap-*` members indicate what this secret is intended to be used
-for.  A value must be set to `true` to be enabled.
+The `usage-bootstrap-*` members indicate what this secret is intended to be used for.
+A value must be set to `true` to be enabled.
 -->
 Secret 的类型必须是 `bootstrap.kubernetes.io/token`，而且名字必须是 `bootstrap-token-<token id>`。
 令牌必须存在于 `kube-system` 名字空间中。
@@ -183,9 +182,9 @@ authenticate to the API server as a bearer token.
   就像下面描述的那样。
 
 <!--
-The `expiration` field controls the expiry of the token.  Expired tokens are
+The `expiration` field controls the expiry of the token. Expired tokens are
 rejected when used for authentication and ignored during ConfigMap signing.
-The expiry value is encoded as an absolute UTC time using RFC3339.  Enable the
+The expiry value is encoded as an absolute UTC time using RFC3339. Enable the
 `tokencleaner` controller to automatically delete expired tokens.
 -->
 `expiration` 字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝，在用于
@@ -208,9 +207,9 @@ You can use the `kubeadm` tool to manage tokens on a running cluster. See the
 <!--
 ## ConfigMap Signing
 
-In addition to authentication, the tokens can be used to sign a ConfigMap.  This
-is used early in a cluster bootstrap process before the client trusts the API
-server.  The signed ConfigMap can be authenticated by the shared token.
+In addition to authentication, the tokens can be used to sign a ConfigMap.
+This is used early in a cluster bootstrap process before the client trusts the API
+server. The signed ConfigMap can be authenticated by the shared token.
 
 Enable ConfigMap signing by enabling the `bootstrapsigner` controller on the
 Controller Manager.
@@ -230,7 +229,7 @@ Controller Manager.
 <!--
 The ConfigMap that is signed is `cluster-info` in the `kube-public` namespace.
 The typical flow is that a client reads this ConfigMap while unauthenticated and
-ignoring TLS errors.  It then validates the payload of the ConfigMap by looking
+ignoring TLS errors. It then validates the payload of the ConfigMap by looking
 at a signature embedded in the ConfigMap.
 
 The ConfigMap may look like this:
@@ -265,19 +264,19 @@ data:
 
 <!--
 The `kubeconfig` member of the ConfigMap is a config file with only the cluster
-information filled out.  The key thing being communicated here is the
-`certificate-authority-data`.  This may be expanded in the future.
+information filled out. The key thing being communicated here is the
+`certificate-authority-data`. This may be expanded in the future.
 -->
 ConfigMap 的 `kubeconfig` 成员是一个填好了集群信息的配置文件。
 这里主要交换的信息是 `certificate-authority-data`。在将来可能会有扩展。
 
 <!--
-The signature is a JWS signature using the "detached" mode.  To validate the
+The signature is a JWS signature using the "detached" mode. To validate the
 signature, the user should encode the `kubeconfig` payload according to JWS
-rules (base64 encoded while discarding any trailing `=`).  That encoded payload
-is then used to form a whole JWS by inserting it between the 2 dots.  You can
+rules (base64 encoded while discarding any trailing `=`). That encoded payload
+is then used to form a whole JWS by inserting it between the 2 dots. You can
 verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
-`07401b.f395accd246ae52d`) as the shared secret.  Users _must_ verify that HS256
+`07401b.f395accd246ae52d`) as the shared secret. Users _must_ verify that HS256
 is used.
 -->
 签名是一个使用 “detached” 模式生成的 JWS 签名。

content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -73,7 +73,7 @@ the `spec.request` field. The CertificateSigningRequest denotes the signer (the
 recipient that the request is being made to) using the `spec.signerName` field.
 Note that `spec.signerName` is a required key after API version `certificates.k8s.io/v1`.
 In Kubernetes v1.22 and later, clients may optionally set the `spec.expirationSeconds`
-field to request a particular lifetime for the issued certificate.  The minimum valid
+field to request a particular lifetime for the issued certificate. The minimum valid
 value for this field is `600`, i.e. ten minutes.
 -->
 ### 请求签名流程 {#request-signing-process}
@@ -223,7 +223,7 @@ signed, a security certificate.
 
 Any signer that is made available for outside a particular cluster should provide information
 about how the signer works, so that consumers can understand what that means for CertifcateSigningRequests
-and (if enabled) [ClusterTrustBundles](#cluster-trust-bundles).  
+and (if enabled) [ClusterTrustBundles](#cluster-trust-bundles).
 This includes:
 -->
 ## 签名者 {#signers}
@@ -237,8 +237,10 @@ This includes:
 <!--
 1. **Trust distribution**: how trust anchors (CA certificates or certificate bundles) are distributed.
 1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
-1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
-1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR.
+1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames,
+   Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
+1. **Permitted key usages / extended key usages**: any restrictions on and behavior
+   when usages different than the signer-determined usages are specified in the CSR.
 1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR `spec.expirationSeconds` field, etc
    and the behavior when the signer-determined expiration is different from the CSR `spec.expirationSeconds` field.
 1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
@@ -281,7 +283,7 @@ certificate expiration or lifetime. The expiration or lifetime therefore has to
 through the `spec.expirationSeconds` field of the CSR object. The built-in signers
 use the `ClusterSigningDuration` configuration option, which defaults to 1 year,
 (the `--cluster-signing-duration` command-line flag of the kube-controller-manager)
-as the default when no `spec.expirationSeconds` is specified.  When `spec.expirationSeconds`
+as the default when no `spec.expirationSeconds` is specified. When `spec.expirationSeconds`
 is specified, the minimum of `spec.expirationSeconds` and `ClusterSigningDuration` is
 used.
 -->
@@ -294,7 +296,7 @@ PKCS#10 签名请求格式并没有一种标准的方法去设置证书的过期
 
 {{< note >}}
 <!--
-The `spec.expirationSeconds` field was added in Kubernetes v1.22.  Earlier versions of Kubernetes do not honor this field.
+The `spec.expirationSeconds` field was added in Kubernetes v1.22. Earlier versions of Kubernetes do not honor this field.
 Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
 -->
 `spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的。早期的 Kubernetes 版本并不认识该字段。
@@ -426,18 +428,18 @@ kube-controller-manager 为每个内置签名者实现了[控制平面签名](#s
 
 {{< note >}}
 <!--
-The `spec.expirationSeconds` field was added in Kubernetes v1.22.  Earlier versions of Kubernetes do not honor this field.
+The `spec.expirationSeconds` field was added in Kubernetes v1.22. Earlier versions of Kubernetes do not honor this field.
 Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
 -->
 `spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的，早期的 Kubernetes 版本并不认识该字段，
 v1.22 版本之前的 Kubernetes API 服务器会在创建对象的时候忽略该字段。
 {{< /note >}}
 
 <!--
-Distribution of trust happens out of band for these signers.  Any trust outside of those described above are strictly
+Distribution of trust happens out of band for these signers. Any trust outside of those described above are strictly
 coincidental. For instance, some distributions may honor `kubernetes.io/legacy-unknown` as client certificates for the
 kube-apiserver, but this is not a standard.
-None of these usages are related to ServiceAccount token secrets `.data[ca.crt]` in any way.  That CA bundle is only
+None of these usages are related to ServiceAccount token secrets `.data[ca.crt]` in any way. That CA bundle is only
 guaranteed to verify a connection to the API server using the default service (`kubernetes.default.svc`).
 -->
 对于这些签名者，信任的分发发生在带外（out of band）。上述信任之外的任何信任都是完全巧合的。
@@ -474,7 +476,8 @@ kube-controller-manager 签名所有标记为 approved 的 CSR。
 
 {{< note >}}
 <!--
-The `spec.expirationSeconds` field was added in Kubernetes v1.22.  Earlier versions of Kubernetes do not honor this field.
+The `spec.expirationSeconds` field was added in Kubernetes v1.22.
+Earlier versions of Kubernetes do not honor this field.
 Kubernetes API servers prior to v1.22 will silently drop this field when the object is created.
 -->
 `spec.expirationSeconds` 字段是在 Kubernetes v1.22 中加入的，早期的 Kubernetes 版本并不认识该字段，
@@ -703,7 +706,7 @@ this API.
 
 <!--
 A ClusterTrustBundles is a cluster-scoped object for distributing X.509 trust
-anchors (root certificates) to workloads within the cluster.  They're designed
+anchors (root certificates) to workloads within the cluster. They're designed
 to work well with the [signer](#signers) concept from CertificateSigningRequests.
 
 ClusterTrustBundles can be used in two modes:
@@ -719,8 +722,8 @@ ClusterTrustBundle 可以使用两种模式：
 ### Common properties and validation {#ctb-common}
 
 All ClusterTrustBundle objects have strong validation on the contents of their
-`trustBundle` field.  That field must contain one or more X.509 certificates,
-DER-serialized, each wrapped in a PEM `CERTIFICATE` block.  The certificates
+`trustBundle` field. That field must contain one or more X.509 certificates,
+DER-serialized, each wrapped in a PEM `CERTIFICATE` block. The certificates
 must parse as valid X.509 certificates.
 
 Esoteric PEM features like inter-block data and intra-block headers are either
@@ -796,8 +799,8 @@ controller in the cluster, so they have several security features:
   `<signerNameDomain>/<signerNamePath>` or match a pattern such as
   `<signerNameDomain>/*`.
 * Signer-linked ClusterTrustBundles **must** be named with a prefix derived from
-  their `spec.signerName` field.  Slashes (`/`) are replaced with colons (`:`),
-  and a final colon is appended.  This is followed by an arbitrary name.  For
+  their `spec.signerName` field. Slashes (`/`) are replaced with colons (`:`),
+  and a final colon is appended. This is followed by an arbitrary name.  For
   example, the signer `example.com/mysigner` can be linked to a
   ClusterTrustBundle `example.com:mysigner:<arbitrary-name>`.
 -->
@@ -841,8 +844,8 @@ spec:
 ```
 
 <!--
-They are primarily intended for cluster configuration use cases.  Each
-signer-unlinked ClusterTrustBundle is an independent object, in contrast to the
+They are primarily intended for cluster configuration use cases.
+Each signer-unlinked ClusterTrustBundle is an independent object, in contrast to the
 customary grouping behavior of signer-linked ClusterTrustBundles.
 
 Signer-unlinked ClusterTrustBundles have no `attest` verb requirement.
@@ -869,7 +872,8 @@ ClusterTrustBundle 的名称**必须不**包含英文冒号（`:`）。
 {{<feature-state for_k8s_version="v1.29" state="alpha" >}}
 
 <!--
-The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.  See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
+The contents of ClusterTrustBundles can be injected into the container filesystem, similar to ConfigMaps and Secrets.
+See the [clusterTrustBundle projected volume source](/docs/concepts/storage/projected-volumes#clustertrustbundle) for more details.
 -->
 ClusterTrustBundle 的内容可以注入到容器文件系统，这与 ConfigMap 和 Secret 类似。
 更多细节参阅 [ClusterTrustBundle 投射卷源](/zh-cn/docs/concepts/storage/projected-volumes#clustertrustbundle)。
@@ -1074,8 +1078,10 @@ kubectl config use-context myuser
 
 <!--
 * Read [Manage TLS Certificates in a Cluster](/docs/tasks/tls/managing-tls-in-a-cluster/)
-* View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
-* View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
+* View the source code for the kube-controller-manager built in
+  [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
+* View the source code for the kube-controller-manager built in
+  [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
 * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
 * Read about the ClusterTrustBundle API: