diff --git a/modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc b/modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc index 8c45d98f9bfe..a205bece172a 100644 --- a/modules/ephemeral-storage-additional-support-limitations-for-shared-resource-csi-driver.adoc +++ b/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`. diff --git a/modules/ephemeral-storage-csi-inline-overview.adoc b/modules/ephemeral-storage-csi-inline-overview.adoc index e9c8b73c259f..cb97b8bdaf70 100644 --- a/modules/ephemeral-storage-csi-inline-overview.adoc +++ b/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. diff --git a/modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc b/modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc index 2d06914c3f5c..552ea3fc2c29 100644 --- a/modules/ephemeral-storage-using-a-sharedconfigmap-object-in-a-pod.adoc +++ b/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 ` 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 ` 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] ==== diff --git a/modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc b/modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc index 05492b4354f3..8ffe930a3526 100644 --- a/modules/ephemeral-storage-using-a-sharedsecrets-resource-in-a-pod.adoc +++ b/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 ` 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 ` 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] ====