为 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 之外,还包含 fsGroupsupplementalGroups 指定的组 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 安全上下文包含 runAsUserrunAsGroupsupplementalGroups。但是,您可以看到附加到容器进程的实际辅助组将包括来自容器镜像中 /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 配置细粒度的 SupplementalGroups 控制

功能状态: Kubernetes v1.31 [alpha](默认启用:false)

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

supplementalGroupsPolicy 字段定义用于计算 Pod 中容器进程的辅助组的策略。此字段有两个有效值:

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

  • Strict:仅将 fsGroupsupplementalGroupsrunAsGroup 字段中的组 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
...

实现

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

CRI 级别

你可以在节点状态中查看是否支持此功能。

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_ADMINCAP_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 常量的定义。

为容器设置 Seccomp 配置文件

要为容器设置 Seccomp 配置文件,请在你的 Pod 或容器清单的 securityContext 部分中包含 seccompProfile 字段。 seccompProfile 字段是一个 SeccompProfile 对象,由 typelocalhostProfile 组成。 type 的有效选项包括 RuntimeDefaultUnconfinedLocalhostlocalhostProfile 只有在 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 对象,由 typelocalhostProfile 组成。 type 的有效选项包括 RuntimeDefault(默认)、UnconfinedLocalhostlocalhostProfile 只有在 typeLocalhost 时才能设置。它指示节点上预配置的配置文件的名称。该配置文件需要加载到所有适合 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 卷重新标记

功能状态: Kubernetes v1.28 [测试版] (默认启用:true)

默认情况下,容器运行时会递归地将 SELinux 标签分配给所有 Pod 卷上的所有文件。为了加快此过程,Kubernetes 可以通过使用挂载选项 -o context=<label> 立即更改卷的 SELinux 标签。

要从此加速中获益,必须满足所有这些条件:

  • 必须启用 特性门控 ReadWriteOncePodSELinuxMountReadWriteOncePod
  • Pod 必须使用具有适用的 accessModes特性门控的 PersistentVolumeClaim
    • 卷具有 accessModes: ["ReadWriteOncePod"],并且启用了特性门控 SELinuxMountReadWriteOncePod
    • 或者,卷可以使用任何其他访问模式,并且必须启用特性门控 SELinuxMountReadWriteOncePodSELinuxChangePolicySELinuxMount,并且 Pod 的 spec.securityContext.seLinuxChangePolicy 为 nil(默认)或 MountOption
  • Pod(或所有使用 PersistentVolumeClaim 的容器)必须设置 seLinuxOptions
  • 对应的 PersistentVolume 必须是以下之一:
    • 使用旧的内置 iscsirbdfc 卷类型的卷。
    • 或者,使用 CSI 驱动程序的卷。CSI 驱动程序必须通过在其 CSIDriver 实例中设置 spec.seLinuxMount: true 来声明它支持使用 -o context 进行挂载。

对于任何其他卷类型,SELinux 重新标记会以另一种方式进行:容器运行时会递归地更改卷中所有 inode(文件和目录)的 SELinux 标签。

功能状态: Kubernetes v1.32 [alpha](默认禁用)
对于希望通过挂载选项选择不进行重新标记的 Pod,可以将 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 标签的同一卷时:

  1. 它会向两个 Pod 发出事件。kubectl describe pod <pod-name> 显示 SELinuxLabel "<pod 上的标签>" 与 pod <另一个 pod 名称> 冲突,后者使用与此 pod 相同的卷,其 SELinuxLabel 为 "<另一个 pod 的标签>"。如果两个 pod 落在同一节点上,则只有一个 pod 可以访问该卷
  2. 提升 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 以检查更改的影响。此功能门需要启用 SELinuxMountReadWriteOncePodSELinuxChangePolicy。在 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 允许用户请求容器的 /procUnmasked,或者由容器进程以读写方式挂载。这也适用于不在 /proc 中的 /sys/firmware

...
securityContext:
  procMount: Unmasked

讨论

Pod 的安全上下文适用于 Pod 的容器,也适用于 Pod 的卷(如果适用)。具体来说,fsGroupseLinuxOptions 按如下方式应用于卷:

  • 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

下一步

此页面上的项目引用了提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不负责这些第三方产品或项目。有关更多详细信息,请参阅 CNCF 网站指南

在提出添加额外第三方链接的更改之前,您应该阅读内容指南

上次修改时间:2024 年 11 月 19 日,太平洋标准时间上午 10:03:提及 MountOption 作为默认值 (8e17234d93)