为 Pod 或容器配置安全上下文
安全上下文定义 Pod 或容器的特权和访问控制设置。安全上下文设置包括但不限于:
自主访问控制:访问对象(如文件)的权限基于 用户 ID (UID) 和组 ID (GID)。
安全增强型 Linux (SELinux):对象被分配安全标签。
以特权或非特权方式运行。
Linux 能力:为进程提供一些特权,但不是 root 用户的所有特权。
AppArmor:使用程序配置文件来限制各个程序的功能。
Seccomp:过滤进程的系统调用。
allowPrivilegeEscalation
:控制进程是否可以获得比其父进程更多的特权。此布尔值直接控制是否在容器进程上设置no_new_privs
标志。当容器满足以下条件时,allowPrivilegeEscalation
始终为 true:- 以特权方式运行,或
- 具有
CAP_SYS_ADMIN
。
readOnlyRootFilesystem
:将容器的根文件系统挂载为只读。
以上项目并非安全上下文设置的完整列表,请参阅 SecurityContext 获取完整列表。
准备开始
您需要有一个 Kubernetes 集群,并且必须配置 kubectl 命令行工具以与您的集群通信。建议在至少具有两个不充当控制平面主机的节点的集群上运行本教程。如果您还没有集群,可以使用 minikube 创建一个,或者可以使用以下 Kubernetes 游乐场之一:
要检查版本,请输入kubectl version
。设置 Pod 的安全上下文
要为 Pod 指定安全设置,请在 Pod 规范中包含 securityContext
字段。securityContext
字段是一个 PodSecurityContext 对象。您为 Pod 指定的安全设置适用于 Pod 中的所有容器。以下是一个 Pod 的配置文件,其中包含 securityContext
和一个 emptyDir
卷:
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
除了 gid
之外,还包含 fsGroup
和 supplementalGroups
指定的组 ID。
退出您的 Shell
exit
在容器镜像中的 /etc/group
中定义的隐式组成员资格
默认情况下,Kubernetes 将 Pod 中的组信息与容器镜像中的 /etc/group
中定义的信息合并。
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
注意
隐式合并的辅助组可能会导致安全问题,尤其是在访问卷时(有关详细信息,请参阅 kubernetes/kubernetes#112879)。如果您想避免这种情况,请参阅以下部分。为 Pod 配置细粒度的 SupplementalGroups 控制
Kubernetes v1.31 [alpha]
(默认启用:false)可以通过为 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。
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
...
注意
请注意,status.containerStatuses[].user.linux
字段中的值是附加到容器中第一个容器进程的第一个进程标识。如果容器具有足够的权限来执行与进程标识相关的系统调用(例如,setuid(2)
、setgid(2)
或 setgroups(2)
等),则容器进程可以更改其标识。因此,实际进程标识将是动态的。实现
已知以下容器运行时支持细粒度的 SupplementalGroups 控制。
CRI 级别
- containerd, 从 v2.0 开始
- CRI-O, 从 v1.31 开始
你可以在节点状态中查看是否支持此功能。
apiVersion: v1
kind: Node
...
status:
features:
supplementalGroupsPolicy: true
配置 Pod 的卷权限和所有权更改策略
Kubernetes v1.23 [稳定]
默认情况下,当挂载卷时,Kubernetes 会递归地更改每个卷内容的所属权和权限,以匹配 Pod 的 securityContext
中指定的 fsGroup
。对于大型卷,检查和更改所有权和权限可能需要很长时间,从而减慢 Pod 的启动速度。你可以使用 securityContext
中的 fsGroupChangePolicy
字段来控制 Kubernetes 检查和管理卷的所有权和权限的方式。
fsGroupChangePolicy - fsGroupChangePolicy
定义了在 Pod 内公开卷之前更改卷的所有权和权限的行为。此字段仅适用于支持 fsGroup
控制的所有权和权限的卷类型。此字段有两个可能的值:
- OnRootMismatch:仅当根目录的权限和所有权与卷的预期权限不匹配时,才更改权限和所有权。这有助于缩短更改卷的所有权和权限所需的时间。
- Always:始终在挂载卷时更改卷的权限和所有权。
例如:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
fsGroupChangePolicy: "OnRootMismatch"
将卷权限和所有权更改委托给 CSI 驱动程序
Kubernetes v1.26 [稳定]
如果你部署了一个支持 VOLUME_MOUNT_GROUP
NodeServiceCapability
的 容器存储接口 (CSI) 驱动程序,则基于 securityContext
中指定的 fsGroup
设置文件所有权和权限的过程将由 CSI 驱动程序而不是 Kubernetes 执行。在这种情况下,由于 Kubernetes 不执行任何所有权和权限更改,fsGroupChangePolicy
不会生效,并且按照 CSI 的规定,驱动程序应使用提供的 fsGroup
挂载卷,从而使卷可由 fsGroup
读取/写入。
为容器设置安全上下文
要为容器指定安全设置,请在容器清单中包含 securityContext
字段。 securityContext
字段是一个 SecurityContext 对象。你为容器指定的安全设置仅适用于单个容器,并且当存在重叠时,它们会覆盖在 Pod 级别进行的设置。容器设置不会影响 Pod 的卷。
这是包含一个容器的 Pod 的配置文件。Pod 和容器都有一个 securityContext
字段
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 capabilities,你可以向进程授予某些特权,而无需授予 root 用户的所有特权。要为容器添加或删除 Linux capabilities,请在容器清单的 securityContext
部分中包含 capabilities
字段。
首先,查看不包含 capabilities
字段时会发生什么。这是不添加或删除任何容器 capabilities 的配置文件
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
输出显示该进程的 capabilities 位图
...
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
...
记下 capabilities 位图,然后退出 shell
exit
接下来,运行一个与前一个容器相同的容器,只不过它设置了额外的 capabilities。
这是运行一个容器的 Pod 的配置文件。该配置添加了 CAP_NET_ADMIN
和 CAP_SYS_TIME
capabilities
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 的 capabilities
cd /proc/1
cat status
输出显示该进程的 capabilities 位图
...
CapPrm: 00000000aa0435fb
CapEff: 00000000aa0435fb
...
比较两个容器的 capabilities
00000000a80425fb
00000000aa0435fb
在第一个容器的 capability 位图中,位 12 和 25 是清除的。在第二个容器中,位 12 和 25 已设置。位 12 是 CAP_NET_ADMIN
,位 25 是 CAP_SYS_TIME
。请参阅 capability.h,了解 capability 常量的定义。
注意
Linux capability 常量的形式为CAP_XXX
。但是,当你在容器清单中列出 capabilities 时,必须省略常量的 CAP_
部分。例如,要添加 CAP_SYS_TIME
,请在你的 capabilities 列表中包含 SYS_TIME
。为容器设置 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 配置文件设置为位于 <kubelet-root-dir>/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 标签,必须在主机操作系统上加载 SELinux 安全模块。高效的 SELinux 卷重新标记
Kubernetes v1.28 [测试版]
(默认启用:true)注意
Kubernetes v1.27 引入了这种行为的早期有限形式,仅适用于使用 ReadWriteOncePod
访问模式的卷(和 PersistentVolumeClaims)。
作为一项 alpha 功能,你可以启用 SELinuxMount
和 SELinuxChangePolicy
特性门控,以将性能改进扩大到其他类型的 PersistentVolumeClaims,如下面详细解释的那样。
默认情况下,容器运行时会递归地将 SELinux 标签分配给所有 Pod 卷上的所有文件。为了加快此过程,Kubernetes 可以通过使用挂载选项 -o context=<label>
立即更改卷的 SELinux 标签。
要从此加速中获益,必须满足所有这些条件:
- 必须启用 特性门控
ReadWriteOncePod
和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 v1.32 [alpha]
(默认禁用)spec.securityContext.seLinuxChangePolicy
设置为 Recursive
。当多个 Pod 在同一节点上共享一个卷,但它们以不同的 SELinux 标签运行时,需要这样做,以便同时访问该卷。例如,一个以 spc_t
标签运行的特权 Pod 和一个以默认标签 container_file_t
运行的非特权 Pod。如果不设置 spec.securityContext.seLinuxChangePolicy
(或使用默认值 MountOption
),则只有一个这样的 Pod 能够在节点上运行,另一个 Pod 会出现 ContainerCreating 错误,并显示 conflicting SELinux labels of volume <卷名称>: <正在运行的 Pod 的标签> and <无法启动的 Pod 的标签>
。SELinuxWarningController
为了更容易识别受 SELinux 卷重新标记更改影响的 Pod,kube-controller-manager 中引入了一个名为 SELinuxWarningController
的新控制器。默认情况下禁用此控制器,可以通过设置 --controllers=*,selinux-warning-controller
命令行标志,或在 KubeControllerManagerConfiguration
中设置 genericControllerManagerConfiguration.controllers
字段来启用此控制器。此控制器需要启用 SELinuxChangePolicy
功能门。
启用后,该控制器会观察正在运行的 Pod,当它检测到两个 Pod 使用具有不同 SELinux 标签的同一卷时:
- 它会向两个 Pod 发出事件。
kubectl describe pod <pod-name>
显示SELinuxLabel "<pod 上的标签>" 与 pod <另一个 pod 名称> 冲突,后者使用与此 pod 相同的卷,其 SELinuxLabel 为 "<另一个 pod 的标签>"。如果两个 pod 落在同一节点上,则只有一个 pod 可以访问该卷
。 - 提升
selinux_warning_controller_selinux_volume_conflict
指标。该指标包含 pod 名称和命名空间作为标签,以便轻松识别受影响的 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,并主动使 Pod 不进行优化。此功能门需要启用SELinuxMountReadWriteOncePod
。在 1.32 版本中,它是 alpha 版本,默认禁用。SELinuxMount
为所有符合条件的卷启用优化。由于它可能会破坏现有工作负载,我们建议首先启用SELinuxChangePolicy
功能门 + SELinuxWarningController 以检查更改的影响。此功能门需要启用SELinuxMountReadWriteOncePod
和SELinuxChangePolicy
。在 1.32 版本中,它是 alpha 版本,默认禁用。
管理对 /proc
文件系统的访问
Kubernetes v1.31 [beta]
(默认禁用)对于遵循 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
注意
将procMount
设置为 Unmasked 需要 pod 规范中的 spec.hostUsers
值为 false
。换句话说:希望拥有 Unmasked /proc
或 Unmasked /sys
的容器也必须位于用户命名空间中。Kubernetes v1.12 到 v1.29 没有强制执行此要求。讨论
Pod 的安全上下文适用于 Pod 的容器,也适用于 Pod 的卷(如果适用)。具体来说,fsGroup
和 seLinuxOptions
按如下方式应用于卷:
fsGroup
:支持所有权管理的卷会被修改为由fsGroup
中指定的 GID 所有和可写。有关更多详细信息,请参阅 所有权管理设计文档。seLinuxOptions
:支持 SELinux 标签的卷会被重新标记,以便可以通过seLinuxOptions
下指定的标签访问。通常您只需要设置level
部分。这将设置赋予 Pod 中所有容器以及卷的 多类别安全 (MCS) 标签。
警告
在您为 Pod 指定 MCS 标签后,所有具有相同标签的 Pod 都可以访问该卷。如果需要 Pod 间保护,则必须为每个 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 运行时规范中的屏蔽路径
此页面上的项目引用了提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不负责这些第三方产品或项目。有关更多详细信息,请参阅 CNCF 网站指南。
在提出添加额外第三方链接的更改之前,您应该阅读内容指南。