Harden CSI provider DaemonSet security context

[dc-tec]

The OpenBao CSI provider deployment manifest currently does not set common hardening options on the DaemonSet/container, i.e. runAsNonRoot, allowPrivilegeEscalation: false, dropped capabilities, seccompProfile: RuntimeDefault, and readOnlyRootFilesystem: true.

We should check if there is a specific compatibility reason for the current defaults, particularly around write access to the provider socket hostPath and otherwise harden the manifest by default.

[dc-tec]

After doing a quick test, the main compatibility risk I noticed is with setting runAsNonRoot: true. With the current hostPath socket directory ownership, the provider cannot bind /provider/openbao.sock and fails with permission denied.

To support running as non-root, we would need to change how the hostPath directory is created/owned or add a separate ownership-prep step. After removing runAsNonRoot and keeping the other hardening settings, the DaemonSet was able to start successfully and create the socket

    spec:
      serviceAccountName: openbao-csi-provider
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      tolerations:
      containers:
        - name: provider-openbao-installer
          image: openbao/openbao-csi-provider:1.4.0
          imagePullPolicy: Always
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

[pree]

As mentioned in the PR inside the helm chart we are setting runAsNonroot: true to the container and it seems to run there.
IMHO we should provide the same hardening inside the deployment manifest as we do inside the helm chart.

Can you check why it's working in the helm-chart and not the deployment manifest?