K
Q

purpose of kubernetes accessModes in pv | pvc

3/1/2021

In kubernetes you can set volumes permissions at pod ,pv or pvc levels. You can define pv | pvc as read only but still can write to the mount point if readOnly attribute is set to false which is pretty confusing. I have read a lot of articles about this but still can't fully understand the purpose.

What I inderstand:

  • Permissions at pv level are for requesting available ressouces from the host file system with at least the same permissions defined in pv.
  • Permissions at pvc level are for requesting pv with at least the same permissions defined in pvc.
  • Permissions at pod level are for setting permissions to the mount point.

Please correct me if I'm wrong

-- Amine Bouzid
kubernetes

Similar Questions

GCP MySQL with private IP not reachable from GKE
Expose kubernetes logs to browser through websocket
Apache Spark on k8s: securing RPC communication between driver and executors is not working
Should we define VirtualService if it is just a plain proxy to Service?
How to expose kafka for external access after build kafka cluster on kubernetes?

1 Answer

3/1/2021

The PV's (and PVC's) access modes are used only for binding PVC (PV).

As you can see in this github discussion:

AccessModes as defined today, only describe node attach (not pod mount) semantics, and doesn't enforce anything.

Additionally you can find useful information in the PV AccessModes documentation:

A volume’s AccessModes are descriptors of the volume’s capabilities. They are not enforced constraints. The storage provider is responsible for runtime errors resulting from invalid use of the resource. For example, NFS offers ReadWriteOnce access mode. You must mark the claims as read-only if you want to use the volume’s ROX capability.

To enforce readOnly mode you can use:

Pod.spec.volumes.persistentVolumeClaim.readOnly - controls if volume is in readonly mode.

I think this answer may be of great help to you.

-- matt_j
Source: StackOverflow