本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已不再准确。
Kubernetes 1.24: 防止未经授权的卷模式转换
Kubernetes v1.24 引入了一项新的 Alpha 阶段特性,该特性可防止未经授权的用户修改在 Kubernetes 集群中从现有 VolumeSnapshot
创建的 PersistentVolumeClaim
的卷模式(volume mode)。
问题
卷模式 (Volume Mode) 决定卷是格式化为文件系统还是作为裸块设备呈现。
用户可以利用自 Kubernetes v1.20 起已稳定的 VolumeSnapshot
特性,从 Kubernetes 集群中的现有 VolumeSnapshot
创建 PersistentVolumeClaim
(简称 PVC)。PVC 的规约中包含一个 dataSource
字段,该字段可以指向一个现有的 VolumeSnapshot
实例。有关更多详细信息,请访问从 Volume Snapshot 创建 PersistentVolumeClaim。
利用上述功能时,没有任何逻辑验证原始卷(已创建快照)的模式是否与新创建卷的模式匹配。
这带来了安全漏洞,可能允许恶意用户利用主机操作系统中尚未知的漏洞。
许多流行的存储备份供应商为了效率,在备份过程中会转换卷模式,这阻止了 Kubernetes 完全阻止该操作,并在区分可信用户和恶意用户方面带来了挑战。
阻止未经授权的用户转换卷模式
在此上下文中,授权用户是指拥有对 VolumeSnapshotContents
(这是一个集群级资源)执行 Update
或 Patch
操作访问权限的用户。
集群管理员负责仅向可信用户或应用程序(如备份供应商)授予这些权限。
如果在 snapshot-controller
、snapshot-validation-webhook
和 external-provisioner
中启用了 Alpha 功能,则在从 VolumeSnapshot
创建 PVC 时,未经授权的用户将无法修改 PVC 的卷模式。
要转换卷模式,授权用户必须执行以下操作:
- 识别要在给定命名空间中用作新创建的 PVC 的数据源的
VolumeSnapshot
。 - 识别绑定到上述
VolumeSnapshot
的VolumeSnapshotContent
。
kubectl get volumesnapshot -n <namespace>
向
VolumeSnapshotContent
添加注解snapshot.storage.kubernetes.io/allowVolumeModeChange
。该注解可以通过软件或由授权用户手动添加。
VolumeSnapshotContent
注解必须如下所示:
kind: VolumeSnapshotContent
metadata:
annotations:
- snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
...
注意:对于预配置的 VolumeSnapshotContents
,您必须执行额外一步,将 spec.sourceVolumeMode
字段设置为 Filesystem
或 Block
,具体取决于从中获取快照的卷的模式。
示例如下所示:
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
annotations:
- snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
name: new-snapshot-content-test
spec:
deletionPolicy: Delete
driver: hostpath.csi.k8s.io
source:
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
sourceVolumeMode: Filesystem
volumeSnapshotRef:
name: new-snapshot-test
namespace: default
对所有需要在备份或恢复操作期间转换卷模式的 VolumeSnapshotContents
重复步骤 1 到 3。
如果上述步骤 4 中所示的注解存在于 VolumeSnapshotContent
对象上,Kubernetes 将不会阻止卷模式被转换。用户在尝试向任何 VolumeSnapshotContent
添加注解之前应牢记这一点。
下一步是什么
启用此功能,并告诉我们您的想法!
我们希望此功能不会对现有工作流造成中断,同时防止恶意用户利用其集群中的安全漏洞。
如有任何疑问或问题,请加入 Kubernetes 的 Slack 频道,并在 #sig-storage 频道中创建讨论串。或者,在 CSI external-snapshotter 仓库中创建议题。