Do we need gidMin/gidMax in the StorageClass?

[JohnStrunk]

In PR #30 we have a proposed set of storage class parameters. As a part of creating this list, I took a look at the existing parameters accepted by the glusterfs provisioner that uses Heketi. It is unclear what the utility of the gidMin and gidMax parameters are and whether they should be brought forward into the CSI driver.

[JohnStrunk]

This seems related, but not consistent with the fsGroup parameter in a container or pod's securityContext. The info on fsGroup points to https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-ownership-management.md

Also related in the volume design that discusses whether and which volume types support ownership change: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volumes.md#volume-changes

[JohnStrunk]

Related Heketi items:

• Be able to assign a gid to a volume as it's created: api: New GID support in VolumeCreate API heketi/heketi#530
• BZ for ^^^ https://bugzilla.redhat.com/show_bug.cgi?id=1356437
• Enable sgid on the volume: chmod cmd should also set S bit to enable a particular group to write in subdirs heketi/heketi#611

[JohnStrunk]

Thanks to @rootfs I believe we have the source:

• The bug: "permission denied" error when writing to provisioned gluster volumes. openshift/origin#11556
• The patch & related discussion on assigning gids: Use Gid when provisioning Gluster Volumes. kubernetes/kubernetes#35460

[jarrpa]

After some recent discussion, it seems we can get away without gidMin and gidMax without running into any security problems. The GID on root of the GlusterFS volume does need to be known, but it is exposed as an annotation on the associated PV. For dynamically provisioned volumes, we control that value. That annotation is then added to the supplementalGroups of any Pod that attached to the GlusterFS volume's PVC. Thus, the onus of security falls on the access to the PVC and less so on the underlying filesystem. The purpose of the GID, then, is merely to grant consistent access across Pod restarts and for RWX cases.

To resolve this, we can simply generate a random GID per volume. If this happens to overlap with a GID inside a Pod's containers, no additional security threat that isn't already present in the gidMin/gidMax implementation would be added.