From f9ba38b5d21c7a877bef3d1b25fd9d0045481399 Mon Sep 17 00:00:00 2001 From: Jonathan Dobson Date: Wed, 30 Mar 2022 18:03:17 -0600 Subject: [PATCH] Update security considerations for CSI inline ephemeral volumes --- .../concepts/storage/ephemeral-volumes.md | 29 +++++++++---------- content/en/docs/concepts/storage/volumes.md | 1 - 2 files changed, 13 insertions(+), 17 deletions(-) diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md index 282cc21f8dd35..a51984885e99c 100644 --- a/content/en/docs/concepts/storage/ephemeral-volumes.md +++ b/content/en/docs/concepts/storage/ephemeral-volumes.md @@ -127,14 +127,17 @@ instructions. ### CSI driver restrictions -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) to control which CSI drivers can be used in a Pod, specified with the -[`allowedCSIDrivers` field](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy). - -{{< note >}} -PodSecurityPolicy is deprecated and will be removed in the Kubernetes v1.25 release. -{{< /note >}} +CSI ephemeral volumes allow users to provide `volumeAttributes` +directly to the CSI driver as part of the Pod spec. A CSI driver +allowing `volumeAttributes` that are typically restricted to +administrators is NOT suitable for use in an inline ephemeral volume. +For example, parameters that are normally defined in the StorageClass +should not be exposed to users through the use of inline ephemeral volumes. + +Cluster administrators who need to restrict the CSI drivers that are +allowed to be used as inline volumes within a Pod spec may do so by: +- Removing `Ephemeral` from `volumeLifecycleModes` in the CSIDriver spec, which prevents the driver from being used as an inline ephemeral volume. +- Using an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to restrict how this driver is used. ### Generic ephemeral volumes @@ -248,14 +251,8 @@ same namespace, so that these conflicts can't occur. Enabling the GenericEphemeralVolume feature allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be -aware of this. If this does not fit their security model, they have -two choices: -- Use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) - that rejects objects like Pods that have a generic ephemeral - volume. -- Use a [Pod Security Policy](/docs/concepts/security/pod-security-policy/) - where the `volumes` list does not contain the `ephemeral` volume type - (deprecated since Kubernetes 1.21). +aware of this. If this does not fit their security model, they should +use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) that rejects objects like Pods that have a generic ephemeral volume. The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so even if users are allowed to use this new mechanism, they cannot use diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index b03c917ec4974..802272623f217 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1197,7 +1197,6 @@ A `csi` volume can be used in a Pod in three different ways: * through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) * with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) -(alpha feature) * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) if the driver supports that (beta feature)