|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: 'Kubernetes 1.24: Prevent unauthorised volume mode conversion' |
| 4 | +date: 2022-05-18 |
| 5 | +slug: prevent-unauthorised-volume-mode-conversion-alpha |
| 6 | +--- |
| 7 | + |
| 8 | +**Author:** Raunak Pradip Shah (Mirantis) |
| 9 | + |
| 10 | +Kubernetes v1.24 introduces a new alpha-level feature that prevents unauthorised users |
| 11 | +from modifying the volume mode of a [`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/) created from an |
| 12 | +existing [`VolumeSnapshot`](/docs/concepts/storage/volume-snapshots/) in the Kubernetes cluster. |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | +### The problem |
| 17 | + |
| 18 | +The [Volume Mode](/docs/concepts/storage/persistent-volumes/#volume-mode) determines whether a volume |
| 19 | +is formatted into a filesystem or presented as a raw block device. |
| 20 | + |
| 21 | +Users can leverage the `VolumeSnapshot` feature, which has been stable since Kubernetes v1.20, |
| 22 | +to create a `PersistentVolumeClaim` (shortened as PVC) from an existing `VolumeSnapshot` in |
| 23 | +the Kubernetes cluster. The PVC spec includes a `dataSource` field, which can point to an |
| 24 | +existing `VolumeSnapshot` instance. |
| 25 | +Visit [Create a PersistentVolumeClaim from a Volume Snapshot](/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot) for more details. |
| 26 | + |
| 27 | +When leveraging the above capability, there is no logic that validates whether the mode of the |
| 28 | +original volume, whose snapshot was taken, matches the mode of the newly created volume. |
| 29 | + |
| 30 | +This presents a security gap that allows malicious users to potentially exploit an |
| 31 | +as-yet-unknown vulnerability in the host operating system. |
| 32 | + |
| 33 | +Many popular storage backup vendors convert the volume mode during the course of a |
| 34 | +backup operation, for efficiency purposes, which prevents Kubernetes from blocking |
| 35 | +the operation completely and presents a challenge in distinguishing trusted |
| 36 | +users from malicious ones. |
| 37 | + |
| 38 | +### Preventing unauthorised users from converting the volume mode |
| 39 | + |
| 40 | +In this context, an authorised user is one who has access rights to perform `Update` |
| 41 | +or `Patch` operations on `VolumeSnapshotContents`, which is a cluster-level resource. |
| 42 | +It is upto the cluster administrator to provide these rights only to trusted users |
| 43 | +or applications, like backup vendors. |
| 44 | + |
| 45 | +If the alpha feature is [enabled](https://kubernetes-csi.github.io/docs/) in |
| 46 | +`snapshot-controller`, `snapshot-validation-webhook` and `external-provisioner`, |
| 47 | +then unauthorised users will not be allowed to modify the volume mode of a PVC |
| 48 | +when it is being created from a `VolumeSnapshot`. |
| 49 | + |
| 50 | +To convert the volume mode, an authorised user must do the following: |
| 51 | + |
| 52 | +1. Identify the `VolumeSnapshot` that is to be used as the data source for a newly |
| 53 | +created PVC in the given namespace. |
| 54 | +2. Identify the `VolumeSnapshotContent` bound to the above `VolumeSnapshot`. |
| 55 | + |
| 56 | +``` |
| 57 | + kubectl get volumesnapshot -n <namespace> |
| 58 | +``` |
| 59 | + |
| 60 | +3. Add the annotation [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange) |
| 61 | +to the `VolumeSnapshotContent`. |
| 62 | + |
| 63 | +4. This annotation can be added either via software or manually by the authorised |
| 64 | +user. The `VolumeSnapshotContent` annotation must look like following manifest fragment: |
| 65 | + |
| 66 | +```yaml |
| 67 | + kind: VolumeSnapshotContent |
| 68 | + metadata: |
| 69 | + annotations: |
| 70 | + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" |
| 71 | + ... |
| 72 | +``` |
| 73 | + |
| 74 | +**Note**: For pre-provisioned `VolumeSnapshotContents`, you must take an extra |
| 75 | +step of setting `spec.sourceVolumeMode` field to either `Filesystem` or `Block`, |
| 76 | +depending on the mode of the volume from which this snapshot was taken. |
| 77 | + |
| 78 | +An example is shown below: |
| 79 | + |
| 80 | +```yaml |
| 81 | + apiVersion: snapshot.storage.k8s.io/v1 |
| 82 | + kind: VolumeSnapshotContent |
| 83 | + metadata: |
| 84 | + annotations: |
| 85 | + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" |
| 86 | + name: new-snapshot-content-test |
| 87 | + spec: |
| 88 | + deletionPolicy: Delete |
| 89 | + driver: hostpath.csi.k8s.io |
| 90 | + source: |
| 91 | + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 |
| 92 | + sourceVolumeMode: Filesystem |
| 93 | + volumeSnapshotRef: |
| 94 | + name: new-snapshot-test |
| 95 | + namespace: default |
| 96 | +``` |
| 97 | +
|
| 98 | +Repeat steps 1 to 3 for all `VolumeSnapshotContents` whose volume mode needs to be |
| 99 | +converted during a backup or restore operation. |
| 100 | + |
| 101 | +If the annotation shown in step 4 above is present on a `VolumeSnapshotContent` |
| 102 | +object, Kubernetes will not prevent the volume mode from being converted. |
| 103 | +Users should keep this in mind before they attempt to add the annotation |
| 104 | +to any `VolumeSnapshotContent`. |
| 105 | + |
| 106 | + |
| 107 | +### What's next |
| 108 | + |
| 109 | +[Enable this feature](https://kubernetes-csi.github.io/docs/) and let us know |
| 110 | +what you think! |
| 111 | + |
| 112 | +We hope this feature causes no disruption to existing workflows while preventing |
| 113 | +malicious users from exploiting security vulnerabilities in their clusters. |
| 114 | + |
| 115 | +For any issues, create a thread in the #sig-storage slack channel or an issue |
| 116 | +in the CSI external-snapshotter [repository](https://github.com/kubernetes-csi/external-snapshotter). |
0 commit comments