Investigate the use of ID-mapped mounts

[WanzenBug]

ID-mapped mounts promise to make it easy to change the observable root uid+gid of a volume. This would be useful for us since any use of fsGroup currently involves a chown -R by kubelet. Depending on the size of the volume, this can delay actually starting the Pod after NodePublishVolume() by over 10 minutes.

Here are the results of a bit of investigation:

• ID mapped mounts could be integrated into the CSI driver
• ID mapped mounts could also be something to directly integrate with kubelet
• Altough available since kernel 5.12, RHEL9 and copy-cats have it disabled for unspecified security concerns (NB: CentOS Stream and Fedora have it enabled, and apart from that one thread that did not go anywhere it seems to work just fine)
• The tooling is non-existent. We would need to write our own mount wrapper should we ever want to continue on that path.

[rck]

would it make sense to open an issue somewhere in kubernetes upstream?

[WanzenBug]

would it make sense to open an issue somewhere in kubernetes upstream?

Sure. Since I already had a bit of a discussion on the topic in the #sig-storage channel of the kubernetes slack, I'll ask there on what needs to happen to get it into upstream.