为 Pod 或容器配置安全上下文

安全上下文为 Pod 或容器定义了特权和访问控制设置。安全上下文设置包括但不限于：

• 自由访问控制：访问对象（如文件）的权限基于用户 ID (UID) 和组 ID (GID)。

• 安全增强型 Linux (SELinux)：对象被分配安全标签。

• 作为特权或非特权运行。

• Linux Capabilities：授予进程一些特权，但不是根用户的所有特权。

• AppArmor：使用程序配置文件来限制单个程序的功能。

• Seccomp：过滤进程的系统调用。

• allowPrivilegeEscalation：控制进程是否可以获得比其父进程更多的特权。这个布尔值直接控制容器进程是否设置 no_new_privs 标志。当容器满足以下条件时，allowPrivilegeEscalation 总是为 true：

  • 以特权方式运行，或者
  • 具有 CAP_SYS_ADMIN

• readOnlyRootFilesystem：将容器的根文件系统挂载为只读。

以上并非完整的安全上下文设置列表——请参阅 SecurityContext 获取完整列表。

准备工作

你需要有一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与你的集群通信。建议在至少有两个不充当控制平面主机的节点的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者使用以下 Kubernetes 试玩环境之一：

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

要检查版本，请输入 kubectl version。

设置 Pod 的安全上下文

要为 Pod 指定安全设置，请在 Pod 规范中包含 securityContext 字段。securityContext 字段是一个 PodSecurityContext 对象。你为 Pod 指定的安全设置适用于 Pod 中的所有容器。以下是一个包含 securityContext 和 emptyDir 卷的 Pod 的配置文件：

pods/security/security-context.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    supplementalGroups: [4000]
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

在配置文件中，runAsUser 字段指定 Pod 中所有容器的所有进程都以用户 ID 1000 运行。runAsGroup 字段指定 Pod 中所有容器内所有进程的主要组 ID 为 3000。如果省略此字段，容器的主要组 ID 将为 root(0)。当指定 runAsGroup 时，创建的任何文件也将由用户 1000 和组 3000 拥有。由于指定了 fsGroup 字段，容器的所有进程也是补充组 ID 2000 的一部分。卷 /data/demo 的所有者以及在该卷中创建的任何文件都将是组 ID 2000。此外，当指定 supplementalGroups 字段时，容器的所有进程也是指定组的一部分。如果省略此字段，则表示为空。

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml

验证 Pod 的容器是否正在运行

kubectl get pod security-context-demo

进入运行中的容器的 shell

kubectl exec -it security-context-demo -- sh

在你的 shell 中，列出正在运行的进程

ps

输出显示进程以用户 1000 运行，这是 runAsUser 的值。

PID   USER     TIME  COMMAND
    1 1000      0:00 sleep 1h
    6 1000      0:00 sh
...

在你的 shell 中，导航到 /data，并列出其中的一个目录

cd /data
ls -l

输出显示 /data/demo 目录的组 ID 为 2000，这是 fsGroup 的值。

drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo

在你的 shell 中，导航到 /data/demo，并创建一个文件

cd demo
echo hello > testfile

列出 /data/demo 目录中的文件

ls -l

输出显示 testfile 的组 ID 为 2000，这是 fsGroup 的值。

-rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile

运行以下命令：

id

输出类似于：

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

从输出中，你可以看到 gid 是 3000，与 runAsGroup 字段相同。如果 runAsGroup 被省略，gid 将保持为 0 (root)，并且进程将能够与 root(0) 组拥有的文件以及对 root (0) 组具有所需组权限的组进行交互。你还可以看到 groups 包含 fsGroup 和 supplementalGroups 指定的组 ID，以及 gid。

退出你的 shell

exit

容器镜像中 /etc/group 定义的隐含组成员资格

默认情况下，Kubernetes 会将 Pod 中的组信息与容器镜像中 /etc/group 中定义的信息合并。

pods/security/security-context-5.yaml

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

此 Pod 安全上下文包含 runAsUser、runAsGroup 和 supplementalGroups。但是，你可以看到附加到容器进程的实际补充组将包括来自容器镜像中 /etc/group 的组 ID。

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context-5.yaml

