Merge pull request #1403 from splunk/CSPL_3149

CSPL-3149 - Address openshift documentation

docs/OpenShift.md

@@ -2,11 +2,10 @@
 
 The Splunk Operator will always start Splunk Enterprise containers using
 a specific, unprivileged `splunk(41812)` user and group to allow write access
-to Kubernetes PersistentVolumes. This follows best security practices,
-which helps prevent any malicious actor from escalating access outside of the
-container and compromising the host. For more information, please see the
-Splunk Enterprise container's
-[Documentation on Security](https://github.com/splunk/docker-splunk/blob/develop/docs/SECURITY.md).
+to Kubernetes PersistentVolumes. This follows best security practices, helping
+prevent malicious actors from escalating access beyond the container and
+compromising the host. For more information, please see the Splunk Enterprise
+container's [Documentation on Security](https://github.com/splunk/docker-splunk/blob/develop/docs/SECURITY.md).
 
 The Splunk Enterprise pods are attached to the `default` serviceaccount or the configured
 [serviceaccount](CustomResources.md#common-spec-parameters-for-splunk-enterprise-resources) if
@@ -16,7 +15,8 @@ and runs as user `1001`.
 Users of Red Hat OpenShift may find that the default Security Context
 Constraint is too restrictive. You can fix this by granting the appropriate
 Service Accounts the `nonroot` Security Context Constraint by running the
-following commands within your namespace:
+following commands within your namespace. If you are using OpenShift 4.14
+or later, you must use the `nonroot-v2` Security Context Constraint instead.
 
 For the Splunk Operator pod:
 ```