Add blog post for FSGroup on mount

content/en/blog/_posts/2022-12-06-fsgroup-on-mount.md

@@ -0,0 +1,40 @@
+---
+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
+---
+
+**Author:** Fabio Bertinatto (Red Hat), Hemant Kumar (Red Hat)
+
+The delegation of fsGroup to CSI Drivers feature was first introduced as alpha in Kubernetes 1.22, reaching the beta mark in Kubernetes 1.25. Today we are happy to announce that this 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 pod's containers will be part of the additional group specified in that field.
+
+In previous Kubernetes releases, the Kubelet would *always* apply the fsGroup ownership and permission changes to files in the volume according to the policy specified in the `Pod.spec.securityContext.fsGroupChangePolicy` field.
+
+Starting with Kubernetes 1.26, CSI drivers have the option to apply the fsGroup settings during attach or mount time of the volumes, freeing the Kubelet from changing the permissions of volumes.
+
+## 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 done 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.
+
+Consequently, the CSI driver should apply the fsGroup to the files in the volume using a mount option. As an example, Azure File CSI Driver utilizes the `gid` mount option to map the fsGroup information to all the files in the volume.
+
+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` fields will have no effect.
+
+For more details about the inner workings of this feature, check out the [feature enhancement](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2317-fsgroup-on-mount/README.md) and the [CSI Developer Documentation](https://kubernetes-csi.github.io/docs/support-fsgroup.html).
+
+## Why is it important?
+
+Without this feature, applying the fsGroup information to files is not possible in certain storage environments.
+
+For instance, Azure File does not support changing ownership and permissions of files. The CSI driver is only able to set the file permissions once, 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) for more information on how to support this feature in your CSI driver.
+
+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 perform the ownership and permissions changes to files according to the policies specified in `CSIDriver.spec.fsGroupPolicy` and `Pod.spec.securityContext.fsGroupChangePolicy`.