验证 Pod 的容器是否正在运行

kubectl get pod security-context-demo

进入运行中的容器的 shell

kubectl exec -it security-context-demo -- sh

检查进程身份

$ id

输出类似于：

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

你可以看到 groups 包含组 ID 50000。这是因为镜像中定义的用户 (uid=1000) 属于容器镜像中 /etc/group 中定义的组 (gid=50000)。

检查容器镜像中的 /etc/group

$ cat /etc/group

你可以看到 uid 1000 属于组 50000。

...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

退出你的 shell

exit

为 Pod 配置细粒度的补充组控制

此功能可以通过为 kubelet 和 kube-apiserver 设置 SupplementalGroupsPolicy 功能门控，并为 pod 设置 .spec.securityContext.supplementalGroupsPolicy 字段来启用。

supplementalGroupsPolicy 字段定义了用于计算 pod 中容器进程的补充组的策略。此字段有两个有效值：

• Merge：将合并容器主用户在 /etc/group 中定义的组成员资格。如果未指定，这是默认策略。

• Strict：只有 fsGroup、supplementalGroups 或 runAsGroup 字段中的组 ID 会作为容器进程的补充组附加。这意味着不会合并容器主用户在 /etc/group 中的任何组成员资格。

当该功能启用时，它还会将附加到第一个容器进程的进程身份暴露在 .status.containerStatuses[].user.linux 字段中。这对于检测是否附加了隐含的组 ID 会很有用。

pods/security/security-context-6.yaml

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

此 Pod 清单定义了 supplementalGroupsPolicy=Strict。你可以看到 /etc/group 中定义的组成员资格没有合并到容器进程的补充组中。

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context-6.yaml

验证 Pod 的容器是否正在运行

kubectl get pod security-context-demo

检查进程身份

kubectl exec -it security-context-demo -- id

输出类似于：

uid=1000 gid=3000 groups=3000,4000

查看 Pod 的状态

kubectl get pod security-context-demo -o yaml

你可以看到 status.containerStatuses[].user.linux 字段公开了附加到第一个容器进程的进程身份。

...
status:
  containerStatuses:
  - name: sec-ctx-demo
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

实现

已知以下容器运行时支持细粒度的补充组控制。

CRI 级别

• containerd，自 v2.0 起
• CRI-O，自 v1.31 起

你可以查看节点状态，判断该功能是否受支持。

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

apiVersion: v1
kind: Event
...
type: Warning
reason: SupplementalGroupsPolicyNotSupported
message: "SupplementalGroupsPolicy=Strict is not supported in this node"
involvedObject:
  apiVersion: v1
  kind: Pod
  ...

为 Pod 配置卷权限和所有权变更策略

默认情况下，当挂载卷时，Kubernetes 会递归地更改每个卷内容的权限和所有权，以匹配 Pod 的 securityContext 中指定的 fsGroup。对于大容量，检查和更改所有权和权限可能需要很长时间，从而减慢 Pod 启动。你可以使用 securityContext 中的 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷权限和所有权的方式。

fsGroupChangePolicy - fsGroupChangePolicy 定义了在将卷暴露到 Pod 内部之前更改卷所有权和权限的行为。此字段仅适用于支持 fsGroup 控制所有权和权限的卷类型。此字段有两个可能的值：

• OnRootMismatch：仅当根目录的权限和所有权与卷的预期权限不匹配时才更改权限和所有权。这有助于缩短更改卷所有权和权限所需的时间。
• Always：挂载卷时始终更改卷的权限和所有权。

例如

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

将卷权限和所有权更改委托给 CSI 驱动

如果你部署了一个支持 VOLUME_MOUNT_GROUP NodeServiceCapability 的 容器存储接口 (CSI) 驱动，那么根据 securityContext 中指定的 fsGroup 设置文件所有权和权限的过程将由 CSI 驱动执行，而不是 Kubernetes。在这种情况下，由于 Kubernetes 不执行任何所有权和权限更改，fsGroupChangePolicy 不生效。根据 CSI 规范，驱动程序应该使用提供的 fsGroup 挂载卷，从而使卷对 fsGroup 可读/写。

