Update CSI provider installation on OpenShift (#13763)

Include recommendation to use Vault agent injector on OpenShift
instead of CSI due to production security constraints.
Additional instructions included for testing and development
clusters.

website/content/docs/platform/k8s/csi/installation.mdx

@@ -22,16 +22,17 @@ 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:
 
-~> Vault CSI Provider Helm installation requires Vault Helm 0.10.0+.
+~> **Note:** Vault CSI Provider Helm installation requires Vault Helm 0.10.0+.
 
 @include 'helm/repo.mdx'
 
 Then install the chart and enable the CSI feature by setting the
 `csi.enabled` value to `true`:
 
-```bash
-# Note: this will also install the Vault server and Agent Injector.
-helm install vault hashicorp/vault --set="csi.enabled=true"
+~> **Note:** this will also install the Vault server and Agent Injector.
+
+```shell-session
+$ helm install vault hashicorp/vault --set="csi.enabled=true"
 ```
 
 Upgrades may be performed with `helm upgrade` on an existing install. Please
@@ -42,3 +43,81 @@ You can see all the available values settings by running `helm inspect values ha
 Docs](/docs/platform/k8s/helm/configuration). 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](/docs/platform/k8s/helm/openshift)
+instead of the Secrets Store CSI driver. OpenShift
+[does not recommend](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-hostpath.html)
+using `hostPath` mounting in production or
+[certify Helm charts](https://github.com/redhat-certification/chart-verifier/blob/dbf89bff2d09142e4709d689a9f4037a739c2244/docs/helm-chart-checks.md#table-2-helm-chart-default-checks)
+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.
+
+```shell-session
+$ 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](https://cloud.redhat.com/blog/managing-sccs-in-openshift).
+
+```shell-session
+$ 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.
+
+```shell-session
+$ 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.
+
+```shell-session
+$ cat > application-scc.yaml << EOF
+apiVersion: security.openshift.io/v1
+kind: SecurityContextConstraints
+metadata:
+  name: vault-csi-provider
+allowPrivilegedContainer: false
+allowHostDirVolumePlugin: true
+allowHostNetwork: true
+allowHostPorts: true
+allowHostIPC: false
+allowHostPID: false
+readOnlyRootFilesystem: false
+defaultAddCapabilities:
+- SYS_ADMIN
+runAsUser:
+  type: RunAsAny
+seLinuxContext:
+  type: RunAsAny
+fsGroup:
+  type: RunAsAny
+users:
+- system:serviceaccount:${KUBERNETES_APPLICATION_NAMESPACE}:${APPLICATION_SERVICE_ACCOUNT}
+EOF
+```
+
+Add the security context constraint for the applicaiton.
+
+```shell-session
+$ kubectl apply -f application-scc.yaml
+```

website/content/docs/platform/k8s/helm/openshift.mdx

@@ -9,8 +9,17 @@ description: >-
 
 # Run Vault on OpenShift
 
-The following documentation describes installing, running and using
-Vault and Vault Agent Injector on OpenShift.
+The following documentation describes installing, running, and using
+Vault and **Vault Agent Injector** on OpenShift.
+
+~> **Note:** We recommend using the Vault agent injector on Openshift
+   instead of the Secrets Store CSI driver. OpenShift
+   [does not recommend](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-hostpath.html)
+   using `hostPath` mounting in production or
+   [certify Helm charts](https://github.com/redhat-certification/chart-verifier/blob/dbf89bff2d09142e4709d689a9f4037a739c2244/docs/helm-chart-checks.md#table-2-helm-chart-default-checks)
+   using CSI objects because pods must run as privileged. If you would like to run the Secrets Store
+   CSI driver on a development or testing cluster, refer to
+   [installation instructions for the Vault CSI provider](/docs/platform/k8s/csi/installation).
 
 ## Requirements
 
@@ -23,7 +32,7 @@ on OpenShift:
 - Vault Helm v0.6.0+
 - Vault K8s v0.4.0+
 
-~> **Note:** Consul on OpenShift is supported since [Consul 1.9] (https://www.hashicorp.com/blog/introducing-openshift-support-for-consul-on-kubernetes). However, for highly available
+~> **Note:** Support for Consul on OpenShift is available since [Consul 1.9](https://www.hashicorp.com/blog/introducing-openshift-support-for-consul-on-kubernetes). However, for highly available
 deployments, Raft integrated storage is recommended.
 
 ## Additional Resources