Kubernetes 1.20:卷权限更改的粒度控制

s :Hemant Kumar,Red Hat和Christian Huffman,Red Hat

Kubernetes 1.20带来了两个重要的Beta功能,使Kubernetes管理员和用户都可以更充分地控制在Pod内装入卷时如何应用卷权限。

允许用户跳过装载时的递归权限更改

传统上,如果您的Pod以非root用户身份运行(你应该), you must specify a fsGroup inside the pod’s security context so that the volume can be readable 和 writable by the Pod. This requirement is covered in more detail in 这里 .

But one side-effect of setting fsGroup is that, each time a volume is mounted, Kubernetes must recursively chown()chmod() all the files 和 directories inside the volume - with a few exceptions noted below. This happens even if group ownership of the volume already matches the requested fsGroup, 和 can be pretty expensive for larger volumes with lots of small files, which causes pod startup to take a long time. This scenario has been a 已知问题 一段时间之后,在Kubernetes 1.20中,如果卷已经具有正确的权限,我们将提供旋钮以选择退出递归权限更改。

When configuring a pod’s security context, set fsGroupChangePolicy to "OnRootMismatch" so if the root of the volume already has the correct permissions, the recursive permission change can be skipped. Kubernetes ensures that permissions of the top-level directory are changed last the first time it applies permissions.

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

您可以在中了解更多信息 为Pod配置批量许可和所有权更改策略.

允许CSI驱动程序声明对基于fsGroup的权限的支持

尽管上一节暗示了Kubernetes 总是 recursively changes permissions of a volume if a Pod has a fsGroup, this is not strictly true. For certain multi-writer volume types, such as NFS or Gluster, the cluster doesn’t perform recursive permission changes even if the pod has a fsGroup. Other volume types may not even support chown()/chmod(), which rely on Unix-style permission control primitives.

那么,我们如何知道何时应用递归权限更改以及何时不应该应用?对于树内存储驱动程序,这相对简单。对于 CSI 由于驱动程序可能跨越多种平台和存储类型,因此此问题可能是一个更大的挑战。

以前,每当将CSI卷装入Pod时,Kubernetes都会尝试自动确定是否应修改权限和所有权。这些方法不精确,可能会导致问题,正如我们已经提到的,具体取决于存储类型。

的 CSI Driver custom resource now has a .spec.fsGroupPolicy field, allowing storage drivers to explicitly opt in or out of these recursive modifications. By having the CSI driver specify a policy for the backing volumes, Kubernetes can avoid needless modification attempts. This optimization helps to reduce volume mount time 和 also cuts own reporting errors about modifications that would never succeed.

CSI Driver FSGroupPolicy API

从Kubernetes 1.20开始,三个FSGroupPolicy值可用,并且为将来的发行版计划了更多的值。

  • ReadWriteOnceWithFSType - This is the default policy, applied if no fsGroupPolicy is defined; this preserves the behavior from previous Kubernetes releases. Each volume is examined at mount time to determine if permissions should be recursively applied.
  • 文件 -无论文件系统类型或PersistentVolumeClaim的访问方式如何,都始终尝试应用权限修改。
  • 没有 -切勿应用权限修改。

如何使用?

的 only configuration needed is defining fsGroupPolicy inside of the .spec for a CSI Driver. Once that element is defined, any subsequently mounted volumes will automatically use the defined policy. 的 re’s no additional deployment required!

下一步是什么?

根据反馈和采用情况,Kubernetes团队计划在1.21或1.22中将这些实现推向GA。

我该如何学习?

Kubernetes 项目文档中更详细地说明了此功能: CSI 驱动程序fsGroup支持为Pod配置批量许可和所有权更改策略 .

我该如何参与?

Kubernetes Slack频道#csi 和任何 标准SIG存储通信通道 是联系SIG存储和CSI团队的绝佳媒介。

那些有兴趣参与CSI或Kubernetes Storage System的任何部分的设计和开发的人,请加入 Kubernetes 存储特别兴趣小组(SIG)。我们正在迅速发展,并随时欢迎新的贡献者。