I want to utilize data from a persistent volume as readOnly inside a container. What is the difference of setting the readOnly flag under the volumeMounts vs the deployment volumes.persistentVolumeClaim?

The results seems to be the same. Is one of the two redundant?

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: ${ORDERER_ORG_NAME}-delpoyment
  namespace: ${NS}
  labels:
    app: ${ORDERER_ORG_NAME}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ${ORDERER_ORG_NAME}
  template:
    metadata:
      labels:
        app: ${ORDERER_ORG_NAME}
    spec:
      initContainers:
        - name: prepare-tls-certs
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "wait-for-certs.sh"]
          volumeMounts:
            - name: fabric-volume
              mountPath: ${ORDERER_ORG_PATH}
              subPath: var/hyperledger/config/tls
              readOnly: true
      containers: # other containers
      volumes:
        - name: fabric-volume
          persistentVolumeClaim:
            readOnly: true
            claimName: fabric-pvc

CodePudding user response：

In your case, yes, the outcome is the same. But this functionality is not redundant, because the readOnly on a volume and readOnly on a mountPoint have different implications. For example,

1. readOnly: true on a volumeMount means that the ro mount option is set when mounting your endpoint. This is on the container level. You can read more about mount options here.
2. readOnly: true on a volume means the volume is readonly. Even if you don't mount it as readOnly, you cannot write to it. This is on a pod level and any container that will mount this volume will not have the ability to write. However, it doesn't have to be readOnly. You can set readOnly:false as well, where your volume will be writeable but the mounted filesystem can be readOnly. This way, other containers can mount this volume as readOnly: false and be able to write to it. This can be used, for instance, to ensure certain containers are not allowed to modify a volume, but others are.

To take it a level further "down the stack", you can have PersistentVolumes that can be shared across multiple pods (across multiple nodes). Here, the readOnly field plays a role in conjunction with the AccessMode of the PersistentVolume. You can have an AccessMode of WriteOnceReadMany meaning that 1 node can have pods attaching this volume for writing and many can read from it only. More than 1 node will not be able to have its pods write to this volume. You can read more about AccessModes of PersistentVolumes here.

In summary, the permissions are always ANDed together with the most restrictive permission generally up the stack. So, generally, an AccessMode will be more permissive, a Volume permission will be less permissive and the volumeMount permissions will be least permissive by design. That's the way you design access to your resources.