HashiCorp Vault Provider for Secrets Store CSI Driver

⚠️ Please note: We take Vault's security and our users' trust very seriously. If you believe you have found a security issue in Vault CSI Provider, please responsibly disclose by contacting us at security@hashicorp.com.

HashiCorp Vault provider for the Secrets Store CSI driver allows you to get secrets stored in Vault and use the Secrets Store CSI driver interface to mount them into Kubernetes pods.

Installation

Prerequisites

• Supported Kubernetes version, see the documentation (runs on Linux nodes only)
• Secrets store CSI driver installed

Using helm

The recommended installation method is via helm 3:

helm repo add hashicorp https://helm.releases.hashicorp.com
# Just installs Vault CSI provider. Adjust `server.enabled` and `injector.enabled`
# if you also want helm to install Vault and the Vault Agent injector.
helm install vault hashicorp/vault \
  --set "server.enabled=false" \
  --set "injector.enabled=false" \
  --set "csi.enabled=true"

Using yaml

You can also install using the deployment config in the deployment folder:

kubectl apply -f deployment/vault-csi-provider.yaml

Usage

See the learn tutorial and documentation pages for full details of deploying, configuring and using Vault CSI provider. The integration tests in test/bats/provider.bats also provide a good set of fully worked and tested examples to build on.

Troubleshooting

To troubleshoot issues with Vault CSI provider, look at logs from the Vault CSI provider pod running on the same node as your application pod:

kubectl get pods -o wide
# find the Vault CSI provider pod running on the same node as your application pod

kubectl logs vault-csi-provider-7x44t

Warning The -debug=true flag has been deprecated, please use -log-level=debug instead. Available log levels are info, debug, trace, warn, error, and off.

Developing

The Makefile has targets to automate building and testing:

make build test

The project also uses some linting and formatting tools. To install the tools:

make bootstrap

You can then run the additional checks:

make fmt lint mod

To run a full set of integration tests on a local kind cluster, ensure you have the following additional dependencies installed:

• docker
• kind
• kubectl
• helm
• bats

You can then run:

make setup-kind e2e-image e2e-setup e2e-test

Finally tidy up the resources created in the kind cluster with:

make e2e-teardown