為 Pod 或 Container 設定安全環境

安全環境定義 Pod 或 Container 的權限和存取控制設定。安全環境設定包括但不限於

• 自主存取控制：存取物件 (例如檔案) 的權限基於使用者 ID (UID) 和群組 ID (GID)。

• 安全增強型 Linux (SELinux)：物件會指派安全標籤。

• 以特權或非特權身分執行。

• Linux Capabilities：授予程序一些權限，但並非 root 使用者的所有權限。

• AppArmor：使用程式設定檔來限制個別程式的功能。

• Seccomp：過濾程序的系統呼叫。

• allowPrivilegeEscalation：控制程序是否可以獲得比其父程序更多的權限。此布林值直接控制是否在容器程序上設定 no_new_privs 旗標。當容器為下列情況時，allowPrivilegeEscalation 始終為 true

  • 以特權身分執行，或
  • 具有 CAP_SYS_ADMIN

• readOnlyRootFilesystem：將容器的根檔案系統掛載為唯讀。

以上項目並非安全環境設定的完整集合 - 請參閱 SecurityContext 以取得完整清單。

準備開始

您需要有一個 Kubernetes 叢集，並且必須將 kubectl 命令列工具設定為與您的叢集通訊。建議在至少有兩個非充當控制平面主機的節點的叢集上執行本教學課程。如果您還沒有叢集，可以使用 minikube 建立一個叢集，或者您可以使用下列 Kubernetes 實驗環境之一

• Killercoda
• Play with Kubernetes

設定 Pod 的安全環境

若要為 Pod 指定安全設定，請在 Pod 規格中包含 securityContext 欄位。securityContext 欄位是 PodSecurityContext 物件。您為 Pod 指定的安全設定會套用至 Pod 中的所有 Container。以下是具有 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 中任何 Container 的所有程序都以使用者 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 的 Container 是否正在執行

kubectl get pod security-context-demo

取得執行中 Container 的 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 中定義的資訊合併。

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 的 Container 是否正在執行

kubectl get pod security-context-demo

取得執行中 Container 的 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 控制

可以透過為 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 的 Container 是否正在執行

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 層級

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

您可以查看節點狀態中是否支援此功能。

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

為 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 的 Container 是否正在執行

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 功能，您可以授予程序某些權限，而無需授予 root 使用者的所有權限。若要為容器新增或移除 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 的 Container 是否正在執行

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 bitmap

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

記下 capabilities bitmap，然後離開您的 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

輸出顯示程序的 capabilities bitmap

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

比較兩個容器的功能

00000000a80425fb
00000000aa0435fb

在第一個容器的 capabilities bitmap 中，位元 12 和 25 已清除。在第二個容器中，位元 12 和 25 已設定。位元 12 是 CAP_NET_ADMIN，位元 25 是 CAP_SYS_TIME。請參閱 capability.h 以取得功能常數的定義。

為容器設定 Seccomp Profile

若要為容器設定 Seccomp profile，請在 Pod 或容器清單檔的 securityContext 區段中包含 seccompProfile 欄位。seccompProfile 欄位是一個 SeccompProfile 物件，由 type 和 localhostProfile 組成。type 的有效選項包括 RuntimeDefault、Unconfined 和 Localhost。只有在 type: Localhost 時，才必須設定 localhostProfile。它指示節點上預先設定的 profile 路徑，相對於 kubelet 設定的 Seccomp profile 位置（使用 --root-dir 標誌設定）。

以下範例將 Seccomp profile 設定為節點的容器執行階段預設 profile

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

以下範例將 Seccomp profile 設定為 <kubelet-root-dir>/seccomp/my-profiles/profile-allow.json 的預先設定檔案

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

為容器設定 AppArmor Profile

若要為容器設定 AppArmor profile，請在容器的 securityContext 區段中包含 appArmorProfile 欄位。appArmorProfile 欄位是一個 AppArmorProfile 物件，由 type 和 localhostProfile 組成。type 的有效選項包括 RuntimeDefault（預設）、Unconfined 和 Localhost。只有當 type 為 Localhost 時，才必須設定 localhostProfile。它指示節點上預先設定的 profile 名稱。profile 需要載入到所有適合 Pod 的節點上，因為您不知道 Pod 將排程到哪裡。設定自訂 profile 的方法在 使用 Profile 設定節點 中討論。

注意：如果明確將 containers[*].securityContext.appArmorProfile.type 設定為 RuntimeDefault，則如果節點上未啟用 AppArmor，則 Pod 將不會被允許進入。但是，如果未指定 containers[*].securityContext.appArmorProfile.type，則只有在節點已啟用 AppArmor 的情況下，才會套用預設值（也是 RuntimeDefault）。如果節點已停用 AppArmor，則 Pod 將被允許進入，但容器將不受 RuntimeDefault profile 的限制。

以下範例將 AppArmor profile 設定為節點的容器執行階段預設 profile

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

以下範例將 AppArmor profile 設定為名為 k8s-apparmor-example-deny-write 的預先設定 profile

...
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 標籤指派給所有 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 標籤。

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 "<label on the pod>" conflicts with pod <the other pod name> that uses the same volume as this pod with SELinuxLabel "<the other pod label>". If both pods land on the same node, only one of them may access the volume。
2. 提高 selinux_warning_controller_selinux_volume_conflict 度量。該度量同時具有 Pod 名稱和命名空間作為標籤，以便輕鬆識別受影響的 Pod。

叢集管理員可以使用此資訊來識別受規劃變更影響的 Pod，並主動選擇讓 Pod 不進行最佳化（即設定 spec.securityContext.seLinuxChangePolicy: Recursive）。

功能閘道

以下功能閘道控制 SELinux 磁碟區重新標籤的行為

• SELinuxMountReadWriteOncePod：為具有 accessModes: ["ReadWriteOncePod"] 的磁碟區啟用最佳化。這是一個非常安全的功能閘道，可以啟用，因為不可能有兩個 Pod 可以共用一個具有此存取模式的單一磁碟區。此功能閘道自 v1.28 起預設啟用。
• SELinuxChangePolicy：在 Pod 和 kube-controller-manager 中的相關 SELinuxWarningController 中啟用 spec.securityContext.seLinuxChangePolicy 欄位。可以在啟用 SELinuxMount 之前使用此功能來檢查叢集上執行的 Pod，並主動選擇讓 Pod 不進行最佳化。此功能閘道需要啟用 SELinuxMountReadWriteOncePod。它是 Alpha 版，在 1.32 中預設停用。
• SELinuxMount 為所有符合條件的磁碟區啟用最佳化。由於它可能會破壞現有的工作負載，因此我們建議先啟用 SELinuxChangePolicy 功能閘道 + SELinuxWarningController，以檢查變更的影響。此功能閘道需要啟用 SELinuxMountReadWriteOncePod 和 SELinuxChangePolicy。它是 Alpha 版，在 1.32 中預設停用。

管理對 /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 Admission
• AllowPrivilegeEscalation 設計文件
• 如需 Linux 中安全性機制的更多資訊，請參閱 Linux 核心安全性功能概述（注意：某些資訊已過時）
• 閱讀關於 Linux Pod 的 使用者命名空間。
• OCI 執行階段規格中的遮罩路徑