Kubernetes 1.24：防止未经授权的卷模式转换

Kubernetes v1.24 引入了一个新的 Alpha 级别特性，可防止未经授权的用户修改 Kubernetes 集群中基于现有 VolumeSnapshot 创建的 PersistentVolumeClaim 的卷模式。

问题所在

卷模式（Volume Mode）决定了一个卷是格式化为文件系统还是呈现为原始块设备。

用户可以利用自 Kubernetes v1.20 以来已稳定的 VolumeSnapshot 功能，从 Kubernetes 集群中已有的 VolumeSnapshot 创建一个 PersistentVolumeClaim（简称 PVC）。PVC 的 spec 中包含一个 dataSource 字段，可以指向一个已有的 VolumeSnapshot 实例。更多细节请访问从卷快照创建 PersistentVolumeClaim。

当利用上述功能时，没有逻辑来验证被快照的原始卷的模式是否与新创建的卷的模式相匹配。

这带来了一个安全漏洞，可能允许恶意用户利用主机操作系统中尚未发现的漏洞。

许多主流的存储备份供应商为了提高效率，在备份操作过程中会转换卷模式，这使得 Kubernetes 无法完全阻止该操作，并且在区分受信任用户和恶意用户方面带来了挑战。

防止未经授权的用户转换卷模式

在这种情况下，授权用户是指有权对集群级资源 VolumeSnapshotContents 执行 Update 或 Patch 操作的用户。
集群管理员应仅将这些权限授予受信任的用户或应用程序，例如备份供应商。

如果在 snapshot-controller、snapshot-validation-webhook 和 external-provisioner 中启用了该 Alpha 特性，那么未经授权的用户将不被允许在从 VolumeSnapshot 创建 PVC 时修改其卷模式。

要转换卷模式，授权用户必须执行以下操作：

1. 识别在给定命名空间中将用作新创建 PVC 的数据源的 VolumeSnapshot。
2. 识别与上述 VolumeSnapshot 绑定的 VolumeSnapshotContent。

kubectl get volumesnapshot -n <namespace>

3. 向 VolumeSnapshotContent 添加注解 snapshot.storage.kubernetes.io/allowVolumeModeChange。

4. 此注解可以由软件或授权用户手动添加。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。

如果 VolumeSnapshotContent 对象上存在上述第 4 步中显示的注解，Kubernetes 将不会阻止卷模式的转换。用户在尝试向任何 VolumeSnapshotContent 添加该注解之前应牢记这一点。

接下来

启用此特性并告诉我们你的想法！

我们希望此特性不会对现有工作流程造成干扰，同时能防止恶意用户利用其集群中的安全漏洞。

如有任何疑问或问题，请加入 Kubernetes on Slack 并在 #sig-storage 频道中创建话题。或者，在 CSI external-snapshotter 仓库中创建一个 issue。

• ←上一篇
• 下一篇→