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 for kube-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:

$ 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:

$ 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