From a991a50d2cc90e48e3c4ca76221fdd8f6ecd8c9c Mon Sep 17 00:00:00 2001 From: Jan Safranek Date: Mon, 18 May 2020 19:46:45 +0200 Subject: [PATCH] Add alternative with merging SELinux and fsGroup together --- .../1710-selinux-relabeling/README.md | 31 +++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/keps/sig-storage/1710-selinux-relabeling/README.md b/keps/sig-storage/1710-selinux-relabeling/README.md index 18be6724add..9b4d853f386 100644 --- a/keps/sig-storage/1710-selinux-relabeling/README.md +++ b/keps/sig-storage/1710-selinux-relabeling/README.md @@ -46,6 +46,7 @@ - [FSGroupChangePolicy approach](#-approach) - [Change container runtime](#change-container-runtime) - [Move SELinux label management to kubelet](#move-selinux-label-management-to-kubelet) + - [Merge FSGroupChangePolicy and SELinuxRelabelPolicy](#merge--and-) ## Release Signoff Checklist @@ -61,7 +62,7 @@ ## Summary -This KEP tries to speed up the way how volumes (incl. persistent volumes) are made available to Pods on systems with SELinux in enforcing mode. +This KEP tries to speed up the way that volumes (incl. persistent volumes) are made available to Pods on systems with SELinux in enforcing mode. Current way includes recursive relabeling of all files on a volume before a container can be started. This is slow for large volumes. ## Motivation @@ -684,4 +685,30 @@ Right now, it's the container runtime who assigns labels to containers that don' We could move SELinux label assignment to kubelet. This change would require significant changes both in kubelet (to manage the contexts) and CRI (to list used context after kubelet restart). As benefit, kubelet would mount volumes for *all* pods quickly, not only those that have explicit `SELinuxOptions`. -We are not sure if it's possible to change the default behavior to `OnVolumeMount`, without any field in `PodSecurityPolicy`. \ No newline at end of file +We are not sure if it's possible to change the default behavior to `OnVolumeMount`, without any field in `PodSecurityPolicy`. + +### Merge `FSGroupChangePolicy` and `SELinuxRelabelPolicy` +With this API, user could ask for any shortcuts that are available regarding SELinux relabeling and ownership change for FSGroup: + +```go +const ( + // The heuristic policy acts like setting both the OnVolumeMount policy and the OnRootMismatch policy. + HeuristicVolumeChangePolicy VolumeChangePolicy = "Heuristic" + RecursiveVolumeChangePolicy VolumeChangePolicy = "Recursive" +) + +type PodSecurityContext struct { + ... + VolumeChangePolicy *VolumeChangePolicy + ... +} +``` + +In the vast majority of cases it's what users want. + +However, this field is not flexible enough to accommodate special cases. +If supported by the storage backend and the volume is consumed as whole, `SELinuxRelabelPolicy: OnMount` always works. +At the same time, `FSGroupChangePolicy: OnRootMismatch` may not be desirable for volumes that are modified outside of Kubernetes, +where various files on the volume may get random owners. + +With a single `VolumeChangePolicy`, user has to fall back to `Recursive` policy and SELinux labels would be unnecessarily changed.