KEP-596: update security considerations

keps/sig-storage/596-csi-inline-volumes/README.md

@@ -12,12 +12,12 @@
   - [User Stories](#user-stories)
     - [Examples](#examples)
   - [Risks and Mitigations](#risks-and-mitigations)
+    - [Security Considerations](#security-considerations)
 - [Design Details](#design-details)
   - [VolumeHandle generation](#volumehandle-generation)
   - [API updates](#api-updates)
   - [Support for inline CSI volumes](#support-for-inline-csi-volumes)
   - [Secret reference](#secret-reference)
-  - [Specifying allowed inline drivers with <code>PodSecurityPolicy</code>](#specifying-allowed-inline-drivers-with-)
   - [Ephemeral inline volume operations](#ephemeral-inline-volume-operations)
   - [Test Plan](#test-plan)
     - [All unit tests](#all-unit-tests)
@@ -77,7 +77,6 @@ Implementing support for embedding volumes directly in pod specs would allow dri
 * Provide a high level design for ephemeral inline CSI volumes support
 * Define API changes needed to support this feature
 * Outlines how ephemeral inline CSI volumes would work 
-* Ensure that inline CSI volumes usage is secure
 
 ### Non-goals
 
@@ -141,6 +140,16 @@ How will UX be reviewed, and by whom?
 Consider including folks who also work outside the SIG or subproject.
 -->
 
+#### Security Considerations
+
+CSI driver vendors that support inline volumes will be responsible for secure handling of volumes.
+
+For example, `csi-driver-nfs` allows anybody who can create a pod to mount any NFS volume into that pod, when the cluster admin deploys the driver with csi driver instance allowing ephemeral use. This option is not on by default, but may be surprising to some admins that this allows mounting of any NFS volume and could be unsafe.
+
+Downstream distributions and cluster admins that wish to exercise fine-grained control over which CSI drivers are allowed to use ephemeral inline volumes within a pod spec should do so with a 3rd party pod admission plugin or webhook (not part of this KEP).
+
+We will update the documentation to include the security aspects of inline CSI volumes and recommend CSI driver vendors not implement inline volumes for persistent storage unless they also provide a 3rd party pod admission plugin.
+
 ## Design Details
 
 ### VolumeHandle generation
@@ -241,30 +250,6 @@ The secret reference declared in an ephemeral inline volume can only be used wit
 * `LocalObjectReference` do not include a namespace reference.  This is to prevent reference to arbitrary namespace values.
 * The namespace needed will be extracted from the the pod spec by the Kubelet code during mount.
 
-### Specifying allowed inline drivers with `PodSecurityPolicy`
-
-To control which CSI driver is allowed to be use ephemeral inline volumes within a pod spec, a new `PodSecurityPolicy` called `AllowedCSIDrivers` is introduced as shown below:
-
-```go
-  type PodSecurityPolicySpec struct {
-	// <snip>
-
-	// AllowedCSIDrivers is a whitelist of allowed CSI drivers used inline in a pod spec.  Empty or nil indicates that no
-	// CSI drivers may be used in this way. This parameter is effective only when the usage of the CSI plugin
-	// is allowed in the "Volumes" field.
-	// +optional
-	AllowedCSIDrivers []AllowedCSIDriver
-  }
-
-  // AllowedCSIDriver represents a single CSI driver that is allowed to be used.
-  type AllowedCSIDriver struct {
-	// Name of the CSI driver
-	Name string
-  }  
-```
-
-Value `PodSecurityPolicy.AllowedCSIDrivers` must be explicitly set with the names of CSI drivers that are allowed to be embedded within a pod spec.  An empty value means no CSI drivers are allowed to be specified inline inside a pod spec.
-
 ### Ephemeral inline volume operations
 
 Inline volume requests can only participate in mount/unmount volume operations. This phase is handled by the Kubelet which is responsible for mounting/unmounting device and/or filesystem mount points inside a pod. At mount time, the internal API will pass the volume information via parameter of `volume.Spec` which will contain a value of either type `v1.CSIVolumeSource` (for volume originated from pod specs) or `v1.CSIPersistentVolume` for volume originating from PV/PVC.  The code will check for the presence of a `v1.CSIVolumeSource` or `v1.CSIPersistentVolume` value.  If a `v1.CSIPersistentVolume` is found, the operation is considered non-ephemeral and follows regular PV/PVC execution flow.  If, however, the internal volume API passes a `v1.CSIVolumeSource`:
@@ -300,7 +285,6 @@ Since ephemeral volume requests will participate in only the mount/unmount volum
 * CSI Kubelet code invokes driver operations during mount for ephemeral volumes: `checkPodLogs` in `csi_mock_volume.go` (upcoming PR)
 * CSI Kubelet code invokes driver operation during unmount of ephemeral volumes: `checkPodLogs` in `csi_mock_volume.go` (upcoming PR)
 * CSI Kubelet cleans up ephemeral volume paths once pod goes away: TODO
-* Apply PodSecurity settings for allowed CSI drivers: TODO
 * Enable testing of an external ephemeral CSI driver: https://github.com/kubernetes/kubernetes/pull/79983/files#diff-e5fc8d9911130b421b74b1ebc273f458
 * Enable testing of the csi-host-path-driver in ephemeral mode in Kubernetes-CSI Prow jobs and Kubernetes itself: TODO