kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[zh] sync encrypt-data.md

This commit is contained in:
windsonsea 2023-09-05 09:16:35 +08:00
parent a8c3b3ff5a
commit deb3a8bf56
1 changed files with 98 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

131
content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md
View File

@ -39,6 +39,7 @@ encrypt Secret objects, including the key-value data they contain.
此任务涵盖使用 {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}
存储的资源数据的加密。
例如，你可以加密 Secret 对象，包括它们包含的键值数据。
<!--
If you want to encrypt data in filesystems that are mounted into containers, you instead need
to either:
@ -274,7 +275,7 @@ read that resource will fail until it is deleted or a valid decryption key is pr
任何尝试读取资源的调用将会失败，直到它被删除或提供有效的解密密钥。
{{< /caution >}}
### Providers
### Provider
<!--
The following table describes each available provider:
@ -283,7 +284,9 @@ The following table describes each available provider:
<table class="complex-layout">
<caption style="display: none;">
<!-- Providers for Kubernetes encryption at rest -->
<!--
Providers for Kubernetes encryption at rest
-->
Kubernetes 静态数据加密的 Provider
</caption>
<thead>
@ -306,8 +309,10 @@ Kubernetes 静态数据加密的 Provider
</tr>
<tr>
<td colspan="4">
<!-- Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written. Existing encrypted resources are <strong>not</strong> automatically overwritten with the plaintext data.
The <tt>identity</tt> provider is the default if you do not specify otherwise. -->
<!--
Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written. Existing encrypted resources are <strong>not</strong> automatically overwritten with the plaintext data.
The <tt>identity</tt> provider is the default if you do not specify otherwise.
-->
不加密写入的资源。当设置为第一个 provider 时，已加密的资源将在新值写入时被解密。
</td>
</tr>
@ -316,7 +321,9 @@ Kubernetes 静态数据加密的 Provider
<tr>
<th rowspan="2" scope="row"><tt>aescbc</tt></th>
<td>
<!-- AES-CBC with <a href="https://datatracker.ietf.org/doc/html/rfc2315">PKCS#7</a> padding -->
<!--
AES-CBC with <a href="https://datatracker.ietf.org/doc/html/rfc2315">PKCS#7</a> padding
-->
带有 <a href="https://datatracker.ietf.org/doc/html/rfc2315">PKCS#7</a> 填充的 AES-CBC
</td>
<td><!-- Weak -->弱</td>
@ -325,18 +332,24 @@ Kubernetes 静态数据加密的 Provider
</tr>
<tr>
<td colspan="4">
<!-- Not recommended due to CBC's vulnerability to padding oracle attacks. Key material accessible from control plane host. -->
<!--
Not recommended due to CBC's vulnerability to padding oracle attacks. Key material accessible from control plane host.
-->
由于 CBC 容易受到密文填塞攻击（Padding Oracle Attack），不推荐使用。密钥材料可从控制面主机访问。
</td>
</tr>
<tr>
<th rowspan="2" scope="row"><tt>aesgcm</tt></th>
<td>
<!-- AES-GCM with random nonce -->
<!--
AES-GCM with random nonce
-->
带有随机数的 AES-GCM
</td>
<td>
<!-- Must be rotated every 200,000 writes -->
<!--
Must be rotated every 200,000 writes
-->
每写入 200k 次后必须轮换
</td>
<td><!-- Fastest -->最快</td>
@ -344,14 +357,18 @@ Kubernetes 静态数据加密的 Provider
</tr>
<tr>
<td colspan="4">
<!-- Not recommended for use except when an automated key rotation scheme is implemented. Key material accessible from control plane host. -->
<!--
Not recommended for use except when an automated key rotation scheme is implemented. Key material accessible from control plane host.
-->
不建议使用，除非实施了自动密钥轮换方案。密钥材料可从控制面主机访问。
</td>
</tr>
<tr>
<th rowspan="2" scope="row"><tt>kms</tt> v1 <em><!--(deprecated since Kubernetes v1.28)-->（自 Kubernetes 1.28 起弃用）</em></th>
<td>
<!-- Uses envelope encryption scheme with DEK per resource. -->
<!--
Uses envelope encryption scheme with DEK per resource.
-->
针对每个资源使用不同的 DEK 来完成信封加密。
</td>
<td><!-- Strongest -->最强</td>
@ -380,7 +397,9 @@ Kubernetes 静态数据加密的 Provider
<tr>
<th rowspan="2" scope="row"><tt>kms</tt> v2 <em>(beta)</em></th>
<td>
<!-- Uses envelope encryption scheme with DEK per API server. -->
<!--
Uses envelope encryption scheme with DEK per API server.
-->
针对每个 API 服务器使用不同的 DEK 来完成信封加密。
</td>
<td><!-- Strongest -->最强</td>
@ -440,7 +459,7 @@ Kubernetes 静态数据加密的 Provider
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
is the first provider, the first key is used for encryption.
-->
每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。
每个 Provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 Provider，则第一个密钥用于加密。
{{< caution >}}
<!--
@ -574,7 +593,7 @@ To create a new Secret, perform the following steps:
...
- name: enc # 增加这一行
mountPath: /etc/kubernetes/enc # 增加这一行
readonly: true # 增加这一行
readOnly: true # 增加这一行
...
volumes:
...
@ -600,31 +619,54 @@ permissions on your control-plane nodes so only the user who runs the `kube-apis
{{< /caution >}}
<!--
## Verifying that data is encrypted
### Reconfigure other control plane hosts {#api-server-config-update-more}
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or
updated Secret or other resource types configured in `EncryptionConfiguration` should be encrypted
when stored. To check this, you can use the `etcdctl` command line
If you have multiple API servers in your cluster, you should deploy the
changes in turn to each API server.
Make sure that you use the **same** encryption configuration on each
control plane host.
-->
### 重新配置其他控制平面主机 {#api-server-config-update-more}
如果你的集群中有多个 API 服务器，应轮流将更改部署到每个 API 服务器。
确保在每个控制平面主机上使用**相同的**加密配置。
<!--
### Verify that newly written data is encrypted {#verifying-that-data-is-encrypted}
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly
created or updated Secret (or other resource kinds configured in `EncryptionConfiguration`)
should be encrypted when stored.
To check this, you can use the `etcdctl` command line
program to retrieve the contents of your secret data.
1. Create a new Secret called `secret1` in the `default` namespace:
This example shows how to check this for encrypting the Secret API.
-->
## 验证数据已被加密 {#verifying-that-data-is-encryped}
### 验证数据已被加密 {#verifying-that-data-is-encryped}
数据在写入 etcd 时会被加密。重新启动你的 `kube-apiserver` 后，任何新创建或更新的 Secret
或在 `EncryptionConfiguration` 中配置的其他资源类型都应在存储时被加密。
或在 `EncryptionConfiguration` 中配置的其他资源类别都应在存储时被加密。
如果想要检查，你可以使用 `etcdctl` 命令行程序来检索你的 Secret 数据内容。
1. 创建一个新的 secret，名称为 `secret1`，命名空间为 `default`：
以下示例演示了如何对加密 Secret API 进行检查。
<!--
1. Create a new Secret called `secret1` in the `default` namespace:
-->
1. 创建一个新的 Secret，名称为 `secret1`，命名空间为 `default`：
```shell
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
<!--
1. Using the `etcdctl` command line, read that Secret out of etcd:
1. Using the `etcdctl` command line tool, read that Secret out of etcd:
-->
2. 使用 `etcdctl` 命令行，从 etcd 中读取 Secret：
2. 使用 `etcdctl` 命令行工具，从 etcd 中读取 Secret：
```
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
@ -686,38 +728,61 @@ program to retrieve the contents of your secret data.
```
<!--
The output should contain `mykey: bXlkYXRh`, with contents of `mydata` encoded, check
The output should contain `mykey: bXlkYXRh`, with contents of `mydata` encoded using base64;
read
[decoding a Secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)
to completely decode the Secret.
to learn how to completely decode the Secret.
-->
其输出应该包含 `mykey: bXlkYXRh`，`mydata` 的内容是被加密过的，
其输出应该包含 `mykey: bXlkYXRh`，其中 `mydata` 的内容使用 base64 进行加密，
请参阅[解密 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)
了解如何完全解码 Secret 内容。
<!--
## Ensure all Secrets are encrypted
### Ensure all relevant data are encrypted {#ensure-all-secrets-are-encrypted}
Since Secrets are encrypted on write, performing an update on a Secret will encrypt that content.
It's often not enough to make sure that new objects get encrypted: you also want that
encryption to apply to the objects that are already stored.
For this example, you have configured your cluster so that Secrets are encrypted on write.
Performing a replace operation for each Secret will encrypt that content at rest,
where the objects are unchanged.
You can make this change across all Secrets in your cluster:
-->
## 确保所有 Secret 都被加密 {#ensure-all-secrets-are-encrypted}
### 确保所有相关数据都被加密 {#ensure-all-secrets-are-encrypted}
由于 Secret 是在写入时被加密，因此对 Secret 执行更新也会加密该内容。
仅仅确保新对象被加密通常是不够的：你还希望对已经存储的对象进行加密。
例如，你已经配置了集群，使得 Secret 在写入时进行加密。
为每个 Secret 执行替换操作将加密那些对象保持不变的静态内容。
你可以在集群中的所有 Secret 上进行此项变更：
<!--
# Run this as an administrator that can read and write all Secrets
-->
```shell
# 以能够读写所有 Secret 的管理员身份运行此命令
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
<!--
The command above reads all Secrets and then updates them to apply server side encryption.
The command above reads all Secrets and then updates them with the same data, in order to
apply server side encryption.
-->
上面的命令读取所有 Secret，然后使用服务端加密来更新其内容。
上面的命令读取所有 Secret，然后使用相同的数据更新这些 Secret，以便应用服务端加密。
{{< note >}}
<!--
If an error occurs due to a conflicting write, retry the command.
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
It is safe to run that command more than once.
For larger clusters, you may wish to subdivide the Secrets by namespace,
or script an update.
-->
如果由于冲突写入而发生错误，请重试该命令。
多次运行此命令是安全的。
对于较大的集群，你可能希望通过命名空间或更新脚本来对 Secret 进行划分。
{{< /note >}}