Skip to content

Commit 237ebca

Browse files
authored
[zh-cn] localize blog: 2023-05-16-kmsv2-beta.md (#41107)
Signed-off-by: xin.li <[email protected]>
1 parent 8d4d81e commit 237ebca

File tree

1 file changed

+391
-0
lines changed

1 file changed

+391
-0
lines changed
Lines changed: 391 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,391 @@
1+
---
2+
layout: blog
3+
title: "Kubernetes 1.27: KMS V2 进入 Beta 阶段"
4+
date: 2023-05-16
5+
slug: kms-v2-moves-to-beta
6+
---
7+
8+
<!--
9+
layout: blog
10+
title: "Kubernetes 1.27: KMS V2 Moves to Beta"
11+
date: 2023-05-16
12+
slug: kms-v2-moves-to-beta
13+
-->
14+
15+
<!--
16+
**Authors:** Anish Ramasekar, Mo Khan, and Rita Zhang (Microsoft)
17+
-->
18+
**作者:** Anish Ramasekar, Mo Khan, and Rita Zhang (Microsoft)
19+
20+
**译者:** Xin Li (DaoCloud)
21+
22+
<!--
23+
With Kubernetes 1.27, we (SIG Auth) are moving Key Management Service (KMS) v2 API to beta.
24+
-->
25+
在 Kubernetes 1.27 中,我们(SIG Auth)将密钥管理服务(KMS)v2 API 带入 Beta 阶段。
26+
27+
<!--
28+
## What is KMS?
29+
One of the first things to consider when securing a Kubernetes cluster is encrypting etcd data at
30+
rest. KMS provides an interface for a provider to utilize a key stored in an external key service to
31+
perform this encryption.
32+
-->
33+
## KMS 是什么?
34+
35+
保护 Kubernetes 集群时首先要考虑的事情之一是加密静态的 etcd 数据。
36+
KMS 为供应商提供了一个接口,以便利用存储在外部密钥服务中的密钥来执行此加密。
37+
38+
<!--
39+
KMS v1 has been a feature of Kubernetes since version 1.10, and is currently in beta as of version
40+
v1.12. KMS v2 was introduced as alpha in v1.25.
41+
-->
42+
KMS v1 自 1.10 版以来一直是 Kubernetes 的一项功能特性,该特性从 v1.12
43+
版开始处于 Beta 阶段。KMS v2 在 v1.25 中作为 Alpha 特性引入。
44+
45+
{{% alert title="Note" color="primary" %}}
46+
<!--
47+
The KMS v2 API and implementation changed in incompatible
48+
ways in-between the alpha release in v1.25 and the beta release in v1.27. The design of KMS v2 has
49+
changed since [the previous blog post](https://kubernetes.io/blog/2022/09/09/kms-v2-improvements/)
50+
was written and it is not compatible with the design in this blog post. Attempting to upgrade from
51+
old versions with the alpha feature enabled will result in data loss.
52+
-->
53+
KMS v2 API 与实现在 v1.25 的 Alpha 版本和 v1.27 的 Beta 版本之间发生了一些不兼容的变化。
54+
[上一篇博文](https://kubernetes.io/blog/2022/09/09/kms-v2-improvements/)撰写以来,
55+
KMS v2 的设计发生了变化,与本博文中的设计不兼容。如果尝试从启用了 Alpha 特性的旧版本升级到
56+
Beta 版本,将会导致数据丢失。
57+
{{% /alert %}}
58+
59+
<!--
60+
## What’s new in `v2beta1`?
61+
The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is
62+
encrypted using a data encryption key (DEK). The DEKs are encrypted with a key encryption key (KEK)
63+
that is stored and managed in a remote KMS. With KMS v1, a new DEK is generated for each encryption.
64+
With KMS v2, a new DEK is only generated on server startup and when the KMS plugin informs the API
65+
server that a KEK rotation has occurred.
66+
-->
67+
## `v2beta1` 有什么新内容?
68+
69+
KMS 加密驱动使用信封加密方式来加密 etcd 中的数据,使用数据加密密钥(DEK)对数据进行加密。
70+
DEK 使用在远程 KMS 中存储和管理的密钥加密密钥(KEK)进行加密。
71+
使用 KMS v1,每次加密都会生成一个新的 DEK。
72+
使用 KMS v2,只有在服务器启动时且 KMS 插件通知 API 服务器发生 KEK 轮换时才会生成新的 DEK。
73+
74+
{{% alert title="警告" color="warning" %}}
75+
<!--
76+
If you are running virtual machine (VM) based nodes
77+
that leverage VM state store with this feature, you must not use KMS v2.
78+
79+
With KMS v2, the API server uses AES-GCM with a 12 byte nonce (8 byte atomic counter and 4 bytes
80+
random data) for encryption. The following issues could occur if the VM is saved and restored:
81+
-->
82+
如果你运行的是虚拟机(VM)节点,其中启用此特性的节点使用了 VM 的状态存储,
83+
则不得使用 KMS v2。
84+
85+
对于 KMS v2,API 服务器使用带有 12 字节随机数(8 字节原子计数器和 4 字节随机数据)的
86+
AES-GCM 进行加密。在保存和恢复虚拟机时,可能会出现以下问题:
87+
88+
<!--
89+
1. The counter value may be lost or corrupted if the VM is saved in an inconsistent state or
90+
restored improperly. This can lead to a situation where the same counter value is used twice,
91+
resulting in the same nonce being used for two different messages.
92+
2. If the VM is restored to a previous state, the counter value may be set back to its previous
93+
value, resulting in the same nonce being used again.
94+
-->
95+
1. 如果 VM 的保存状态不一致或其恢复不正确,计数器值可能会丢失或损坏。
96+
这可能会导致系统再次使用同一计数器值,进而在两个不同的消息中使用相同的随机数。
97+
2. 如果 VM 恢复到以前的状态,则计数器值可能会设置回其以前的值,
98+
导致再次使用相同的随机数。
99+
100+
<!--
101+
Although both of these cases are partially mitigated by the 4 byte random nonce, this can compromise
102+
the security of the encryption.
103+
-->
104+
虽然这两种情况都可以通过 4 字节随机数部分缓解,但这仍可能会危及加密的安全性。
105+
{{% /alert %}}
106+
107+
<!--
108+
### Sequence Diagram
109+
110+
#### Encrypt Request
111+
-->
112+
### 时序图
113+
114+
#### 加密请求
115+
116+
<!-- source
117+
```mermaid
118+
%%{init:{"theme":"neutral", "sequence": {"mirrorActors":true},
119+
"themeVariables": {
120+
"actorBkg":"royalblue",
121+
"actorTextColor":"white"
122+
}}}%%
123+
124+
sequenceDiagram
125+
participant user
126+
participant kube_api_server
127+
participant kms_plugin
128+
participant external_kms
129+
alt Generate DEK at startup
130+
Note over kube_api_server,external_kms: Refer to Generate Data Encryption Key (DEK) diagram for details
131+
end
132+
user->>kube_api_server: create/update resource that's to be encrypted
133+
kube_api_server->>kube_api_server: encrypt resource with DEK
134+
kube_api_server->>etcd: store encrypted object
135+
```
136+
-->
137+
138+
<!--
139+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-encryption.svg"
140+
alt="Sequence diagram for KMSv2 beta Encrypt" class="diagram-large" >}}
141+
-->
142+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-encryption.svg"
143+
alt="KMSv2 Beta 加密的序列图" class="diagram-large" >}}
144+
145+
<!--
146+
#### Decrypt Request
147+
-->
148+
#### 解密请求
149+
150+
<!-- source
151+
```mermaid
152+
%%{init:{"theme":"neutral", "sequence": {"mirrorActors":true},
153+
"themeVariables": {
154+
"actorBkg":"royalblue",
155+
"actorTextColor":"white"
156+
}}}%%
157+
158+
sequenceDiagram
159+
participant user
160+
participant kube_api_server
161+
participant kms_plugin
162+
participant external_kms
163+
participant etcd
164+
user->>kube_api_server: get/list resource that's encrypted
165+
kube_api_server->>etcd: get encrypted resource
166+
etcd->>kube_api_server: encrypted resource
167+
alt Encrypted DEK not in cache
168+
kube_api_server->>kms_plugin: decrypt request
169+
kms_plugin->>external_kms: decrypt DEK with remote KEK
170+
external_kms->>kms_plugin: decrypted DEK
171+
kms_plugin->>kube_api_server: return decrypted DEK
172+
kube_api_server->>kube_api_server: cache decrypted DEK
173+
end
174+
kube_api_server->>kube_api_server: decrypt resource with DEK
175+
kube_api_server->>user: return decrypted resource
176+
```
177+
-->
178+
179+
<!--
180+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-decryption.svg"
181+
alt="Sequence diagram for KMSv2 beta Decrypt" class="diagram-large" >}}
182+
-->
183+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-decryption.svg"
184+
alt="KMSv2 Beta 解密的序列图" class="diagram-large" >}}
185+
186+
<!--
187+
#### Status Request
188+
-->
189+
#### 状态请求
190+
191+
<!-- source
192+
```mermaid
193+
%%{init:{"theme":"neutral", "sequence": {"mirrorActors":true},
194+
"themeVariables": {
195+
"actorBkg":"royalblue",
196+
"actorTextColor":"white"
197+
}}}%%
198+
199+
sequenceDiagram
200+
participant kube_api_server
201+
participant kms_plugin
202+
participant external_kms
203+
alt Generate DEK at startup
204+
Note over kube_api_server,external_kms: Refer to Generate Data Encryption Key (DEK) diagram for details
205+
end
206+
loop every minute (or every 10s if error or unhealthy)
207+
kube_api_server->>kms_plugin: status request
208+
kms_plugin->>external_kms: validate remote KEK
209+
external_kms->>kms_plugin: KEK status
210+
kms_plugin->>kube_api_server: return status response <br/> {"healthz": "ok", key_id: "<remote KEK ID>", "version": "v2beta1"}
211+
alt KEK rotation detected (key_id changed), rotate DEK
212+
Note over kube_api_server,external_kms: Refer to Generate Data Encryption Key (DEK) diagram for details
213+
end
214+
end
215+
```
216+
-->
217+
218+
<!--
219+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-status.svg"
220+
alt="Sequence diagram for KMSv2 beta Status" class="diagram-large" >}}
221+
-->
222+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-status.svg"
223+
alt="KMSv2 Beta 状态的序列图" class="diagram-large" >}}
224+
225+
<!--
226+
#### Generate Data Encryption Key (DEK)
227+
-->
228+
#### 生成数据加密密钥(DKE)
229+
230+
<!-- source
231+
```mermaid
232+
%%{init:{"theme":"neutral", "sequence": {"mirrorActors":true},
233+
"themeVariables": {
234+
"actorBkg":"royalblue",
235+
"actorTextColor":"white"
236+
}}}%%
237+
238+
sequenceDiagram
239+
participant kube_api_server
240+
participant kms_plugin
241+
participant external_kms
242+
kube_api_server->>kube_api_server: generate DEK
243+
kube_api_server->>kms_plugin: encrypt request
244+
kms_plugin->>external_kms: encrypt DEK with remote KEK
245+
external_kms->>kms_plugin: encrypted DEK
246+
kms_plugin->>kube_api_server: return encrypt response <br/> {"ciphertext": "<encrypted DEK>", key_id: "<remote KEK ID>", "annotations": {}}
247+
```
248+
-->
249+
250+
<!--
251+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-generate-dek.svg"
252+
alt="Sequence diagram for KMSv2 beta Generate DEK" class="diagram-large" >}}
253+
-->
254+
{{< figure src="/images/blog/2023-05-16-kubernetes-1.27-kmsv2-beta/kubernetes-1.27-generate-dek.svg"
255+
alt="KMSv2 Beta 生成 DEK 的序列图" class="diagram-large" >}}
256+
257+
<!--
258+
### Performance Improvements
259+
With KMS v2, we have made significant improvements to the performance of the KMS encryption
260+
provider. In case of KMS v1, a new DEK is generated for every encryption. This means that for every
261+
write request, the API server makes a call to the KMS plugin to encrypt the DEK using the remote
262+
KEK. The API server also has to cache the DEKs to avoid making a call to the KMS plugin for every
263+
read request. When the API server restarts, it has to populate the cache by making a call to the KMS
264+
plugin for every DEK in the etcd store based on the cache size. This is a significant overhead for
265+
the API server. With KMS v2, the API server generates a DEK at startup and caches it. The API server
266+
also makes a call to the KMS plugin to encrypt the DEK using the remote KEK. This is a one-time call
267+
at startup and on KEK rotation. The API server then uses the cached DEK to encrypt the resources.
268+
This reduces the number of calls to the KMS plugin and improves the overall latency of the API
269+
server requests.
270+
-->
271+
### 性能改进
272+
273+
在 KMS v2 中,我们对 KMS 加密提供程序的性能进行了重大改进。对于 KMS v1,
274+
每次加密都会生成一个新的 DEK。这意味着对于每个写入请求,API 服务器都会调用
275+
KMS 插件以使用远程 KEK 加密 DEK。为避免每个读取请求都会调用 KMS 插件,
276+
API 服务器必须缓存 DEK。当 API 服务器重新启动时,
277+
它必须根据缓存大小为 etcd 存储中的每个 DEK 调用 KMS 插件来填充缓存。
278+
这对 API 服务器来说是一个很大的开销。使用 KMS v2,API 服务器在启动时生成一个 DEK 并将其缓存。
279+
API 服务器还调用 KMS 插件以使用远程 KEK 加密 DEK。这是启动时和 KEK 轮换时的一次性调用。
280+
在此之后,API 服务器使用缓存的 DEK 来加密资源。这样做减少了对 KMS 插件的调用次数,
281+
并改善了 API 服务器请求的整体延迟。
282+
283+
<!--
284+
We conducted a test that created 12k secrets and measured the time taken for the API server to
285+
encrypt the resources. The metric used was
286+
[`apiserver_storage_transformation_duration_seconds`](https://kubernetes.io/docs/reference/instrumentation/metrics/).
287+
For KMS v1, the test was run on a managed Kubernetes v1.25 cluster with 2 nodes. There was no
288+
additional load on the cluster during the test. For KMS v2, the test was run in the Kubernetes CI
289+
environment with the following [cluster
290+
configuration](https://github.com/kubernetes/kubernetes/blob/release-1.27/test/e2e/testing-manifests/auth/encrypt/kind.yaml).
291+
-->
292+
我们进行了一项创建 12,000 个 Secret 的测试,并检测了 API
293+
服务器加密资源所花费的时间。使用的指标是
294+
[`apiserver_storage_transformation_duration_seconds`](https://kubernetes.io/zh-cn/docs/reference/instrumentation/metrics/)
295+
对于 KMS v1,测试在具有 2 个节点的托管 Kubernetes v1.25 集群上运行。
296+
测试期间集群上没有额外的负载。对于 KMS v2,
297+
测试是在具有以下[集群配置](https://github.com/kubernetes/kubernetes/blob/release-1.27/test/e2e/testing-manifests/auth/encrypt/kind.yaml)
298+
Kubernetes CI 环境中运行的
299+
300+
<!--
301+
| KMS Provider | Time taken by 95 percentile |
302+
| ------------ | --------------------------- |
303+
| KMS v1 | 160ms |
304+
| KMS v2 | 80μs |
305+
306+
The results show that the KMS v2 encryption provider is three orders of magnitude faster than the
307+
KMS v1 encryption provider.
308+
-->
309+
| KMS 驱动 | 95 分位请求所用时间 |
310+
| ------------ | --------------------------- |
311+
| KMS v1 | 160ms |
312+
| KMS v2 | 80μs |
313+
314+
结果表明,KMS v2 加密驱动比 KMS v1 快三个数量级。
315+
316+
<!--
317+
## What's next?
318+
For Kubernetes v1.28, we expect the feature to stay in beta. In the coming releases we want to
319+
investigate:
320+
- Cryptographic changes to remove the limitation on VM state store.
321+
- Kubernetes REST API changes to enable a more robust story around key rotation.
322+
- Handling undecryptable resources. Refer to the
323+
[KEP](https://github.com/kubernetes/enhancements/pull/3927) for details.
324+
-->
325+
## 下一步计划
326+
327+
对于 Kubernetes v1.28,我们预计该功能仍处于测试阶段。在即将发布的版本中,我们将致力于:
328+
329+
- 修改加密程序以消除对 VM 状态存储的限制。
330+
- 针对密钥轮换,修改 Kubernetes REST API 以实现更强大的特性。
331+
- 处理无法解密的资源,更多细节参考:[KEP](https://github.com/kubernetes/enhancements/pull/3927)
332+
333+
<!--
334+
You can learn more about KMS v2 by reading [Using a KMS provider for data
335+
encryption](/docs/tasks/administer-cluster/kms-provider/). You can also follow along on the
336+
[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/3299-kms-v2-improvements/#readme)
337+
to track progress across the coming Kubernetes releases.
338+
-->
339+
你可以通过阅读[使用 KMS 驱动进行数据加密](/zh-cn/docs/tasks/administer-cluster/kms-provider/)
340+
还可以关注 [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/3299-kms-v2-improvements/#readme)
341+
来跟踪即将发布的 Kubernetes 版本进度。
342+
343+
<!--
344+
## Call to action
345+
346+
In this blog post, we have covered the improvements made to the KMS encryption provider in
347+
Kubernetes v1.27. We have also discussed the new KMS v2 API and how it works. We would love to hear
348+
your feedback on this feature. In particular, we would like feedback from Kubernetes KMS plugin
349+
implementors as they go through the process of building their integrations with this new API. Please
350+
reach out to us on the [#sig-auth-kms-dev](https://kubernetes.slack.com/archives/C03035EH4VB)
351+
channel on Kubernetes Slack.
352+
-->
353+
## 行动号召
354+
355+
在这篇博文中,我们介绍了 Kubernetes v1.27 中对 KMS 加密驱动所做的改进。
356+
我们还讨论了新的 KMS v2 API 及其工作原理。我们很想听听你对此功能的反馈,
357+
特别是,我们希望 Kubernetes KMS 插件实现者在构建与这个新 API 的集成过程中得到反馈。
358+
请通过 Kubernetes Slack 上的 [#sig-auth-kms-dev](https://kubernetes.slack.com/archives/C03035EH4VB)
359+
频道与我们联系。
360+
361+
<!--
362+
## How to get involved
363+
If you are interested in getting involved in the development of this feature, share feedback, or
364+
participate in any other ongoing SIG Auth projects, please reach out on the
365+
[#sig-auth](https://kubernetes.slack.com/archives/C0EN96KUY) channel on Kubernetes Slack.
366+
-->
367+
## 如何参与
368+
369+
如果你有兴趣参与此功能的开发、分享反馈或参与任何其他正在进行的 SIG Auth 项目,
370+
请联系 Kubernetes Slack 上的 [#sig-auth](https://kubernetes.slack.com/archives /C0EN96KUY) 频道。
371+
372+
<!--
373+
You are also welcome to join the bi-weekly [SIG Auth
374+
meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md#meetings), held
375+
every-other Wednesday.
376+
-->
377+
也欢迎你加入每两周举行一次的
378+
[SIG Auth 会议](https://github.com/kubernetes/community/blob/master/sig-auth/README.md#meetings)
379+
每隔一个星期三举行一次。
380+
381+
<!--
382+
## Acknowledgements
383+
This feature has been an effort driven by contributors from several different companies. We would
384+
like to extend a huge thank you to everyone that contributed their time and effort to help make this
385+
possible.
386+
-->
387+
## 致谢
388+
389+
此功能是由来自几家不同公司的贡献者推动的,我们非常感谢所有贡献时间和精力帮助实现这一目标的人。
390+
391+

0 commit comments

Comments
 (0)