Merge pull request #39137 from Zhuzhenghao/certificate-signing-requests.md

[zh] Sync certificate-signing-requests.md

Author: k8s-ci-robot

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

@@ -22,8 +22,7 @@ weight: 25
 The Certificates API enables automation of
 [X.509](https://www.itu.int/rec/T-REC-X.509) credential provisioning by providing
 a programmatic interface for clients of the Kubernetes API to request and obtain
-X.509 {{< glossary_tooltip term_id="certificate" text="certificates" >}}
-from a Certificate Authority (CA).
+X.509 {{< glossary_tooltip term_id="certificate" text="certificates" >}} from a Certificate Authority (CA).
 
 A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed
 by a denoted signer, after which the request may be approved or denied before
@@ -48,9 +47,9 @@ The CertificateSigningRequest resource type allows a client to ask for an X.509
 be issued, based on a signing request.
 
 The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in
-the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the
+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`.
+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
 value for this field is `600`, i.e. ten minutes.
@@ -59,7 +58,7 @@ value for this field is `600`, i.e. ten minutes.
 
 CertificateSigningRequest 资源类型允许客户使用它申请发放 X.509 证书。
 CertificateSigningRequest 对象 在 `spec.request` 中包含一个 PEM 编码的 PKCS#10 签名请求。
-CertificateSigningRequest 使用 `spec.signerName` 字段标示 _签名者_（请求的接收方）。
+CertificateSigningRequest 使用 `spec.signerName` 字段标示签名者（请求的接收方）。
 注意，`spec.signerName` 在 `certificates.k8s.io/v1` 之后的 API 版本是必填项。
 在 Kubernetes v1.22 和以后的版本，客户可以可选地设置 `spec.expirationSeconds`
 字段来为颁发的证书设定一个特定的有效期。该字段的最小有效值是 `600`，也就是 10 分钟。
@@ -68,10 +67,8 @@ CertificateSigningRequest 使用 `spec.signerName` 字段标示 _签名者_（
 Once created, a CertificateSigningRequest must be approved before it can be signed.
 Depending on the signer selected, a CertificateSigningRequest may be automatically approved
 by a {{< glossary_tooltip text="controller" term_id="controller" >}}.
-Otherwise, a CertificateSigningRequest must be manually approved
-either via the REST API (or client-go)
-or by running `kubectl certificate approve`.
-Likewise, a CertificateSigningRequest may also be denied,
+Otherwise, a CertificateSigningRequest must be manually approved either via the REST API (or client-go)
+or by running `kubectl certificate approve`. Likewise, a CertificateSigningRequest may also be denied,
 which tells the configured signer that it must not sign the request.
 -->
 创建完成的 CertificateSigningRequest，要先通过批准，然后才能签名。
@@ -82,15 +79,12 @@ which tells the configured signer that it must not sign the request.
 同样，CertificateSigningRequest 也可能被驳回，
 这就相当于通知了指定的签名者，这个证书不能签名。
 
-<!--  
-For certificates that have been approved, the next step is signing.
-The relevant signing controller
+<!--
+For certificates that have been approved, the next step is signing. The relevant signing controller
 first validates that the signing conditions are met and then creates a certificate.
-The signing controller then updates the CertificateSigningRequest,
-storing the new certificate into
+The signing controller then updates the CertificateSigningRequest, storing the new certificate into
 the `status.certificate` field of the existing CertificateSigningRequest object. The
-`status.certificate` field is either empty or contains a X.509 certificate,
-encoded in PEM format.
+`status.certificate` field is either empty or contains a X.509 certificate, encoded in PEM format.
 The CertificateSigningRequest `status.certificate` field is empty until the signer does this.
 -->
 对于已批准的证书，下一步是签名。
@@ -101,8 +95,7 @@ The CertificateSigningRequest `status.certificate` field is empty until the sign
 直到签名完成前，CertificateSigningRequest 的字段 `status.certificate` 都为空。
 
 <!--
-Once the `status.certificate` field has been populated,
-the request has been completed and clients can now
+Once the `status.certificate` field has been populated, the request has been completed and clients can now
 fetch the signed certificate PEM data from the CertificateSigningRequest resource.
 The signers can instead deny certificate signing if the approval conditions are not met.
 -->
@@ -111,10 +104,8 @@ The signers can instead deny certificate signing if the approval conditions are
 当然如果不满足签名条件，签名者可以拒签。
 
 <!--
-In order to reduce the number of old CertificateSigningRequest resources left
-in a cluster, a garbage collection
-controller runs periodically.
-The garbage collection removes CertificateSigningRequests that have not changed
+In order to reduce the number of old CertificateSigningRequest resources left in a cluster, a garbage collection
+controller runs periodically. The garbage collection removes CertificateSigningRequests that have not changed
 state for some duration:
 
 * Approved requests: automatically deleted after 1 hour
@@ -127,17 +118,16 @@ state for some duration:
 一个垃圾收集控制器将会周期性地运行。
 此垃圾收集器会清除在一段时间内没有改变过状态的 CertificateSigningRequests：
 
-* 已批准的请求：1小时后自动删除
-* 已拒绝的请求：1小时后自动删除
-* 已失败的请求：1小时后自动删除
-* 挂起的请求：24小时后自动删除
+* 已批准的请求：1 小时后自动删除
+* 已拒绝的请求：1 小时后自动删除
+* 已失败的请求：1 小时后自动删除
+* 挂起的请求：24 小时后自动删除
 * 所有请求：在颁发的证书过期后自动删除
 
 <!--
 ## Signers
 
-Custom signerNames can also be specified. All signers should provide information about how they work
-so that clients can predict what will happen to their CSRs.
+Custom signerNames can also be specified. All signers should provide information about how they work so that clients can predict what will happen to their CSRs.
 This includes:
 -->
 ## 签名者 {#signers}
@@ -149,27 +139,22 @@ This includes:
 
 <!--
 1. **Trust distribution**: how trust (CA bundles) are distributed.
-2.  **Permitted subjects**: any restrictions on and behavior
-   when a disallowed subject is requested.
-3. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames,
-   Email subjectAltNames, URI subjectAltNames etc,
-   and behavior when a disallowed extension is requested.
-4. **Permitted key usages / extended key usages**: any restrictions on and behavior
-   when usages different than the signer-determined usages are specified in the CSR.
-5. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR `spec.expirationSeconds` field, etc
+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. **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.
-6. **CA bit allowed/disallowed**: and behavior if a CSR contains a request
-   a for a CA certificate when the signer does not permit it.
+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.
 -->
 1. **信任分发**：信任（CA 证书包）是如何分发的。
-2. **许可的主体**：当一个受限制的主体（subject）发送请求时，相应的限制和应对手段。
-3. **许可的 x509 扩展**：包括 IP subjectAltNames、DNS subjectAltNames、
+1. **许可的主体**：当一个受限制的主体（subject）发送请求时，相应的限制和应对手段。
+1. **许可的 x509 扩展**：包括 IP subjectAltNames、DNS subjectAltNames、
    Email subjectAltNames、URI subjectAltNames 等，请求一个受限制的扩展项时的应对手段。
-4. **许可的密钥用途/扩展的密钥用途**：当用途和签名者在 CSR 中指定的用途不同时，
+1. **许可的密钥用途/扩展的密钥用途**：当用途和签名者在 CSR 中指定的用途不同时，
    相应的限制和应对手段。
-5. **过期时间/证书有效期**：过期时间由签名者确定、由管理员配置、还是由 CSR `spec.expirationSeconds` 字段指定等，
+1. **过期时间/证书有效期**：过期时间由签名者确定、由管理员配置、还是由 CSR `spec.expirationSeconds` 字段指定等，
    以及签名者决定的过期时间与 CSR `spec.expirationSeconds` 字段不同时的应对手段。
-6. **允许/不允许 CA 位**：当 CSR 包含一个签名者并不允许的 CA 证书的请求时，相应的应对手段。
+1. **允许/不允许 CA 位**：当 CSR 包含一个签名者并不允许的 CA 证书的请求时，相应的应对手段。
 
 <!--
 Commonly, the `status.certificate` field contains a single PEM-encoded X.509
@@ -218,22 +203,22 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
 -->
 ### Kubernetes 签名者 {#kubernetes-signers}
 
-Kubernetes提供了内置的签名者，每个签名者都有一个众所周知的 `signerName`:
+Kubernetes 提供了内置的签名者，每个签名者都有一个众所周知的 `signerName`:
 
 <!--
 1. `kubernetes.io/kube-apiserver-client`: signs certificates that will be honored as client certificates by the API server.
-  Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-    1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver. The CA bundle is not distributed by any other means.
-    1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign.
-       Certain subjects like cluster-admin level users or groups vary between distributions and installations,
-       but deserve additional scrutiny before approval and signing.
-       The `CertificateSubjectRestriction` admission plugin is enabled by default to restrict `system:masters`,
-       but it is often not the only cluster-admin subject in a cluster.
-    1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
-    1. Permitted key usages - must include `["client auth"]`. Must not include key usages beyond `["digital signature", "key encipherment", "client auth"]`.
-    1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
-       of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
-    1. CA bit allowed/disallowed - not allowed.
+   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
+   1. Trust distribution: signed certificates must be honored as client certificates by the API server. The CA bundle is not distributed by any other means.
+   1. Permitted subjects - no subject restrictions, but approvers and signers may choose not to approve or sign.
+      Certain subjects like cluster-admin level users or groups vary between distributions and installations,
+      but deserve additional scrutiny before approval and signing.
+      The `CertificateSubjectRestriction` admission plugin is enabled by default to restrict `system:masters`,
+      but it is often not the only cluster-admin subject in a cluster.
+   1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
+   1. Permitted key usages - must include `["client auth"]`. Must not include key usages beyond `["digital signature", "key encipherment", "client auth"]`.
+   1. Expiration/certificate lifetime - for the kube-controller-manager implementation of this signer, set to the minimum
+      of the `--cluster-signing-duration` option or, if specified, the `spec.expirationSeconds` field of the CSR object.
+   1. CA bit allowed/disallowed - not allowed.
 -->
 1. `kubernetes.io/kube-apiserver-client`：签名的证书将被 API 服务器视为客户证书。
    {{< glossary_tooltip term_id="kube-controller-manager" >}} 不会自动批准它。
@@ -278,7 +263,8 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知
 1. `kubernetes.io/kubelet-serving`: signs serving certificates that are honored as a valid kubelet serving certificate
    by the API server, but has no other guarantees.
    Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: signed certificates must be honored by the kube-apiserver as valid to terminate connections to a kubelet. The CA bundle is not distributed by any other means.
+   1. Trust distribution: signed certificates must be honored by the API server as valid to terminate connections to a kubelet.
+      The CA bundle is not distributed by any other means.
    1. Permitted subjects - organizations are exactly `["system:nodes"]`, common name starts with "`system:node:`".
    1. Permitted x509 extensions - honors key usage and DNSName/IPAddress subjectAltName extensions, forbids EmailAddress and
       URI subjectAltName extensions, drops other extensions. At least one DNS or IP subjectAltName must be present.
@@ -292,7 +278,7 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知
    1. 信任分发：签名的证书必须被 kube-apiserver 认可，可有效的中止 kubelet 连接。CA 证书包不通过任何其他方式分发。
    1. 许可的主体：组织名必须是 `["system:nodes"]`，用户名以 "`system:node:`" 开头
    1. 许可的 x509 扩展：允许 key usage、DNSName/IPAddress subjectAltName 等扩展，
-      禁止  EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。
+      禁止 EmailAddress、URI subjectAltName 等扩展，并丢弃其他扩展。
       至少有一个 DNS 或 IP 的 SubjectAltName 存在。
    1. 许可的密钥用途：必须是 `["key encipherment", "digital signature", "server auth"]`
    1. 过期时间/证书有效期：对于 kube-controller-manager 实现的签名者，
@@ -304,7 +290,7 @@ Kubernetes提供了内置的签名者，每个签名者都有一个众所周知
    may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
    does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
    Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
-   1. Trust distribution: None.  There is no standard trust or distribution for this signer in a Kubernetes cluster.
+   1. Trust distribution: None. There is no standard trust or distribution for this signer in a Kubernetes cluster.
    1. Permitted subjects - any
    1. Permitted x509 extensions - honors subjectAltName and key usage extensions and discards other extensions.
    1. Permitted key usages - any
@@ -423,7 +409,7 @@ To allow signing a CertificateSigningRequest:
 {{< codenew file="access/certificate-signing-request/clusterrole-sign.yaml" >}}
 
 <!--
-## Normal User
+## Normal user
 
 A few steps are required in order to get a normal user to be able to
 authenticate and invoke an API. First, this user must have a certificate issued
@@ -457,8 +443,7 @@ openssl req -new -key myuser.key -out myuser.csr
 <!--
 ### Create CertificateSigningRequest
 
-Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl.
-Below is a script to generate the CertificateSigningRequest.
+Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.
 -->
 ### 创建 CertificateSigningRequest {#create-certificatesigningrequest}
 
@@ -544,7 +529,7 @@ Export the issued certificate from the CertificateSigningRequest.
 
 从 CertificateSigningRequest 导出颁发的证书。
 
-```
+```shell
 kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
 ```
 
@@ -581,14 +566,13 @@ kubectl create rolebinding developer-binding-myuser --role=developer --user=myus
 
 The last step is to add this user into the kubeconfig file.
 
-First, we need to add new credentials:
+First, you need to add new credentials:
 -->
 ### 添加到 kubeconfig   {#add-to-kubeconfig}
 
 最后一步是将这个用户添加到 kubeconfig 文件。
-我们假设私钥和证书文件存放在 “/home/vagrant/work/” 目录中。
 
-首先，我们需要添加新的凭据：
+首先，你需要添加新的凭据：
 
 ```shell
 kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
@@ -726,7 +710,7 @@ you like. If you want to add a note for human consumption, use the
 -->
 `status.conditions.reason` 字段通常设置为一个首字母大写的对机器友好的原因码;
 这是一个命名约定，但你也可以随你的个人喜好设置。
-如果你想添加一个供人类使用的注释，那就用 `status.conditions.message`  字段。
+如果你想添加一个供人类使用的注释，那就用 `status.conditions.message` 字段。
 
 <!--
 ## Signing
@@ -737,8 +721,6 @@ The Kubernetes control plane implements each of the
 [Kubernetes signers](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers),
 as part of the kube-controller-manager.
 
-Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that
-were marked as approved.
 -->
 ## 签名   {#signing}
 
@@ -749,8 +731,12 @@ Kubernetes 控制平面实现了每一个
 每个签名者的实现都是 kube-controller-manager 的一部分。
 
 {{< note >}}
-在Kubernetes v1.18 之前，
-kube-controller-manager 签名所有标记为 approved  的 CSR。
+<!--
+Prior to Kubernetes v1.18, the kube-controller-manager would sign any CSRs that
+were marked as approved.
+-->
+在 Kubernetes v1.18 之前，
+kube-controller-manager 签名所有标记为 approved 的 CSR。
 {{< /note >}}
 
 {{< note >}}