为容器设置安全上下文

要为容器指定安全设置，请在容器清单中包含 securityContext 字段。securityContext 字段是一个 SecurityContext 对象。你为容器指定的安全设置仅适用于单个容器，并且在重叠时会覆盖 Pod 级别的设置。容器设置不影响 Pod 的卷。

以下是包含一个容器的 Pod 的配置文件。Pod 和容器都具有 securityContext 字段：

pods/security/security-context-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

验证 Pod 的容器是否正在运行

kubectl get pod security-context-demo-2

进入运行中的容器的 shell

kubectl exec -it security-context-demo-2 -- sh

在你的 shell 中，列出正在运行的进程

ps aux

输出显示进程以用户 2000 运行。这是为容器指定的 runAsUser 的值。它会覆盖为 Pod 指定的值 1000。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
...

退出你的 shell

exit

为容器设置功能

使用 Linux 功能，你可以在不授予根用户所有特权的情况下，授予进程某些特权。要为容器添加或删除 Linux 功能，请在容器清单的 securityContext 部分包含 capabilities 字段。

首先，看看当你没有包含 capabilities 字段时会发生什么。以下是不添加或删除任何容器功能的配置文件：

pods/security/security-context-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-3
spec:
  containers:
  - name: sec-ctx-3
    image: gcr.io/google-samples/hello-app:2.0

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml

验证 Pod 的容器是否正在运行

kubectl get pod security-context-demo-3

进入运行中的容器的 shell

kubectl exec -it security-context-demo-3 -- sh

在你的 shell 中，列出正在运行的进程

ps aux

输出显示容器的进程 ID (PID)

USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js

在你的 shell 中，查看进程 1 的状态

cd /proc/1
cat status

输出显示了进程的功能位图

...
CapPrm:	00000000a80425fb
CapEff:	00000000a80425fb
...

记下功能位图，然后退出你的 shell

exit

接下来，运行一个与前一个容器相同，但设置了额外功能的容器。

以下是运行一个容器的 Pod 的配置文件。该配置添加了 CAP_NET_ADMIN 和 CAP_SYS_TIME 功能：

pods/security/security-context-4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

创建 Pod

kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml

进入运行中的容器的 shell

kubectl exec -it security-context-demo-4 -- sh

在你的 shell 中，查看进程 1 的功能

cd /proc/1
cat status

输出显示进程的功能位图

...
CapPrm:	00000000aa0435fb
CapEff:	00000000aa0435fb
...

比较两个容器的功能

00000000a80425fb
00000000aa0435fb

在第一个容器的功能位图中，位 12 和 25 是清除的。在第二个容器中，位 12 和 25 是设置的。位 12 是 CAP_NET_ADMIN，位 25 是 CAP_SYS_TIME。有关功能常量的定义，请参阅 capability.h。

为容器设置 Seccomp 配置文件

要为容器设置 Seccomp 配置文件，请在 Pod 或容器清单的 securityContext 部分中包含 seccompProfile 字段。seccompProfile 字段是一个 SeccompProfile 对象，由 type 和 localhostProfile 组成。type 的有效选项包括 RuntimeDefault、Unconfined 和 Localhost。localhostProfile 必须仅在 type: Localhost 时设置。它指示节点上预配置配置文件的路径，相对于 kubelet 配置的 Seccomp 配置文件位置（通过 --root-dir 标志配置）。

这是一个将 Seccomp 配置文件设置为节点容器运行时默认配置文件的示例：

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

这是一个将 Seccomp 配置文件设置为预配置文件 /seccomp/my-profiles/profile-allow.json 的示例：

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-profiles/profile-allow.json

为容器设置 AppArmor 配置文件

要为容器设置 AppArmor 配置文件，请在容器的 securityContext 部分中包含 appArmorProfile 字段。appArmorProfile 字段是一个 AppArmorProfile 对象，由 type 和 localhostProfile 组成。type 的有效选项包括 RuntimeDefault（默认）、Unconfined 和 Localhost。localhostProfile 必须仅在 type 为 Localhost 时设置。它指示节点上预配置配置文件的名称。该配置文件需要加载到所有适合 Pod 的节点上，因为你不知道 Pod 将被调度到哪里。设置自定义配置文件的方法在设置具有配置文件的节点中讨论。

