vault-csi-provider icon indicating copy to clipboard operation
vault-csi-provider copied to clipboard

How to Run Vault CSI Provider as a Non-Root User

Open SanduDS opened this issue 1 year ago • 1 comments
trafficstars

I am trying to deploy the Vault CSI provider in my Kubernetes cluster and want to ensure that it runs as a non-root user. I have configured the securityContext in HCP vault helm configuration values file, but I am encountering issues with permissions.

Here is the relevant excerpt from my values.yaml file.

csi:
   enabled: true
   agent:
      enabled: false
   image:
      repository: "hashicorp/vault-csi-provider" 
      tag: "1.4.2"
      pullPolicy: IfNotPresent
   daemonSet:
      securityContext:
         pod:
            runAsNonRoot: true
            runAsUser: 405 # on guest user UID
            fsGroup: 100 # on guest user GID
         container:
            seccompProfile:
               type: RuntimeDefault
               runAsUser: 405
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
               drop:
                  - NET_RAW
                  - ALL

Issues Encountered:

  1. When I set runAsNonRoot: true, the container fails to start with the error: Error running provider: err="failed to listen on unix socket at /provider/vault.sock: listen unix /provider/vault.sock: bind: permission denied"

Request:

Could you please provide guidance or an example configuration on how to properly run the Vault CSI provider as a non-root user? Any help would be greatly appreciated.

SanduDS avatar Jul 31 '24 09:07 SanduDS

For this error, you should check the permissions on the /etc/kubernetes/secrets-store-csi-providers directory on your host machine (your node). If it has root permissions, that’s the source of the problem—the directory must have the same permissions as your pod.

Additionally, I personally encountered a permission issue with the agent as well, with the error:

Error running provider: err="failed to listen on unix socket at /tmp/vault.sock: listen unix /tmp/vault.sock: bind: read-only file system"

I solved this by mounting a volume on the CSI provider as follows (to override default /tmp mount that is in read-only mode because of readOnlyRootFilesystem = true):

extraVolumes:
  - name: tmp-agent
    emptyDir: {}

and on the /tmp path using the csiProvider.agent.extraVolumeMounts option like this:

extraVolumeMounts:
  - name: tmp-agent
    mountPath: /tmp

I’m not sure if it’s normal to have to perform these adjustments or if my solutions follow best practices. If anyone from the Vault development team has the proper answer on how to resolve this issue correctly, we’d appreciate it!

bilouw avatar Feb 21 '25 21:02 bilouw