Kubernetes 1.31：细粒度的 SupplementalGroups 控制

本博客讨论了 Kubernetes 1.31 中的一项新功能，旨在改进 Pod 中容器对补充组的处理。

动机：容器镜像中 /etc/group 定义的隐式组成员身份

尽管此行为可能不受许多 Kubernetes 集群用户/管理员的欢迎，但默认情况下，kubernetes 会合并来自 Pod 的组信息和容器镜像中 /etc/group 定义的信息。

让我们看一个例子，下面的 Pod 在 Pod 的安全上下文中指定了 runAsUser=1000、runAsGroup=3000 和 supplementalGroups=4000。

implicit-groups.yaml

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

ctr 容器中 id 命令的结果是什么？

# Create the Pod:
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/implicit-groups.yaml

# Verify that the Pod's Container is running:
$ kubectl get pod implicit-groups

# Check the id command
$ kubectl exec implicit-groups -- id

然后，输出应该类似于这样

uid=1000 gid=3000 groups=3000,4000,50000

即使 50000 根本没有在 Pod 的清单中定义，补充组（groups 字段）中的组 ID 50000 来自哪里？答案是容器镜像中的 /etc/group 文件。

检查容器镜像中 /etc/group 的内容应该显示如下

$ kubectl exec implicit-groups -- cat /etc/group
...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

啊哈！容器的主用户 1000 在最后一项中属于组 50000。

因此，容器镜像中 /etc/group 中为容器的主用户定义的组成员身份将隐式合并到来自 Pod 的信息中。 请注意，这是当前 CRI 实现从 Docker 继承的设计决策，并且社区直到现在才真正重新考虑它。

它有什么问题？

来自容器镜像中 /etc/group 的隐式合并组信息可能会引起一些担忧，尤其是在访问卷时（有关详细信息，请参阅 kubernetes/kubernetes#112879），因为文件权限由 Linux 中的 uid/gid 控制。 更糟糕的是，来自 /etc/group 的隐式 gid 无法被任何策略引擎检测/验证，因为清单中没有关于隐式组信息的线索。 这也可能是 Kubernetes 安全的一个问题。

Pod 中细粒度的 SupplementalGroups 控制：SupplementaryGroupsPolicy

为了解决上述问题，Kubernetes 1.31 在 Pod 的 .spec.securityContext 中引入了新字段 supplementalGroupsPolicy。

此字段提供了一种控制如何计算 Pod 中容器进程的补充组的方法。 可用的策略如下

• 合并：将合并容器主用户的 /etc/group 中定义的组成员身份。 如果未指定，则将应用此策略（即，为了向后兼容，保持原样行为）。

• 严格：它仅将 fsGroup、supplementalGroups 或 runAsGroup 字段中指定的组 ID 作为容器进程的补充组附加。 这意味着不会合并容器主用户的 /etc/group 中定义的组成员身份。

让我们看看 Strict 策略是如何工作的。

strict-supplementalgroups-policy.yaml

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

# Create the Pod:
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/strict-supplementalgroups-policy.yaml

# Verify that the Pod's Container is running:
$ kubectl get pod strict-supplementalgroups-policy

# Check the process identity:
kubectl exec -it strict-supplementalgroups-policy -- id

输出应该类似于这样

uid=1000 gid=3000 groups=3000,4000

您可以看到 Strict 策略可以从 groups 中排除组 50000！

因此，确保 supplementalGroupsPolicy: Strict（由某些策略机制强制执行）有助于防止 Pod 中的隐式补充组。

附加到 Pod 状态的进程标识

此功能还通过 .status.containerStatuses[].user.linux 字段公开附加到容器的第一个容器进程的进程标识。 这有助于查看是否附加了隐式组 ID。

...
status:
  containerStatuses:
  - name: ctr
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

功能可用性

要启用 supplementalGroupsPolicy 字段，必须使用以下组件

• Kubernetes：v1.31 或更高版本，并启用 SupplementalGroupsPolicy 功能门控。截至 v1.31，该门控标记为 alpha。
• CRI 运行时
  • containerd：v2.0 或更高版本
  • CRI-O：v1.31 或更高版本

您可以在节点的 .status.features.supplementalGroupsPolicy 字段中查看是否支持该功能。

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

下一步是什么？

Kubernetes SIG Node 希望 - 并且预期 - 该功能将在 Kubernetes 的未来版本中升级为 beta 版本，并最终实现通用可用性 (GA)，以便用户不再需要手动启用功能门控。

为了向后兼容，当未指定 supplementalGroupsPolicy 时，将应用 Merge 策略。

我如何了解更多？

• 有关 supplementalGroupsPolicy 的更多详细信息，请参阅 配置 Pod 或容器的安全上下文。
• KEP-3619：细粒度的 SupplementalGroups 控制

如何参与？

此功能由 SIG Node 社区推动。 请加入我们，与社区联系，并分享您对上述功能及其他方面的想法和反馈。 我们期待您的来信！

• ←上一篇
下一篇→