From c655e0648cd2c4236aabd45cb10cc815770bad7e Mon Sep 17 00:00:00 2001 From: Fabio Bertinatto Date: Mon, 31 Oct 2022 09:08:41 -0300 Subject: [PATCH] Add blog post for FSGroup on mount --- .../_posts/2022-12-06-fsgroup-on-mount.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 content/en/blog/_posts/2022-12-06-fsgroup-on-mount.md diff --git a/content/en/blog/_posts/2022-12-06-fsgroup-on-mount.md b/content/en/blog/_posts/2022-12-06-fsgroup-on-mount.md new file mode 100644 index 0000000000000..be611d002396c --- /dev/null +++ b/content/en/blog/_posts/2022-12-06-fsgroup-on-mount.md @@ -0,0 +1,34 @@ +--- +layout: blog +title: "Kubernetes 1.26: Providing pod's FSGroup to CSI drivers during mount" +date: 2022-12-06 +slug: kubernetes-12-06-fsgroup-on-mount +--- + +We are happy to announce that the delegation of fsGroup to CSI Drivers feature has graduated to General Availability (GA) in Kubernetes 1.26. + +Currently, if a fsGroup is specified in the [pod's security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod), all processes in the container will be also part of a suplementary group. + +In previous Kubernetes releases, the Kubelet would always apply the fsGroup ownership and permission changes to every file in the volume. That is done by recursively calling `chown` and `chmod` in files and directories within the volume. + +From now on, CSI drivers that support this feature can apply the fsGroup settings during attach or mount time, making the step of recursively changing the permissions of volumes in the Kubelet unnecessary. + +## How does it work? + +Initially, CSI drivers that support this feature should advertise the [VOLUME_MOUNT_GROUP](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetcapabilities) node capability. + +Once recognizing this information, the Kubelet will pass the fsGroup information to the CSI driver during the pod startup time. This is one through the [NodeStageVolumeRequest](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodestagevolume) and [NodePublishVolumeRequest](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodepublishvolume) CSI calls. + +How the CSI driver will apply the fsGroup to the files in the volume depends on the storage backend. As an example, Azure File CSI Driver utilizes the `mount -o context` option to do that. + +It should be noted that in the example above the Kubelet will refrain from applying the permission changes into the volumes' files. In addition to that, `CSIDriver.spec.fsGroupPolicy` and `Pod.spec.securityContext.fsGroupChangePolicy` are ignored. + +## Why is it important? + +Certain underlying storage environments, like Azure File, do not support changing ownership and permissions of files. The CSI driver is able to set the file permissions only when it mounts the volume. + +## How do I use it? + +This feature should be mostly transparent to users. If you maintain a CSI driver that should support this feature, head over to the [CSI Developer Documentation on FSGroup](https://kubernetes-csi.github.io/docs/support-fsgroup.html). + +Existing CSI drivers that do not support this feature will continue to work as usual, i.e., they will not receive any fsGroup information from the Kubelet. In addition to that, the Kubelet will continue to recursively change the ownership and permissions of files when the pod's fsGroup is set.