<p>I want to utilize data from a persistent volume as <code>readOnly</code> inside a container.
What is the difference of setting the <code>readOnly</code> flag under the <code>volumeMounts</code> vs the deployment <code>volumes.persistentVolumeClaim</code>?</p>
<p>The results seems to be the same. Is one of the two redundant?</p>
<pre class="lang-yaml prettyprint-override"><code>---
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: [&quot;/bin/sh&quot;, &quot;wait-for-certs.sh&quot;]
          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
</code></pre>

Gr3at
<p>In your case, yes, the outcome is the same. But this functionality is not redundant, because the <code>readOnly</code> on a volume and <code>readOnly</code> on a <code>mountPoint</code> have different implications. For example,</p>
<ol>
<li><code>readOnly: true</code> on a <code>volumeMount</code> means that the <code>ro</code> mount option is set when mounting your endpoint. This is on the <code>container level</code>. You can read more about <code>mount options</code> <a href="https://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-INDEPENDENT_MOUNT_OPTIONS" rel="nofollow noreferrer">here</a>.</li>
<li><code>readOnly: true</code> on a volume means the <em><strong>volume</strong></em> is readonly. Even if you don't mount it as <code>readOnly</code>, 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 <em><strong>have to be</strong></em> <code>readOnly</code>. You can set <code>readOnly:false</code> as well, where your <code>volume</code> will be <code>writeable</code> but the mounted <code>filesystem</code> can be <code>readOnly</code>. This way, other containers can mount this volume as <code>readOnly: false</code> 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.</li>
</ol>
<p>To take it a level further &quot;down the stack&quot;, you can have <code>PersistentVolumes</code> that can be shared across multiple pods (across multiple nodes). Here, the <code>readOnly</code> field plays a role in conjunction with the <code>AccessMode</code> of the <code>PersistentVolume</code>. You can have an <code>AccessMode</code> of <code>WriteOnceReadMany</code> meaning that 1 <code>node</code> can have pods attaching this volume for <code>writing</code> and many can <code>read</code> from it only. More than 1 <code>node</code> will not be able to have its pods write to this volume. You can read more about <code>AccessModes</code> of <code>PersistentVolumes</code> <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">here</a>.</p>
<p>In summary, the permissions are always <code>AND</code>ed together with the most restrictive permission generally <code>up the stack</code>. So, generally, an <code>AccessMode</code> will be more permissive, a <code>Volume</code> permission will be less permissive and the <code>volumeMount</code> permissions will be least permissive by design. That's the way you design access to your resources.</p>
