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。

• ←上一篇
• 下一篇→