注意：如果 containers[*].securityContext.appArmorProfile.type 显式设置为 RuntimeDefault，则如果节点上未启用 AppArmor，Pod 将不被允许。但是，如果未指定 containers[*].securityContext.appArmorProfile.type，则仅当节点上启用 AppArmor 时才应用默认值（也是 RuntimeDefault）。如果节点上禁用 AppArmor，Pod 将被允许，但容器将不受 RuntimeDefault 配置文件的限制。

这是一个将 AppArmor 配置文件设置为节点容器运行时默认配置文件的示例：

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: RuntimeDefault

这是一个将 AppArmor 配置文件设置为名为 k8s-apparmor-example-deny-write 的预配置文件的示例：

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write

有关更多详细信息，请参阅 使用 AppArmor 限制容器对资源的访问。

为容器分配 SELinux 标签

要为容器分配 SELinux 标签，请在 Pod 或容器清单的 securityContext 部分中包含 seLinuxOptions 字段。seLinuxOptions 字段是一个 SELinuxOptions 对象。这是一个应用 SELinux 级别的示例：

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

高效的 SELinux 卷重新标记

在禁用 SELinuxMount 功能门控（Kubernetes 1.33 和所有早期版本中的默认设置）的情况下，容器运行时默认递归地将 SELinux 标签分配给所有 Pod 卷上的所有文件。为了加快此过程，Kubernetes 可以通过使用挂载选项 -o context= 立即更改卷的 SELinux 标签。

要从这种加速中受益，必须满足所有这些条件：

• 必须启用 功能门控 SELinuxMountReadWriteOncePod。
• Pod 必须使用具有适用 accessModes 和 功能门控 的 PersistentVolumeClaim
  • 卷具有 accessModes: ["ReadWriteOncePod"]，并且功能门控 SELinuxMountReadWriteOncePod 已启用。
  • 或者，卷可以使用任何其他访问模式，并且所有功能门控 SELinuxMountReadWriteOncePod、SELinuxChangePolicy 和 SELinuxMount 都必须启用，并且 Pod 的 spec.securityContext.seLinuxChangePolicy 为 nil（默认）或 MountOption。
• Pod（或所有使用 PersistentVolumeClaim 的容器）必须设置 seLinuxOptions。
• 相应的 PersistentVolume 必须是以下之一：
  • 使用传统树内 iscsi、rbd 或 fc 卷类型的卷。
  • 或使用 CSI 驱动的卷。CSI 驱动必须通过在其 CSIDriver 实例中设置 spec.seLinuxMount: true 来声明它支持使用 -o context 进行挂载。

当这些条件中的任何一个不满足时，SELinux 重新标记将以另一种方式进行：容器运行时递归地更改卷中所有 inode（文件和目录）的 SELinux 标签。明确指出，这适用于 Kubernetes 临时卷（如 secret、configMap 和 projected），以及所有其 CSIDriver 实例未明确声明使用 -o context 进行挂载的卷。

当使用此加速时，在同一节点上同时使用相同适用卷的所有 Pod **必须具有相同的 SELinux 标签**。具有不同 SELinux 标签的 Pod 将无法启动，并将保持 ContainerCreating 状态，直到删除所有使用该卷的其他 SELinux 标签的 Pod。

SELinuxWarningController

为了更容易识别受 SELinux 卷重新标记更改影响的 Pod，kube-controller-manager 中引入了一个名为 SELinuxWarningController 的新控制器。它默认禁用，可以通过设置 --controllers=*,selinux-warning-controller 命令行标志 或通过在 KubeControllerManagerConfiguration 中设置 genericControllerManagerConfiguration.controllers 字段 来启用。此控制器需要启用 SELinuxChangePolicy 功能门控。

启用后，控制器会观察正在运行的 Pod，并在检测到两个 Pod 使用具有不同 SELinux 标签的相同卷时：

