whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Switch language name 'zh' to 'zh-cn'

Browse Source 
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.

- The upstream docsy theme changed the language name, leading to many warnings during site build;
  The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.

There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.

We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.

This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/tasks/tls/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "TLS"
weight: 100
description: 了解如何使用传输层安全性（ TLS ）保护集群中的流量。
---
content/zh-cn/docs/tasks/tls/certificate-rotation.md
+132
View File
@@ -0,0 +1,132 @@
---
title: 为 kubelet 配置证书轮换
content_type: task
---
<!--
reviewers:
- jcbsmpsn
- mikedanese
title: Configure Certificate Rotation for the Kubelet
content_type: task
-->
<!-- overview -->
<!--
This page shows how to enable and configure certificate rotation for the kubelet.
-->
本文展示如何在 kubelet 中启用并配置证书轮换。
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
## {{% heading "prerequisites" %}}
<!--
* Kubernetes version 1.8.0 or later is required
-->
* 要求 Kubernetes 1.8.0 或更高的版本
<!-- steps -->
<!--
## Overview
The kubelet uses certificates for authenticating to the Kubernetes API. By
default, these certificates are issued with one year expiration so that they do
not need to be renewed too frequently.
-->
## 概述
Kubelet 使用证书进行 Kubernetes API 的认证。
默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。
<!--
Kubernetes contains [kubelet certificate
rotation](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/),
that will automatically generate a new key and request a new certificate from
the Kubernetes API as the current certificate approaches expiration. Once the
new certificate is available, it will be used for authenticating connections to
the Kubernetes API.
-->
Kubernetes 包含特性
[kubelet 证书轮换](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)，
在当前证书即将过期时，
将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与
Kubernetes API 间的连接认证。
<!--
## Enabling client certificate rotation
The `kubelet` process accepts an argument `--rotate-certificates` that controls
if the kubelet will automatically request a new certificate as the expiration of
the certificate currently in use approaches.
-->
## 启用客户端证书轮换
`kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的
证书即将到期时，是否会自动申请新的证书。
<!--
The `kube-controller-manager` process accepts an argument
`--cluster-signing-duration` (`--experimental-cluster-signing-duration` prior to 1.19)
that controls how long certificates will be issued for.
-->
`kube-controller-manager` 进程接收 `--cluster-signing-duration` 参数
（在 1.19 版本之前为 `--experimental-cluster-signing-duration`），用来
控制签发证书的有效期限。
<!--
## Understanding the certificate rotation configuration
When a kubelet starts up, if it is configured to bootstrap (using the
`--bootstrap-kubeconfig` flag), it will use its initial certificate to connect
to the Kubernetes API and issue a certificate signing request. You can view the
status of certificate signing requests using:
-->
## 理解证书轮换配置
当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet
会使用其初始证书连接到 Kubernetes API ，并发送证书签名的请求。
可以通过以下方式查看证书签名请求的状态：
```shell
kubectl get csr
```
<!--
Initially a certificate signing request from the kubelet on a node will have a
status of `Pending`. If the certificate signing requests meets specific
criteria, it will be auto approved by the controller manager, then it will have
a status of `Approved`. Next, the controller manager will sign a certificate,
issued for the duration specified by the
`--cluster-signing-duration` parameter, and the signed certificate
will be attached to the certificate signing request.
-->
最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件，
控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书，
证书的有效期限由 `--cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
<!--
The kubelet will retrieve the signed certificate from the Kubernetes API and
write that to disk, in the location specified by `--cert-dir`. Then the kubelet
will use the new certificate to connect to the Kubernetes API.
-->
Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir`
参数指定。
然后 kubelet 会使用新的证书连接到 Kubernetes API。
<!--
As the expiration of the signed certificate approaches, the kubelet will
automatically issue a new certificate signing request, using the Kubernetes API.
This can happen at any point between 30% and 10% of the time remaining on the
certificate. Again, the controller manager will automatically approve the certificate
request and attach a signed certificate to the certificate signing request. The
kubelet will retrieve the new signed certificate from the Kubernetes API and
write that to disk. Then it will update the connections it has to the
Kubernetes API to reconnect using the new certificate.
-->
当签署的证书即将到期时，kubelet 会使用 Kubernetes API，自动发起新的证书签名请求。
该请求会发生在证书的有效时间剩下 30% 到 10% 之间的任意时间点。
同样地，控制器管理器会自动批准证书请求，并将签署的证书附加到证书签名请求中。 Kubelet
会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API
的连接，使用新的证书重新连接到 Kubernetes API。
content/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster.md
+549
View File
@@ -0,0 +1,549 @@
---
title: 管理集群中的 TLS 认证
content_type: task
---
<!--
title: Manage TLS Certificates in a Cluster
content_type: task
reviewers:
- mikedanese
- beacham
- liggit
-->
<!-- overview -->
<!--
Kubernetes provides a `certificates.k8s.io` API, which lets you provision TLS
certificates signed by a Certificate Authority (CA) that you control. These CA
and certificates can be used by your workloads to establish trust.
`certificates.k8s.io` API uses a protocol that is similar to the [ACME
draft](https://github.com/ietf-wg-acme/acme/).
-->
Kubernetes 提供 `certificates.k8s.io` API，可让你配置由你控制的证书颁发机构（CA）
签名的 TLS 证书。 你的工作负载可以使用这些 CA 和证书来建立信任。
`certificates.k8s.io` API使用的协议类似于
[ACME 草案](https://github.com/ietf-wg-acme/acme/)。
{{< note >}}
<!--
Certificates created using the `certificates.k8s.io` API are signed by a
[dedicated CA](#a-note-to-cluster-administrators). It is possible to configure your cluster to use the cluster root
CA for this purpose, but you should never rely on this. Do not assume that
these certificates will validate against the cluster root CA.
-->
使用 `certificates.k8s.io` API 创建的证书由指定 [CA](#a-note-to-cluster-administrators) 颁发。
将集群配置为使用集群根目录 CA 可以达到这个目的，但是你永远不要依赖这一假定。
不要以为这些证书将针对群根目录 CA 进行验证。
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!--
You need the `cfssl` tool. You can download `cfssl` from
[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
Some steps in this page use the `jq` tool. If you don't have `jq`, you can
install it via your operating system's software sources, or fetch it from
[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/).
-->
你需要 `cfssl` 工具。
你可以从 [https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)
下载 `cfssl`。
本文中某些步骤使用 `jq` 工具。如果你没有 `jq`，你可以通过操作系统的软件源安装，
或者从 [https://stedolan.github.io/jq/](https://stedolan.github.io/jq/) 获取。
<!-- steps -->
<!--
## Trusting TLS in a cluster
Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires
some extra application configuration. You will need to add the CA certificate
bundle to the list of CA certificates that the TLS client or server trusts. For
example, you would do this with a golang TLS config by parsing the certificate
chain and adding the parsed certificates to the `RootCAs` field in the
[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) struct.
-->
## 集群中的 TLS 信任
信任 Pod 中运行的应用程序所提供的[自定义 CA](#a-note-to-cluster-administrators) 通常需要一些额外的应用程序配置。
你需要将 CA 证书包添加到 TLS 客户端或服务器信任的 CA 证书列表中。
例如，你可以使用 Golang TLS 配置通过解析证书链并将解析的证书添加到
[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) 结构中的 `RootCAs`
字段中。
{{< note >}}
<!--
Even though the custom CA certificate may be included in the filesystem (in the
ConfigMap `kube-root-ca.crt`),
you should not use that certificate authority for any purpose other than to verify internal
Kubernetes endpoints. An example of an internal Kubernetes endpoint is the
Service named `kubernetes` in the default namespace.
If you want to use a custom certificate authority for your workloads, you should generate
that CA separately, and distribute its CA certificate using a
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your pods
have access to read.
-->
即使自定义 CA 证书可能包含在文件系统中（在 ConfigMap `kube-root-ca.crt` 中），
除了验证内部 Kubernetes 端点之外，你不应将该证书颁发机构用于任何目的。
内部 Kubernetes 端点的一个示例是默认命名空间中名为 `kubernetes` 的服务。
如果你想为你的工作负载使用自定义证书颁发机构，你应该单独生成该 CA，
并使用你的 Pod 有读权限的 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap)
分发该 CA 证书。
{{< /note >}}
<!--
## Requesting a certificate
The following section demonstrates how to create a TLS certificate for a
Kubernetes service accessed through DNS.
{{< note >}}
This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
{{< /note >}}
-->
## 请求证书
以下部分演示如何为通过 DNS 访问的 Kubernetes 服务创建 TLS 证书。
{{< note >}}
本教程使用 CFSSL：Cloudflare's PKI 和 TLS 工具包
[点击此处](https://blog.cloudflare.com/introducing-cfssl/)了解更多信息。
{{< /note >}}
<!--
## Create a certificate signing request
Generate a private key and certificate signing request (or CSR) by running
the following command:
-->
## 创建证书签名请求
通过运行以下命令生成私钥和证书签名请求（或 CSR）:
```shell
cat <<EOF | cfssl genkey - | cfssljson -bare server
{
"hosts": [
"my-svc.my-namespace.svc.cluster.local",
"my-pod.my-namespace.pod.cluster.local",
"192.0.2.24",
"10.0.34.2"
],
"CN": "my-pod.my-namespace.pod.cluster.local",
"key": {
"algo": "ecdsa",
"size": 256
}
}
EOF
```
<!--
Where `192.0.2.24` is the service's cluster IP,
`my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
`10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
is the pod's DNS name. You should see the output similar to:
-->
其中 `192.0.2.24` 是服务的集群 IP，`my-svc.my-namespace.svc.cluster.local`
是服务的 DNS 名称，`10.0.34.2` 是 Pod 的 IP，而
`my-pod.my-namespace.pod.cluster.local` 是 Pod 的 DNS 名称。
你能看到的输出类似于：
```
2022/02/01 11:45:32 [INFO] generate received request
2022/02/01 11:45:32 [INFO] received CSR
2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
2022/02/01 11:45:32 [INFO] encoded CSR
```
<!--
This command generates two files; it generates `server.csr` containing the PEM
encoded [PKCS#10](https://tools.ietf.org/html/rfc2986) certification request,
and `server-key.pem` containing the PEM encoded key to the certificate that
is still to be created.
-->
此命令生成两个文件；它生成包含 PEM 编码
[PKCS#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`，
以及 PEM 编码密钥的 `server-key.pem`，用于待生成的证书。
<!--
## Create a CertificateSigningRequest object to send to the Kubernetes API
Generate a CSR yaml blob and send it to the apiserver by running the following
command:
-->
## 创建证书签名请求（CSR）对象发送到 Kubernetes API
使用以下命令创建 CSR YAML 文件，并发送到 API 服务器：
```shell
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: my-svc.my-namespace
spec:
request: $(cat server.csr | base64 | tr -d '\n')
signerName: example.com/serving
usages:
- digital signature
- key encipherment
- server auth
EOF
```
<!--
Notice that the `server.csr` file created in step 1 is base64 encoded
and stashed in the `.spec.request` field. You are also requesting a
certificate with the "digital signature", "key encipherment", and "server
auth" key usages, signed by an example `example.com/serving` signer.
A specific `signerName` must be requested.
View documentation for [supported signer names](/docs/reference/access-authn-authz/certificate-signing-requests/#signers)
for more information.
The CSR should now be visible from the API in a Pending state. You can see
it by running:
-->
请注意，在步骤 1 中创建的 `server.csr` 文件是 base64 编码并存储在
`.spec.request` 字段中的。你还要求提供 “digital signature（数字签名）”，
“密钥加密（key encipherment）” 和 “服务器身份验证（server auth）” 密钥用途，
由 `example.com/serving` 示例签名程序签名的证书。
你也可以要求使用特定的 `signerName`。更多信息可参阅
[支持的签署者名称](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signers)。
在 API server 中可以看到这些 CSR 处于 Pending 状态。执行下面的命令你将可以看到：
```shell
kubectl describe csr my-svc.my-namespace
```
```none
Name: my-svc.my-namespace
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 01 Feb 2022 11:49:15 -0500
Requesting User: yourname@example.com
Signer: example.com/serving
Status: Pending
Subject:
Common Name: my-pod.my-namespace.pod.cluster.local
Serial Number:
Subject Alternative Names:
DNS Names: my-pod.my-namespace.pod.cluster.local
my-svc.my-namespace.svc.cluster.local
IP Addresses: 192.0.2.24
10.0.34.2
Events: <none>
```
<!--
## Get the CertificateSigningRequest approved {#get-the-certificate-signing-request-approved}
Approving the [certificate signing request](/docs/reference/access-authn-authz/certificate-signing-requests/)
is either done by an automated approval process or on a one off basis by a cluster
administrator. If you're authorized to approve a certificate request, you can do that
manually using `kubectl`; for example:
-->
## 批准证书签名请求（CSR） {#get-the-certificate-signing-request-approved}
[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
的批准或者是通过自动批准过程完成的，或由集群管理员一次性完成。
如果你被授权批准证书请求，你可以使用 `kubectl` 来手动完成此操作；例如：
```shell
kubectl certificate approve my-svc.my-namespace
```
```none
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
```
<!-- You should now see the following: -->
你现在应该能看到如下输出：
```shell
kubectl get csr
```
```none
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
my-svc.my-namespace 10m example.com/serving yourname@example.com <none> Approved
```
<!--
This means the certificate request has been approved and is waiting for the
requested signer to sign it.
-->
这意味着证书请求已被批准，并正在等待请求的签名者对其签名。
<!--
## Sign the CertificateSigningRequest {#sign-the-certificate-signing-request}
Next, you'll play the part of a certificate signer, issue the certificate, and upload it to the API.
A signer would typically watch the CertificateSigningRequest API for objects with its `signerName`,
check that they have been approved, sign certificates for those requests,
and update the API object status with the issued certificate.
-->
## 签名证书签名请求（CSR） {#sign-the-certificate-signing-request}
接下来，你将扮演证书签署者的角色，颁发证书并将其上传到 API 服务器。
签名者通常会使用其 `signerName` 查看对象的 CertificateSigningRequest API，
检查它们是否已被批准，为这些请求签署证书，并使用已颁发的证书更新 API 对象状态。
<!--
### Create a Certificate Authority
You need an authority to provide the digital signature on the new certificate.
First, create a signing certificate by running the following:
-->
### 创建证书颁发机构
你需要授权在新证书上提供数字签名。
首先，通过运行以下命令创建签名证书：
```shell
cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
"CN": "My Example Signer",
"key": {
"algo": "rsa",
"size": 2048
}
}
EOF
```
<!-- You should see output similar to: -->
你应该看到类似于以下的输出：
```none
2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
2022/02/01 11:50:39 [INFO] generate received request
2022/02/01 11:50:39 [INFO] received CSR
2022/02/01 11:50:39 [INFO] generating key: rsa-2048
2022/02/01 11:50:39 [INFO] encoded CSR
2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472
```
<!--
This produces a certificate authority key file (`ca-key.pem`) and certificate (`ca.pem`).
-->
这会产生一个证书颁发机构密钥文件（`ca-key.pem`）和证书（`ca.pem`）。
<!-- ### Issue a certificate -->
### 颁发证书
{{< codenew file="tls/server-signing-config.json" >}}
<!--
Use a `server-signing-config.json` signing configuration and the certificate authority key file
and certificate to sign the certificate request:
-->
使用 `server-signing-config.json` 签名配置、证书颁发机构密钥文件和证书来签署证书请求：
```shell
kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
base64 --decode | \
cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
cfssljson -bare ca-signed-server
```
<!-- You should see output similar to: -->
你应该看到类似于以下的输出：
```
2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337
```
<!-- This produces a signed serving certificate file, `ca-signed-server.pem`. -->
这会生成一个签名的服务证书文件，`ca-signed-server.pem`。
<!--
### Upload the signed certificate
Finally, populate the signed certificate in the API object's status:
-->
### 上传签名证书
最后，在 API 对象的状态中填充签名证书：
```shell
kubectl get csr my-svc.my-namespace -o json | \
jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -
```
{{< note >}}
<!--
This uses the command line tool [`jq`](https://stedolan.github.io/jq/) to populate the base64-encoded
content in the `.status.certificate` field.
If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and
upload the resulting file.
-->
这使用命令行工具 [`jq`](https://stedolan.github.io/jq/)
在 `.status.certificate` 字段中填充 base64 编码的内容。
如果你没有 `jq` 工具，你还可以将 JSON 输出保存到文件中，手动填充此字段，然后上传结果文件。
{{< /note >}}
<!--
Once the CSR is approved and the signed certificate is uploaded, run:
-->
批准 CSR 并上传签名证书后，运行：
```shell
kubectl get csr
```
<!-- The output is similar to: -->
输入类似于：
```none
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
my-svc.my-namespace 20m example.com/serving yourname@example.com <none> Approved,Issued
```
<!--
## Download the certificate and use it
Now, as the requesting user, you can download the issued certificate
and save it to a `server.crt` file by running the following:
-->
## 下载证书并使用它
现在，作为请求用户，你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中：
CSR 被签署并获得批准后，你应该看到以下内容：
```shell
kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
```
<!--
Now you can populate `server.crt` and `server-key.pem` in a
{{< glossary_tooltip text="Secret" term_id="secret" >}}
that you could later mount into a Pod (for example, to use with a webserver
that serves HTTPS).
-->
现在你可以将 `server.crt` 和 `server-key.pem` 填充到
{{<glossary_tooltip text="Secret" term_id="secret" >}} 中，
稍后你可以将其挂载到 Pod 中（例如，用于提供 HTTPS 的网络服务器）。
```shell
kubectl create secret tls server --cert server.crt --key server-key.pem
```
```none
secret/server created
```
<!--
Finally, you can populate `ca.pem` into a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
and use it as the trust root to verify the serving certificate:
-->
最后，你可以将 `ca.pem` 填充到
{{<glossary_tooltip text="ConfigMap" term_id="configmap" >}}
并将其用作信任根来验证服务证书：
```shell
kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
```
```none
configmap/example-serving-ca created
```
<!--
## Approving CertificateSigningRequests {#approving-certificate-signing-requests}
A Kubernetes administrator (with appropriate permissions) can manually approve
(or deny) CertificateSigningRequests by using the `kubectl certificate
approve` and `kubectl certificate deny` commands. However if you intend
to make heavy usage of this API, you might consider writing an automated
certificates controller.
-->
## 批准证书签名请求（CSR） {#approving-certificate-signing-requests}
Kubernetes 管理员（具有适当权限）可以使用 `kubectl certificate approve` 和
`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求（CSR）。
但是，如果你打算大量使用此 API，则可以考虑编写自动化的证书控制器。
{{< caution >}}
<!--
The ability to approve CSRs decides who trusts whom within your environment. The
ability to approve CSRs should not be granted broadly or lightly.
You should make sure that you confidently understand both the verification requirements
that fall on the approver **and** the repercussions of issuing a specific certificate
before you grant the `approve` permission.
-->
批准证书 CSR 的能力决定了在你的环境中谁信任谁。
不应广泛或轻率地授予批准 CSR 的能力。
在授予 `approve` 权限之前，你应该确保自己充分了解批准人的验证要求**和**颁发特定证书的后果。
{{< /caution >}}
<!--
Whether a machine or a human using kubectl as above, the role of the _approver_ is
to verify that the CSR satisfies two requirements:
-->
无论上述机器或人使用 kubectl，“批准者”的作用是验证 CSR 满足如下两个要求：
<!--
1. The subject of the CSR controls the private key used to sign the CSR. This
addresses the threat of a third party masquerading as an authorized subject.
In the above example, this step would be to verify that the pod controls the
private key used to generate the CSR.
2. The subject of the CSR is authorized to act in the requested context. This
addresses the threat of an undesired subject joining the cluster. In the
above example, this step would be to verify that the pod is allowed to
participate in the requested service.
-->
1. CSR 的 subject 控制用于签署 CSR 的私钥。这解决了伪装成授权主体的第三方的威胁。
在上述示例中，此步骤将验证该 Pod 控制了用于生成 CSR 的私钥。
2. CSR 的 subject 被授权在请求的上下文中执行。
这点用于处理不期望的主体被加入集群的威胁。
在上述示例中，此步骤将是验证该 Pod 是否被允许加入到所请求的服务中。
<!--
If and only if these two requirements are met, the approver should approve
the CSR and otherwise should deny the CSR.
For more information on certificate approval and access control, read
the [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
reference page.
-->
当且仅当满足这两个要求时，审批者应该批准 CSR，否则拒绝 CSR。
有关证书批准和访问控制的更多信息，
请阅读[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)参考页。
<!--
## Configuring your cluster to provide signing
This page assumes that a signer is setup to serve the certificates API. The
Kubernetes controller manager provides a default implementation of a signer. To
enable it, pass the `--cluster-signing-cert-file` and
`--cluster-signing-key-file` parameters to the controller manager with paths to
your Certificate Authority's keypair.
-->
## 给集群管理员的一个建议
本页面假设已经为 certificates API 配置了签名者。
Kubernetes 控制器管理器提供了一个签名者的默认实现。要启用它，请为控制器管理器设置
`--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数，
使之取值为你的证书机构的密钥对的路径。
content/zh-cn/docs/tasks/tls/manual-rotation-of-ca-certificates.md
+297
View File
@@ -0,0 +1,297 @@
---
title: 手动轮换 CA 证书
min-kubernetes-server-version: v1.13
content_type: task
---
<!--
title: Manual Rotation of CA Certificates
min-kubernetes-server-version: v1.13
content_type: task
-->
<!-- overview -->
<!--
This page shows how to manually rotate the certificate authority (CA) certificates.
-->
本页展示如何手动轮换证书机构（CA）证书。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
- For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication).
- For more information about best practices for CA certificates, see [Single root CA](/docs/setup/best-practices/certificates/#single-root-ca).
-->
- 要了解 Kubernetes 中用户认证的更多信息，参阅
[认证](/zh/docs/reference/access-authn-authz/authentication)；
- 要了解与 CA 证书最佳实践有关的更多信息，参阅[单根 CA](/zh/docs/setup/best-practices/certificates/#single-root-ca)。
<!-- steps -->
<!--
## Rotate the CA certificates manually
-->
## 手动轮换 CA 证书 {#rotate-the-ca-certificates-manually}
<!--
Make sure to back up your certificate directory along with configuration files and any other necessary files.
This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers.
Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another.
Configurations with a single API server will experience unavailability while the API server is being restarted.
-->
{{< caution >}}
确保备份你的证书目录、配置文件以及其他必要文件。
这里的方法假定 Kubernetes 的控制面通过运行多个 API 服务器以高可用配置模式运行。
另一假定是 API 服务器可体面地终止，因而客户端可以彻底地与一个 API 服务器断开
连接并连接到另一个 API 服务器。
如果集群中只有一个 API 服务器，则在 API 服务器重启期间会经历服务中断期。
{{< /caution >}}
<!--
1. Distribute the new CA certificates and private keys
(ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`)
to all your control plane nodes in the Kubernetes certificates directory.
-->
1. 将新的 CA 证书和私钥（例如：`ca.crt`、`ca.key`、`front-proxy-ca.crt` 和
`front-proxy-client.key`）分发到所有控制面节点，放在其 Kubernetes 证书目录下。
<!--
1. Update {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}'s `--root-ca-file` to
include both old and new CA. Then restart the component.
Any service account created after this point will get secrets that include both old and new CAs.
{{< note >}}
The files specified by the kube-controller-manager flags `--client-ca-file` and `--cluster-signing-cert-file`
cannot be CA bundles. If these flags and `--root-ca-file` point to the same `ca.crt` file which is now a
bundle (includes both old and new CA) you will face an error. To workaround this problem you can copy the new CA to a separate
file and make the flags `--client-ca-file` and `--cluster-signing-cert-file` point to the copy. Once `ca.crt` is no longer
a bundle you can restore the problem flags to point to `ca.crt` and delete the copy.
{{< /note >}}
-->
2. 更新 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 的
`--root-ca-file` 标志，使之同时包含老的和新的 CA，之后重启组件。
自此刻起，所创建的所有服务账号都会获得同时包含老的 CA 和新的 CA 的 Secret。
{{< note >}}
kube-controller-manager 标志 `--client-ca-file` 和 `--cluster-signing-cert-file` 所引用的文件
不能是 CA 证书包。如果这些标志和 `--root-ca-file` 指向同一个 `ca.crt` 包文件（包含老的和新的 CA 证书），
你将会收到出错信息。
要解决这个问题，可以将新的 CA 证书复制到单独的文件中，并将 `--client-ca-file` 和 `--cluster-signing-cert-file`
标志指向该副本。一旦 `ca.crt` 不再是证书包文件，就可以恢复有问题的标志指向 `ca.crt` 并删除该副本。
{{< /note >}}
<!--
1. Update all service account tokens to include both old and new CA certificates.
If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs.
-->
3. 更新所有服务账号令牌，使之同时包含老的和新的 CA 证书。
如果在 API 服务器使用新的 CA 之前启动了新的 Pod，这些 Pod
也会获得此更新并且同时信任老的和新的 CA 证书。
<!--
```shell
base64_encoded_ca="$(base64 -w0 <path to file containing both old and new CAs>)"
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
done
done
```
-->
```shell
base64_encoded_ca="$(base64 -w0 <path to file containing both old and new CAs>)"
for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
done
done
```
<!--
1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets.
* Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected.
1. Append the both old and new CA to the file against `-client-ca-file` and `-kubelet-certificate-authority` flag in the `kube-apiserver` configuration.
1. Append the both old and new CA to the file against `-client-ca-file` flag in the `kube-scheduler` configuration.
-->
4. 重启所有使用集群内配置的 Pods（例如：`kube-proxy`、`coredns` 等），以便这些 Pod 能够使用
来自 *ServiceAccount* Secret 中的、已更新的证书机构数据。
* 确保 `coredns`、`kube-proxy` 和其他使用集群内配置的 Pod 都正按预期方式工作。
5. 将老的和新的 CA 都追加到 `kube-apiserver` 配置的 `--client-ca-file` 和 `--kubelet-certificate-authority` 标志所指的文件。
6. 将老的和新的 CA 都追加到 `kube-scheduler` 配置的 `--client-ca-file` 标志所指的文件。
<!--
1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively.
For information about creating certificates for individual user accounts, see
[Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts).
Additionally, update the `certificate-authority-data` section in the kubeconfig files,
respectively with Base64-encoded old and new certificate authority data
-->
7. 通过替换 `client-certificate-data` 和 `client-key-data`
中的内容，更新用户账号的证书。
有关为独立用户账号创建证书的更多信息，可参阅
[为用户帐号配置证书](/zh/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts)。
另外，还要更新 kubeconfig 文件中的 `certificate-authority-data`
节，使之包含 Base64 编码的老的和新的证书机构数据。
<!--
1. Follow below steps in a rolling fashion.
1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)*
or *webhook handlers* to trust the new CA certificates.
1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and
`certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes.
If your kubelet is not using client certificate rotation update `client-certificate-data` and
`client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file
usually found in `/var/lib/kubelet/pki`.
-->
8. 遵循下列步骤执行滚动更新
1. 重新启动所有其他 *[被聚合的 API 服务器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)*
或者 *Webhook 处理程序*，使之信任新的 CA 证书。
2. 在所有节点上更新 kubelet 配置中的 `clientCAFile` 所指文件以及 kubelet.conf 中的
`certificate-authority-data` 并重启 kubelet 以同时使用老的和新的 CA 证书。
如果你的 kubelet 并未使用客户端证书轮换，则在所有节点上更新 kubelet.conf 中
`client-certificate-data` 和 `client-key-data` 以及 kubelet
客户端证书文件（通常位于 `/var/lib/kubelet/pki` 目录下）
<!--
1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and
`front-proxy-client.crt`) signed by new CA.
You can use the existing private keys or new private keys.
If you changed the private keys then update these in the Kubernetes certificates directory as well.
-->
3. 使用用新的 CA 签名的证书
（`apiserver.crt`、`apiserver-kubelet-client.crt` 和 `front-proxy-client.crt`）
来重启 API 服务器。
你可以使用现有的私钥，也可以使用新的私钥。
如果你改变了私钥，则要将更新的私钥也放到 Kubernetes 证书目录下。
由于 Pod 既信任老的 CA 也信任新的 CA，Pod 中的客户端会经历短暂的连接断开状态，
之后再连接到使用新的 CA 所签名的证书的新的 API 服务器。
<!--
* Restart Scheduler to use the new CAs.
* Make sure control plane components logs no TLS errors.
-->
* 重启调度器以使用新的 CA 证书。
* 确保控制面组件的日志中没有 TLS 相关的错误信息。
<!--
To generate certificates and private keys for your cluster using the `openssl`
command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl).
You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).
-->
{{< note >}}
要使用 `openssl` 命令行为集群生成新的证书和私钥，可参阅
[证书（`openssl`）](/zh/docs/tasks/administer-cluster/certificates/#openssl)。
你也可以使用[`cfssl`](/zh/docs/tasks/administer-cluster/certificates/#cfssl).
{{< /note >}}
<!--
1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion.
Example:
-->
4. 为 Daemonset 和 Deployment 添加注解，从而触发较安全的滚动更新，替换 Pod。
示例：
```shell
for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
done
for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
done
done
```
<!--
To limit the number of concurrent disruptions that your application experiences,
see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).
-->
{{< note >}}
要限制应用可能受到的并发干扰数量，可以参阅
[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/).
{{< /note >}}
<!--
1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA.
-->
9. 如果你的集群使用启动引导令牌来添加节点，则需要更新 `kube-public` 名字空间下的
ConfigMap `cluster-info`，使之包含新的 CA 证书。
```shell
base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
kubectl get cm/cluster-info --namespace kube-public -o yaml | \
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
```
<!--
1. Verify the cluster functionality.
1. Validate the logs from control plane components, along with the kubelet and the
kube-proxy are not throwing any tls errors, see
[looking at the logs](/docs/tasks/debug/debug-cluster/#looking-at-logs).
1. Validate logs from any aggregated api servers and pods using in-cluster config.
-->
10. 验证集群的功能正常
1. 验证控制面组件的日志，以及 `kubelet` 和 `kube-proxy` 的日志，确保其中没有
抛出 TLS 错误，参阅
[查看日志](/zh/docs/tasks/debug/debug-cluster/#looking-at-logs).
2. 验证被聚合的 API 服务器的日志，以及所有使用集群内配置的 Pod 的日志。
<!--
1. Once the cluster functionality is successfully verified:
1. Update all service account tokens to include new CA certificate only.
* All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted.
1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp.
1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file.
-->
11. 完成集群功能的检查之后：
1. 更新所有的服务账号令牌，使之仅包含新的 CA 证书。
* 使用集群内 kubeconfig 的 Pod 最终也需要被重启，以获得新的服务账号 Secret
数据，进而不再信任老的 CA 证书。
1. 从 kubeconfig 文件和 `--client-ca-file` 以及 `--root-ca-file` 标志所指向的文件
中去除老的 CA 数据，之后重启控制面组件。
1. 重启 kubelet，移除 `clientCAFile` 标志所指向的文件以及 kubelet kubeconfig 文件中
的老的 CA 数据。