Vault CSI Provider Pod Fails To Start -- Socket Bind Issue

User reports that the Vault CSI Provider pod still fails deployment due to its inability to bind to a unix socket - a requirement of the CSI design.

Similar CSI issues were worked here: #96 (closed)

User added these notes to help replicate te issues:

Couple notes: We aren't using Umbrella BB, we're sourcing the individual service helm charts. We are using kyverno but have heavily "written out" the policies and set some for warnings vs enforcement - we do have a bunch of warnings about Vault but nothing we don't expect at our currently maturity of development/deployment.`

None of the policies regarding running as root are enforcing, and none of them are popping up in the logs for Vault in our attempted deployments of the VCSIP.`

The User is planning to use the Vault Agent injector instead of the CSI injector.

We should probably still do something to fix this. Discovered that this image would require root privs in order to open up the unix domain socket. So, one fix would be to set the securityContext to root and add a kyverno exception for this container. e.g.

diff --git a/chart/values.yaml b/chart/values.yaml
index 4441a5d..e743cb7 100644
--- a/chart/values.yaml
+++ b/chart/values.yaml
@@ -1205,10 +1205,9 @@ csi:
     # security context for the pod template and container in the csi provider daemonSet
     securityContext: 
       pod: 
-        runAsNonRoot: true
-        runAsGroup: 1000
-        runAsUser: 100
-        fsGroup: 1000  
+        runAsGroup: 0
+        runAsUser: 0
+        fsGroup: 0  
 
   pod:
     # Extra annotations for the provider pods. This can either be YAML or a

Since using the csi-provider requires installing helm charts outside of Big Bang's supported packages, we could just leave this as-is too, and add a note that these values would need to be updated if csi.enabled is turned on.