Skip to content

Commit 23b6380

Browse files
authored
Merge pull request #32419 from RaunakShah/3151-placeholder
Add unauthorised volume mode conversion blog article
2 parents 994555c + c7b91e9 commit 23b6380

File tree

1 file changed

+116
-0
lines changed

1 file changed

+116
-0
lines changed
Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
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

Comments
 (0)