vault-csi-provider
vault-csi-provider copied to clipboard
How to Run Vault CSI Provider as a Non-Root User
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:
- 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.
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!