Proposed title of this feature request

Improve handling of recursive permission settings for fsGroup

What is the nature and description of the request?

Prior version 1.20 the fsGroup setting in the pod caused Kubernetes to recursively change ownership of all the files on the PersistentVolume. This could have been very slow to the point where the pod using fsGroup might have been reported as failed.

To mitigate the problem, Kubernetes 1.20 introduced a new [API that lets users to skip the recursive permission change|https://kubernetes.io/blog/2020/12/14/kubernetes-release-1.20-fsgroupchangepolicy-fsgrouppolicy]. This solution is however still very problematic: it requires users to set additional option for the volumes with large number of files and it still may happen that the pod would not be able to access the files on the volume.

There is a new feature in the Linux OS that may lead to better universal solution: idmapped mounts which allows to map the UID/GID of files on the volume to different ones. This is still not complete equivalent of recursive ownership change since the mapping must be 1:1 and the fsGroup feature expects ALL:1 mapping. However it is worth exploring potential update of the idmapped mount feature to allow also the ID squashing and using it for the fsGroup volume mounting.

The idmapped mounts are currently not supported by RHEL even though the feature is present in the upstream projects.

Why does the customer need this? (List the business requirements here)

OpenShift customers are required to run pods with non-root permissions and hence must use the fsGroup setting and the manual workaround described above. This feature request originates from discussions among several Red Hat engineering teams not from the field.

List any affected packages or components.

RHEL: kernel, util-linux

OpenShift: Storage / Kubernetes, Storage / Kubernetes External Components