CSI 3.4 deployment to OpenShift 4.16.39 failed, causing PersistentVolumeClaims using the vsphere-csi-sc StorageClass to remain in a Pending state. CSI controller pods were rejected due to runAsUser violations, and no dynamic provisioning occurred. PVCs could not bind, resulting in storage downtime. Logs from failed controller pods showed:
“Error creating: pods ‘vsphere-csi-controller-
VMware vCenter Server
The default SCC policies in OpenShift did not permit UID 65532, which is used by the CSI controller container. As a result, pod creation failed due to security policy rejections. Without a custom SCC to allow this UID and associated capabilities, CSI components could not initialize or run.
A custom SecurityContextConstraints policy was created to allow UID 65532 and required privileges. This SCC included:
Policy YAML:
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: vsphere-csi-unified-scc
allowPrivilegedContainer: true
allowHostDirVolumePlugin: true # hostPath
allowHostNetwork: true
allowHostPorts: true
allowedCapabilities:
- SYS_ADMIN
runAsUser:
type: RunAsAny # allows UID 65532
seLinuxContext:
type: RunAsAny
fsGroup:
type: RunAsAny
supplementalGroups:
type: RunAsAny
volumes:
- "*" # allow all volumes, including hostPath
users:
- system:serviceaccount:vmware-system-csi:vsphere-csi-controller
- system:serviceaccount:vmware-system-csi:vsphere-csi-node
Once this SCC was applied, all CSI pods were able to start, and PVC provisioning resumed successfully. The cluster resumed dynamic provisioning through the vSphere CSI driver.