[enterprise-4.13] OSDOCS-RHDEVDOCS-4304: shared resource updates for validating admission webhooks

modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc

@@ -7,6 +7,7 @@
 The Shared Resource CSI Driver has the following noteworthy limitations:
 
 * The driver is subject to the limitations of Container Storage Interface (CSI) inline ephemeral volumes.
-* The value of the `readOnly` field must be `true`. Otherwise, on volume provisioning during pod startup, the driver returns an error to the kubelet. This limitation is in keeping with proposed best practices for the upstream Kubernetes CSI Driver to apply SELinux labels to associated volumes.
+* The value of the `readOnly` field must be `true`. On `Pod` creation, a validating admission webhook rejects the pod creation if `readOnly` is `false`. If for some reason the validating admission webhook cannot be contacted, on volume provisioning during pod startup, the driver returns an error to the kubelet. Requiring `readOnly` is `true` is in keeping with proposed best practices for the upstream Kubernetes CSI Driver to apply SELinux labels to associated volumes.
 * The driver ignores the `FSType` field because it only supports `tmpfs` volumes.
 * The driver ignores the `NodePublishSecretRef` field. Instead, it uses `SubjectAccessReviews` with the `use` verb to evaluate whether a pod can obtain a volume that contains `SharedSecret` or `SharedConfigMap` custom resource (CR) instances.
+* You cannot create `SharedSecret` or `SharedConfigMap` custom resource (CR) instances whose names start with `openshift`.

modules/ephemeral-storage-csi-inline-overview.adoc

@@ -15,7 +15,7 @@ This feature allows you to specify CSI volumes directly in the `Pod` specificati
 By default, {product-title} supports CSI inline ephemeral volumes with these limitations:
 
 * Support is only available for CSI drivers. In-tree and FlexVolumes are not supported.
-* The Shared Resource CSI Driver supports inline ephemeral volumes as a Technology Preview feature.
+* The Shared Resource CSI Driver supports using inline ephemeral volumes only to access `Secrets` or `ConfigMaps` across multiple namespaces as a Technology Preview feature.
 * Community or storage vendors provide other CSI drivers that support these volumes. Follow the installation instructions provided by the CSI driver provider.
 
 CSI drivers might not have implemented the inline volume functionality, including `Ephemeral` capacity. For details, see the CSI driver documentation.

modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc

@@ -10,9 +10,9 @@ To access a `SharedConfigMap` custom resource (CR) instance from a pod, you gran
 
 * You have created a `SharedConfigMap` CR instance for the config map that you want to share across namespaces in the cluster.
 * You must have permission to perform the following actions:
-** Create build configs and start builds.
 ** Discover which `SharedConfigMap` CR instances are available by entering the `oc get sharedconfigmaps` command and getting a non-empty list back.
-** Determine if the `builder` service accounts available to you in your namespace are allowed to use the given `SharedSecret` CR instance. That is, you can run `oc adm policy who-can use <identifier of specific SharedSecret>` to see if the `builder` service account in your namespace is listed.
+** Determine if the service account your pod specifies is allowed to use the given `SharedSecret` CR instance. That is, you can run `oc adm policy who-can use <identifier of specific SharedSecret>` to see if the service account in your namespace is listed.
+** Determine if the service account your pod specifies is allowed to use `csi` volumes, or if you, as the requesting user who created the pod directly, are allowed to use `csi` volumes.  See "Understanding and managing pod security admission" for details.
 
 [NOTE]
 ====

modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc

@@ -10,9 +10,9 @@ To access a `SharedSecret` custom resource (CR) instance from a pod, you grant a
 
 * You have created a `SharedSecret` CR instance for the secret you want to share across namespaces in the cluster.
 * You must have permission to perform the following actions
-** Create build configs and start builds.
 ** Discover which `SharedSecret` CR instances are available by entering the `oc get sharedsecrets` command and getting a non-empty list back.
-** Determine if the `builder` service accounts available to you in your namespace are allowed to use the given `SharedSecret` CR instance. That is, you can run `oc adm policy who-can use <identifier of specific SharedSecret>` to see if the `builder` service account in your namespace is listed.
+** Determine if the service account your pod specifies is allowed to use the given `SharedSecret` CR instance. That is, you can run `oc adm policy who-can use <identifier of specific SharedSecret>` to see if the service account in your namespace is listed.
+** Determine if the service account your pod specifies is allowed to use `csi` volumes, or if you, as the requesting user who created the pod directly, are allowed to use `csi` volumes.  See "Understanding and managing pod security admission" for details.
 
 [NOTE]
 ====