k8s Deployment set readOnly in volumes vs volumeMounts - kubernetes

Question

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

Answer 1

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,
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.
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.