Use cases for potential KEP - Inline CSI Volume Admission Control

[Adam Kaplan]

Hello sig-storage and sig-auth,

My team is developing a CSI driver which provides inline ephemeral CSI volumes [1]. In thinking through how this driver could be secured by cluster administrators, we found that current pod security standards default to allowing these volumes to be mounted [2]. Current guidance recommends that either:

1. Cluster admins deem these drivers safe for all when the CSIDriver object is created, or

2. Cluster admins rely on third party admission control.

We'd like to propose a middle ground whereby Kubernetes provides some first-class admission control for inline CSI volumes. This was initially discussed during sig-security's biweekly meeting, where we felt it was best to solicit use cases here for such an enhancement. I have a bare draft KEP in the linked Google doc, where I'm attempting to capture said use cases [3].

Please feel free to add your suggestions for use cases, or risks/mitigations that should be considered, to the Google doc.

Thank you,

Adam

[1] https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes

[2] https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md#pod-security-standards

[3] https://docs.google.com/document/d/1FSHyYrb0_zWL3d1KZRA_6aXfhF8N-v9D-ggYAidHkwE/edit?usp=sharing

--

Adam Kaplan

He/Him

Principal Software Engineer

Red Hat

100 E. Davie Street

adam....@redhat.com    T: 1-919-754-4843    

[Xing Yang]

You may be interested in this draft design proposal: https://docs.google.com/document/d/1d1KXKArMgEGMGw5Sos4lFVlg0-CtG-ESZsKXy18P-CQ/edit#.  It's a different use case.  It tries to define "VolumeSecurityStandards" based on "PodSecurityStandards" and use that to have a more fine-grained control of volume mode conversion between source and target PVCs.

Thanks,

Xing

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-auth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/CADmLb%2B%3D6Cc9Ae20xwgwj0WF07FRHg4a2bP3%2BbTZMMRMMAjuyqg%40mail.gmail.com.

[David Eads]

I like the idea of having an enumeration on a CSIDriver that allows a CSIDriver author to indicate whether their driver is safe for restricted, baseline, privileged, or requires external admission handling.  Such a field would provide a reminder to driver authors to remember to consider how their driver interacts with pod security admission and to cluster-admin trying to decide whether and how to install a CSIDriver that they are not an expert with.  A built-in admission plugin could then use the combination of the field value on a CSIDriver and the namespace label to decide whether to allow, deny, or ignore.  For migration purposes, empty would have to be "ignore" by default, but if we structure it similar to the PodSecurity admission plugin the treatment of empty could be configurable to allow empty to be privileged.

No external admission plugin will be able to create a new field on CSIDriver and since this aspect of CSIDrivers interacts with the built-in PodSecurity admission plugin it seems like a good idea to bake in support for these types of volumes and guide driver authors and cluster-admins.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-auth/CADwwA9uDSvKE_3zEgBHy4tbVhzD6RPDzNpsDJZ8SexoQ-UWpKQ%40mail.gmail.com.

[Adam Kaplan]

Resurrecting this thread - I have updated my KEP proposal more or less in the direction that David suggested [1]. The proposal will let driver maintainers or cluster admins to indicate the driver's safety level by adding the "security.kubernetes.io/csi-ephemeral-volume-profile" label to a CSIDriver object. The PodSecurityAdmission plugin will be extended to do the following:

1. Identify pods which use inline CSI volumes

2. Look up the CSIDrivers referenced in the CSI volume spec

3. Compare the driver's csi-ephemeral-volume-profile value against the namespace's pod security profiles for enforcement, warning, and audit.

It is worth debating whether or not extending the PodSecurityAdmission plugin is appropriate, or if a separate admission plugin (maintained by sig-storage) is the better approach. There are pros and cons to each, which I have tried to highlight in the current KEP draft. I welcome your feedback on this latest version.

https://docs.google.com/document/d/1FSHyYrb0_zWL3d1KZRA_6aXfhF8N-v9D-ggYAidHkwE/edit#heading=h.mtg0qtn7lyo6