1. 它向两个 Pod 发出事件。kubectl describe pod 显示 SELinuxLabel "" 与使用相同卷的 Pod <其他 Pod 名称> 的 SELinuxLabel "<其他 Pod 标签>" 冲突。如果两个 Pod 都落在同一个节点上，则只有一个可以访问该卷。
2. 提高 selinux_warning_controller_selinux_volume_conflict 指标。该指标将 Pod 名称 + 命名空间作为标签，以便轻松识别受影响的 Pod。

集群管理员可以使用此信息来识别受计划更改影响的 Pod，并主动选择退出优化（即设置 spec.securityContext.seLinuxChangePolicy: Recursive）。

功能门控

以下功能门控控制 SELinux 卷重新标记的行为：

• SELinuxMountReadWriteOncePod：为具有 accessModes: ["ReadWriteOncePod"] 的卷启用优化。这是一个非常安全的功能门控，因为两个 Pod 无法使用这种访问模式共享一个卷。此功能门控自 v1.28 起默认启用。
• SELinuxChangePolicy：在 Pod 中启用 spec.securityContext.seLinuxChangePolicy 字段以及 kube-controller-manager 中相关的 SELinuxWarningController。此功能可以在启用 SELinuxMount 之前使用，以检查集群上运行的 Pod，并主动选择退出优化。此功能门控需要启用 SELinuxMountReadWriteOncePod。它在 1.33 中处于 Beta 阶段并默认启用。
• SELinuxMount 启用所有符合条件的卷的优化。由于它可能会破坏现有工作负载，我们建议首先启用 SELinuxChangePolicy 功能门控 + SELinuxWarningController 以检查更改的影响。此功能门控需要启用 SELinuxMountReadWriteOncePod 和 SELinuxChangePolicy。它处于 Beta 阶段，但在 1.33 中默认禁用。

管理对 /proc 文件系统的访问

对于遵循 OCI 运行时规范的运行时，容器默认以多种路径被掩盖且只读的模式运行。其结果是容器在容器的挂载命名空间中存在这些路径，它们的功能类似于容器是隔离主机，但容器进程无法写入它们。被掩盖和只读的路径列表如下：

• 被掩盖的路径

  • /proc/asound
  • /proc/acpi
  • /proc/kcore
  • /proc/keys
  • /proc/latency_stats
  • /proc/timer_list
  • /proc/timer_stats
  • /proc/sched_debug
  • /proc/scsi
  • /sys/firmware
  • /sys/devices/virtual/powercap

• 只读路径

  • /proc/bus
  • /proc/fs
  • /proc/irq
  • /proc/sys
  • /proc/sysrq-trigger

对于某些 Pod，你可能希望绕过路径的默认掩盖。最常见的情况是当你在 Kubernetes 容器（Pod 内）中运行容器时。

securityContext 字段 procMount 允许用户请求容器的 /proc 为 Unmasked，或由容器进程以读写方式挂载。这也适用于不在 /proc 中的 /sys/firmware。

...
securityContext:
  procMount: Unmasked

讨论

Pod 的安全上下文适用于 Pod 的容器，并在适用时也适用于 Pod 的卷。具体来说，fsGroup 和 seLinuxOptions 应用于卷，如下所示：

• fsGroup：支持所有权管理的卷会被修改，使其由 fsGroup 中指定的 GID 拥有且可写入。有关详细信息，请参阅 所有权管理设计文档。

• seLinuxOptions：支持 SELinux 标签的卷会被重新标记，以便由 seLinuxOptions 下指定的标签访问。通常你只需要设置 level 部分。这会设置分配给 Pod 中所有容器以及卷的 多类别安全 (MCS) 标签。

清理

删除 Pod

kubectl delete pod security-context-demo
kubectl delete pod security-context-demo-2
kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4

下一步

• PodSecurityContext
• SecurityContext
• CRI 插件配置指南
• 安全上下文设计文档
• 所有权管理设计文档
• PodSecurity 准入
• AllowPrivilegeEscalation 设计文档
• 有关 Linux 中安全机制的更多信息，请参阅 Linux 内核安全功能概述（注意：某些信息已过时）
• 阅读有关 Linux Pod 的 用户命名空间。
• OCI 运行时规范中的掩盖路径