Installing the Vault CSI provider
Prerequisites
- Kubernetes 1.16+ for both the master and worker nodes (Linux-only)
- Secrets store CSI driver installed
TokenRequest
endpoint available, which requires setting the flags--service-account-signing-key-file
and--service-account-issuer
forkube-apiserver
. Set by default from 1.20+ and earlier in most managed services.
Installation using helm
The Vault Helm chart is the recommended way to install and configure the Vault CSI Provider in Kubernetes.
To install a new instance of Vault and the Vault CSI Provider, first add the HashiCorp helm repository and ensure you have access to the chart:
Note: Vault CSI Provider Helm installation requires Vault Helm 0.10.0+.
$ helm repo add hashicorp https://helm.releases.hashicorp.com"hashicorp" has been added to your repositories$ helm search repo hashicorp/vaultNAME CHART VERSION APP VERSION DESCRIPTIONhashicorp/vault 0.29.0 1.18.1 Official HashiCorp Vault Chart
Then install the chart and enable the CSI feature by setting the
csi.enabled
value to true
:
Note: this will also install the Vault server and Agent Injector.
$ helm install vault hashicorp/vault --set="csi.enabled=true"
Upgrades may be performed with helm upgrade
on an existing installation. Please
always run Helm with --dry-run
before any install or upgrade to verify
changes.
You can see all the available values settings by running helm inspect values hashicorp/vault
or by reading the Vault Helm Configuration
Docs. Commonly used values in the Helm
chart include limiting the namespaces the Vault CSI Provider runs in, TLS options and
more.
Installation on OpenShift
We recommend using the Vault agent injector on Openshift
instead of the Secrets Store CSI driver. OpenShift
does not recommend
using hostPath
mounting in production or
certify Helm charts
using CSI objects because pods must run as privileged. Pods will have elevated access to
other pods on the same node, which OpenShift does not recommend.
You can run the Secrets Store CSI driver with additional security configurations on a OpenShift development or testing cluster.
Deploy the Secrets Store CSI driver and Vault Helm chart to your OpenShift cluster.
Then, patch the DaemonSet
for the Vault CSI provider to
run with a privileged security context.
$ kubectl patch daemonset vault-csi-provider \ --type='json' \ --patch='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'
The Secrets Store CSI driver and Vault CSI provider need hostPath
mount access.
Add the service account for the Secrets Store CSI driver to the privileged
security context constraint.
$ oc adm policy add-scc-to-user privileged system:serviceaccount:${KUBERNETES_VAULT_NAMESPACE}:secrets-store-csi-driver
Add the service account for the Vault CSI provider to the privileged
security context constraint.
$ oc adm policy add-scc-to-user privileged system:serviceaccount:${KUBERNETES_VAULT_NAMESPACE}:vault-csi-provider
You need to give additional access to the application retrieving secrets with the Vault CSI provider.
Create a SecurityContextConstraint
to allowHostDirVolumePlugin
, allowHostDirVolumePlugin
, and
allowHostPorts
for the application's service account.
You can adjust the other attributes based on your application's runtime configuration.
$ cat > application-scc.yaml << EOFapiVersion: security.openshift.io/v1kind: SecurityContextConstraintsmetadata: name: vault-csi-providerallowPrivilegedContainer: falseallowHostDirVolumePlugin: trueallowHostNetwork: trueallowHostPorts: trueallowHostIPC: falseallowHostPID: falsereadOnlyRootFilesystem: falsedefaultAddCapabilities:- SYS_ADMINrunAsUser: type: RunAsAnyseLinuxContext: type: RunAsAnyfsGroup: type: RunAsAnyusers:- system:serviceaccount:${KUBERNETES_APPLICATION_NAMESPACE}:${APPLICATION_SERVICE_ACCOUNT}EOF
Add the security context constraint for the application.
$ kubectl apply -f application-scc.yaml