Skip to content

Commit e652213

Browse files
authored
Merge pull request #46129 from my-git9/pt-14503
[zh-cn]Locatlization blog:2024-02-21-prevent-unauthorized-volume-mode-conversion-ga.md
2 parents 7b046b8 + 15f68d0 commit e652213

File tree

1 file changed

+196
-0
lines changed

1 file changed

+196
-0
lines changed
Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
---
2+
layout: blog
3+
title: "Kubernetes 1.30:防止未经授权的卷模式转换进阶到 GA"
4+
date: 2024-04-30
5+
slug: prevent-unauthorized-volume-mode-conversion-ga
6+
---
7+
<!--
8+
layout: blog
9+
title: "Kubernetes 1.30: Preventing unauthorized volume mode conversion moves to GA"
10+
date: 2024-04-30
11+
slug: prevent-unauthorized-volume-mode-conversion-ga
12+
author: >
13+
Raunak Pradip Shah (Mirantis)
14+
-->
15+
16+
**作者:** Raunak Pradip Shah (Mirantis)
17+
18+
**译者:** Xin Li (DaoCloud)
19+
20+
<!--
21+
With the release of Kubernetes 1.30, the feature to prevent the modification of the volume mode
22+
of a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/) that was created from
23+
an existing VolumeSnapshot in a Kubernetes cluster, has moved to GA!
24+
-->
25+
随着 Kubernetes 1.30 的发布,防止修改从 Kubernetes 集群中现有
26+
VolumeSnapshot 创建的 [PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/)
27+
的卷模式的特性已被升级至 GA!
28+
29+
<!--
30+
## The problem
31+
32+
The [Volume Mode](/docs/concepts/storage/persistent-volumes/#volume-mode) of a PersistentVolumeClaim
33+
refers to whether the underlying volume on the storage device is formatted into a filesystem or
34+
presented as a raw block device to the Pod that uses it.
35+
36+
Users can leverage the VolumeSnapshot feature, which has been stable since Kubernetes v1.20,
37+
to create a PersistentVolumeClaim (shortened as PVC) from an existing VolumeSnapshot in
38+
the Kubernetes cluster. The PVC spec includes a dataSource field, which can point to an
39+
existing VolumeSnapshot instance.
40+
Visit [Create a PersistentVolumeClaim from a Volume Snapshot](/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot)
41+
for more details on how to create a PVC from an existing VolumeSnapshot in a Kubernetes cluster.
42+
-->
43+
## 问题
44+
45+
PersistentVolumeClaim 的[卷模式](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-mode)
46+
是指存储设备上的底层卷是被格式化为某文件系统还是作为原始块设备呈现给使用它的 Pod。
47+
48+
用户可以利用自 Kubernetes v1.20 以来一直稳定的 VolumeSnapshot 特性,基于
49+
Kubernetes 集群中现有的 VolumeSnapshot 创建 PersistentVolumeClaim(简称 PVC)。
50+
PVC 规约中包括一个 `dataSource` 字段,它可以指向现有的 VolumeSnapshot 实例。
51+
有关如何基于 Kubernetes 集群中现有 VolumeSnapshot 创建 PVC 的更多详细信息,
52+
请访问[使用卷快照创建 PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot)
53+
54+
<!--
55+
When leveraging the above capability, there is no logic that validates whether the mode of the
56+
original volume, whose snapshot was taken, matches the mode of the newly created volume.
57+
58+
This presents a security gap that allows malicious users to potentially exploit an
59+
as-yet-unknown vulnerability in the host operating system.
60+
61+
There is a valid use case to allow some users to perform such conversions. Typically, storage backup
62+
vendors convert the volume mode during the course of a backup operation, to retrieve changed blocks
63+
for greater efficiency of operations. This prevents Kubernetes from blocking the operation completely
64+
and presents a challenge in distinguishing trusted users from malicious ones.
65+
-->
66+
当利用上述特性时,没有逻辑来验证制作快照的原始卷的模式是否与新创建的卷的模式匹配。
67+
68+
这带来了一个安全漏洞,允许恶意用户潜在地利用主机操作系统中未知的漏洞。
69+
70+
有一个合法的场景允许某些用户执行此类转换。
71+
通常,存储备份供应商会在备份操作过程中转换卷模式,通过检索已被更改的块来提高操作效率。
72+
这使得 Kubernetes 无法完全阻止此类操作,但给区分可信用户和恶意用户带来了挑战。
73+
74+
<!--
75+
## Preventing unauthorized users from converting the volume mode
76+
77+
In this context, an authorized user is one who has access rights to perform **update**
78+
or **patch** operations on VolumeSnapshotContents, which is a cluster-level resource.
79+
It is up to the cluster administrator to provide these rights only to trusted users
80+
or applications, like backup vendors.
81+
Users apart from such authorized ones will never be allowed to modify the volume mode
82+
of a PVC when it is being created from a VolumeSnapshot.
83+
-->
84+
## 防止未经授权的用户转换卷模式
85+
86+
在此上下文中,授权用户是有权对 VolumeSnapshotContents(集群级资源)执行
87+
**update****patch** 操作的用户。
88+
集群管理员应仅向受信任的用户或应用程序(例如备份供应商)赋予这些权限。
89+
当从 VolumeSnapshot 创建 PVC 时,除了此类授权用户之外的用户将永远不会被允许修改 PVC 的卷模式。
90+
91+
<!--
92+
To convert the volume mode, an authorized user must do the following:
93+
94+
1. Identify the VolumeSnapshot that is to be used as the data source for a newly
95+
created PVC in the given namespace.
96+
2. Identify the VolumeSnapshotContent bound to the above VolumeSnapshot.
97+
-->
98+
要转换卷模式,授权用户必须执行以下操作:
99+
100+
1. 标识要用作给定命名空间中新创建的 PVC 的数据源的 VolumeSnapshot。
101+
2. 识别与上述 VolumeSnapshot 绑定的 VolumeSnapshotContent。
102+
103+
```shell
104+
kubectl describe volumesnapshot -n <namespace> <name>
105+
```
106+
107+
<!--
108+
3. Add the annotation [`snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"`](/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange)
109+
to the above VolumeSnapshotContent. The VolumeSnapshotContent annotations must include one similar to the following manifest fragment:
110+
-->
111+
3. 在 VolumeSnapshotContent 上添加 [`snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"`](/zh-cn/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange)
112+
注解,VolumeSnapshotContent 注解必须包含类似于以下清单片段:
113+
114+
```yaml
115+
kind: VolumeSnapshotContent
116+
metadata:
117+
annotations:
118+
- snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
119+
...
120+
```
121+
122+
<!--
123+
**Note**: For pre-provisioned VolumeSnapshotContents, you must take an extra
124+
step of setting `spec.sourceVolumeMode` field to either `Filesystem` or `Block`,
125+
depending on the mode of the volume from which this snapshot was taken.
126+
127+
An example is shown below:
128+
-->
129+
**注意**:对于预配置的 VolumeSnapshotContents,你必须执行额外的步骤,将
130+
`spec.sourceVolumeMode` 字段设置为 `Filesystem``Block`
131+
具体取决于用来制作此快照的卷的模式。
132+
133+
一个例子如下所示:
134+
135+
```yaml
136+
apiVersion: snapshot.storage.k8s.io/v1
137+
kind: VolumeSnapshotContent
138+
metadata:
139+
annotations:
140+
- snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
141+
name: <volume-snapshot-content-name>
142+
spec:
143+
deletionPolicy: Delete
144+
driver: hostpath.csi.k8s.io
145+
source:
146+
snapshotHandle: <snapshot-handle>
147+
sourceVolumeMode: Filesystem
148+
volumeSnapshotRef:
149+
name: <volume-snapshot-name>
150+
namespace: <namespace>
151+
```
152+
153+
<!--
154+
Repeat steps 1 to 3 for all VolumeSnapshotContents whose volume mode needs to be
155+
converted during a backup or restore operation. This can be done either via software
156+
with credentials of an authorized user or manually by the authorized user(s).
157+
158+
If the annotation shown above is present on a VolumeSnapshotContent object,
159+
Kubernetes will not prevent the volume mode from being converted.
160+
Users should keep this in mind before they attempt to add the annotation
161+
to any VolumeSnapshotContent.
162+
-->
163+
对备份或恢复操作期间需要转换卷模式的所有 VolumeSnapshotContent 重复步骤 1 至 3。
164+
这可以通过具有授权用户凭据的软件来完成,也可以由授权用户手动完成。
165+
166+
如果 VolumeSnapshotContent 对象上存在上面显示的注解,Kubernetes 将不会阻止卷模式转换。
167+
用户在尝试将注解添加到任何 VolumeSnapshotContent 之前应记住这一点。
168+
169+
<!--
170+
## Action required
171+
172+
The `prevent-volume-mode-conversion` feature flag is enabled by default in the
173+
external-provisioner `v4.0.0` and external-snapshotter `v7.0.0`. Volume mode change
174+
will be rejected when creating a PVC from a VolumeSnapshot unless the steps
175+
described above have been performed.
176+
-->
177+
## 需要采取的行动
178+
179+
默认情况下,在 external-provisioner `v4.0.0` 和 external-snapshotter `v7.0.0`
180+
中启用 `prevent-volume-mode-conversion` 特性标志。
181+
基于 VolumeSnapshot 来创建 PVC 时,卷模式更改将被拒绝,除非已执行上述步骤。
182+
183+
<!--
184+
## What's next
185+
186+
To determine which CSI external sidecar versions support this feature, please head
187+
over to the [CSI docs page](https://kubernetes-csi.github.io/docs/).
188+
For any queries or issues, join [Kubernetes on Slack](https://slack.k8s.io/) and
189+
create a thread in the #csi or #sig-storage channel. Alternately, create an issue in the
190+
CSI external-snapshotter [repository](https://github.com/kubernetes-csi/external-snapshotter).
191+
-->
192+
## 接下来
193+
194+
要确定哪些 CSI 外部 sidecar 版本支持此功能,请前往 [CSI 文档页面](https://kubernetes-csi.github.io/docs/)。
195+
对于任何疑问或问题,请加入 [Slack 上的 Kubernetes](https://slack.k8s.io/) 并在 #csi 或 #sig-storage 频道中发起讨论。
196+
或者,在 CSI 外部快照[仓库](https://github.com/kubernetes-csi/external-snapshotter)中登记问题。

0 commit comments

Comments
 (0)