[Shared Resources] Persist Read-Only Volume Mounts on Driver Restart

User Story

As an application developer
I want the Shared Resource CSI driver to preserve read-only volume mounts across driver restarts
So that I can reliably use SharedSecrets and SharedConfigMaps in read-only CSI volumes.

Acceptance Criteria

• Workloads/Pods can use SharedSecrets/SharedConfigMaps with read-only volumes.
• Read-only volume mounts can have their content updated after the driver pod is restarted on the node.
• SELinux labels for the pod volume are acceptable for storage/node/auth teams.
• Required SCCs needed to use the CSI volume type in a typical workload (Deployment) are documented.

QE Impact

QE will need to verify that a read-only SharedSecret/SharedConfigMap volume can have their content updated in a running workload after the CSI driver pods restart.

Docs Impact

Running documentation for the Shared Resource CSI driver should include instructions on which SCCs are needed to use the SharedResource CSI driver.

PX Impact

We eventually need PX material for the field, but this won't be in scope for the story.

Notes

A desired feature of the shared resource CSI driver is the ability to update the referenced Secret or ConfigMap, while the pod sees the volume as read-only.
The is possible if the user is required to provide the `readOnly: true` in the CSI volume spec AND the driver intentionally provides read-write volumes to cri-o/kubelet.

See "Solution 3" in https://docs.google.com/document/d/1uWSqaNtQ8uAkMUSDZxIKLay8GMVwebTT873Mk3r0tr8/edit#heading=h.jghf3od3f7ht

Open Questions:

1. Does our use of SELinux labels/labeling scheme open a potential security hole? No under the following conditions:
a. We provide read-write volumes to kubelet/cri-o AND
b. We require users to set "readOnly: true" in the CSI volume spec.
2. Is the issue with Security Context Constraints orthogonal to SELinux labels? More or less "yes"
3. Must this work with all SCCs? Can we require users to create a specialized SCC for this capability? Builds run with privileged SCC, so we aren't as concerned for tech preview. For GA we need to find an appropriate security solution in upstream Kubernetes.