How to make a volume read-only?

[derselbst]

Suppose the following use-case: A Kubernetes-user creates a Weka FileSystem (either dynamically via PVC or statically). The user populates the volume with some data and later wants to share that volume with other users. But before sharing it, the volume should be marked read-only to prevent modification to the data. How to achieve this?

Options we have considered:

1. Changing the accessMode of the PV and the PVC to ReadOnlyMany does not seem to prevent a pod from writing data into the mounted weka filesystem. The wekafs is mounted rw anyhow, and files can be created, changed, deleted.
2. Changing the .spec.csi.readOnly to true in the PV is forbidden, because the spec is immutable.
3. Setting read-only mounts and volumes in Pod.spec.containers.volumeMounts[x].readOnly and Pod.spec.volumes.persistentVolumeClaim.readOnly resp. might work, but doesn't prevent a user from accidentally not setting it and therefore modifying data.
4. Using a Weka-user with "Read-Only" user role is not supported, because as per documentation at least an OrgaAdmin is required.
5. One could recursively go through the filesystem and mark every single file and directory read-only. Given that we're dealing with several 100000 files, this would take awful long and is no guarantee that a file isn't deleted accidentally by a root-user in a Kubernetes pod.
6. The Weka web UI doesn't seem to provide an option for marking a filesystem read-only.

Is there any other option to prevent modifications to an entire Weka filesystem?

[sergeyberezansky]

Hello, I will try to answer your questions and please ask for more clarifications if needed.

1. With regard to Changing the accessMode of the PV and the PVC to ReadOnlyMany: this functionality is not enforced by Kubernetes on data plane, but only used for scheduling pods. So for example if a PVC mode is set to ReadOnlyMany, K8s will allow attachment of the volume to multiple pods that require read-only access, but will not allow attaching to a pod that requires write access. Unfortunately, the accessMode is not passed to CSI in the NodePublishVolume request hence we cannot enforce it.

2. Indeed, spec of volume / storageClass is immutable

3. This is the recommended way to enforce readOnly access to PVC

4. Weka-user "read-only" does not actually enforce read-only access to filesystem, but rather to the system API.

5. Definitely, this solution, while feasible, is not scalable and cannot be simply automated. I will answer in more details below

6. Weka allows creation of a read-only / writable snapshot of a filesystem. However, since CSI plugin relies on the filesystem to preserve the provisioned volumes metadata, it must have a read-write access to the filesystem anyway.

I would suggest you the following possible solutions:

1. you could consider using a pod with root privileges to create data on the volume, while subsequently the other pods would not have root privileges and run under a different user ID.
2. you could create a new volume by cloning the existing volume (different point-in-time taken with each clone), or by provisioning a CSI snapshot and then provisioning a new volume from that snapshot (same point-in-time will be used for all subsequently provisioned volumes) as a separate PVC.
   Although in such case the volume still would not be read-only, the modifications would be local for the current replica only and will not affect the original data.
   Moreover, assuming no changes are actually done on this volume, it will consume almost no capacity on the storage, as it will basically map to Weka writable snapshot of an existing filesystem.*

• if the same filesystem is used for both this particular volume and other volumes, taking a snapshot of the filesystem will actually consume capacity, since modification of contents of anyone of the volumes will effectively increase the snapshot size. However, this statement is only correct for directory-backed volumes since only they are effectively sharing the same filesystem. Hence, it is recommended though to separate the volume to a different filesystem if using directory backing in such case.

Please refer to https://github.com/weka/csi-wekafs/blob/main/docs/usage.md#choosing-the-right-volume-type-for-your-workload for additional information regarding different types of volume backings

[derselbst]

Alright then, we'll pursue this as a mixture of option 3. and snapshotting the original volume. Will let you know if there are any issues coming up. Thanks again!

[sergeyberezansky]

@derselbst, I hope I have answered your quesion. Please feel free to ask for additional clarifications or let me know whether it was helpful

[derselbst]

Many thanks for your quick and detailed reply! (Sry, for not having made this a discussion in the first place, was too focussed on the problem)