Update security considerations for CSI inline ephemeral volumes

content/en/docs/concepts/storage/ephemeral-volumes.md

@@ -127,14 +127,15 @@ instructions.
 
 ### CSI driver restrictions
 
-{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
+CSI ephemeral volumes allow users to provide `volumeAttributes`
+directly to the CSI driver as part of the Pod spec. A CSI driver
+requiring `volumeAttributes` that are typically restricted to
+administrators is NOT suitable for use in an inline ephemeral volume.
 
-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 >}}
+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.
+- Using an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to restrict how this driver is used.
 
 ### Generic ephemeral volumes
 
@@ -248,14 +249,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

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)