kind: CSIDriver
metadata:
name: csi.mydriver.company.org
labels:
security.openshift.io/csi-ephemeral-volume-profile: restricted (1)
Container Storage Interface (CSI) inline ephemeral volumes allow you to define a Pod
spec that creates inline ephemeral volumes when a pod is deployed and delete them when a pod is destroyed.
This feature is only available with supported Container Storage Interface (CSI) drivers:
Shared Resource CSI driver
Azure File CSI driver
Secrets Store CSI driver
Traditionally, volumes that are backed by Container Storage Interface (CSI) drivers can only be used with a PersistentVolume
and PersistentVolumeClaim
object combination.
This feature allows you to specify CSI volumes directly in the Pod
specification, rather than in a PersistentVolume
object. Inline volumes are ephemeral and do not persist across pod restarts.
The Shared Resource CSI Driver feature is now generally available in Builds for Red Hat OpenShift 1.1. This feature is now deprecated in OpenShift Container Platform. To use this feature, ensure you are using Builds for Red Hat OpenShift 1.1 or a more recent version. |
By default, OpenShift Container Platform 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 using inline ephemeral volumes only to access Secrets
or ConfigMaps
across multiple namespaces as a Technology Preview feature in OpenShift Container Platform.
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.
The Container Storage Interface (CSI) Volume Admission plugin allows you to restrict the use of an individual CSI driver capable of provisioning CSI ephemeral volumes on pod admission. Administrators can add a csi-ephemeral-volume-profile
label, and this label is then inspected by the Admission plugin and used in enforcement, warning, and audit decisions.
To use the CSI Volume Admission plugin, administrators add the security.openshift.io/csi-ephemeral-volume-profile
label to a CSIDriver
object, which declares the CSI driver’s effective pod security profile when it is used to provide CSI ephemeral volumes, as shown in the following example:
kind: CSIDriver
metadata:
name: csi.mydriver.company.org
labels:
security.openshift.io/csi-ephemeral-volume-profile: restricted (1)
1 | CSI driver object YAML file with the csi-ephemeral-volume-profile label set to "restricted" |
This “effective profile” communicates that a pod can use the CSI driver to mount CSI ephemeral volumes when the pod’s namespace is governed by a pod security standard.
The CSI Volume Admission plugin inspects pod volumes when pods are created; existing pods that use CSI volumes are not affected. If a pod uses a container storage interface (CSI) volume, the plugin looks up the CSIDriver
object and inspects the csi-ephemeral-volume-profile
label, and then use the label’s value in its enforcement, warning, and audit decisions.
When a CSI driver has the csi-ephemeral-volume-profile
label, pods using the CSI driver to mount CSI ephemeral volumes must run in a namespace that enforces a pod security standard of equal or greater permission. If the namespace enforces a more restrictive standard, the CSI Volume Admission plugin denies admission. The following table describes the enforcement behavior for different pod security profiles for given label values.
Pod security profile | Driver label: restricted | Driver label: baseline | Driver label: privileged |
---|---|---|---|
Restricted |
Allowed |
Denied |
Denied |
Baseline |
Allowed |
Allowed |
Denied |
Privileged |
Allowed |
Allowed |
Allowed |
The CSI Volume Admission plugin can warn you if the CSI driver’s effective profile is more permissive than the pod security warning profile for the pod namespace. The following table shows when a warning occurs for different pod security profiles for given label values.
Pod security profile | Driver label: restricted | Driver label: baseline | Driver label: privileged |
---|---|---|---|
Restricted |
No warning |
Warning |
Warning |
Baseline |
No warning |
No warning |
Warning |
Privileged |
No warning |
No warning |
No warning |
The CSI Volume Admission plugin can apply audit annotations to the pod if the CSI driver’s effective profile is more permissive than the pod security audit profile for the pod namespace. The following table shows the audit annotation applied for different pod security profiles for given label values.
Pod security profile | Driver label: restricted | Driver label: baseline | Driver label: privileged |
---|---|---|---|
Restricted |
No audit |
Audit |
Audit |
Baseline |
No audit |
No audit |
Audit |
Privileged |
No audit |
No audit |
No audit |
If the referenced CSI driver for a CSI ephemeral volume does not have the csi-ephemeral-volume-profile
label, the CSI Volume Admission plugin considers the driver to have the privileged profile for enforcement, warning, and audit behaviors. Likewise, if the pod’s namespace does not have the pod security admission label set, the Admission plugin assumes the restricted profile is allowed for enforcement, warning, and audit decisions. Therefore, if no labels are set, CSI ephemeral volumes using that CSI driver are only usable in privileged namespaces by default.
The CSI drivers that ship with OpenShift Container Platform and support ephemeral volumes have a reasonable default set for the csi-ephemeral-volume-profile
label:
Shared Resource CSI driver: restricted
Azure File CSI driver: privileged
An admin can change the default value of the label if desired.
You can embed a CSI inline ephemeral volume in the Pod
specification in OpenShift Container Platform. At runtime, nested inline volumes follow the ephemeral lifecycle of their associated pods so that the CSI driver handles all phases of volume operations as pods are created and destroyed.
Create the Pod
object definition and save it to a file.
Embed the CSI inline ephemeral volume in the file.
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
command: [ "sleep", "1000000" ]
volumes: (1)
- name: my-csi-inline-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:
foo: bar
1 | The name of the volume that is used by pods. |
Create the object definition file that you saved in the previous step.
$ oc create -f my-csi-app.yaml