Pod 和容器的 Linux 核心安全約束
本頁描述了 Linux 核心中一些內建的安全功能，你可以在 Kubernetes 工作負載中使用這些功能。要了解如何將這些功能應用於你的 Pod 和容器，請參閱為 Pod 或容器配置 SecurityContext。你應該已經熟悉 Linux 和 Kubernetes 工作負載的基礎知識。
以非 root 許可權執行工作負載
當你在 Kubernetes 中部署工作負載時，可以使用 Pod 規約來限制該工作負載作為節點的 root 使用者執行。你可以使用 Pod 的 `securityContext` 來為 Pod 中的程序定義特定的 Linux 使用者和組，並明確限制容器作為 root 使用者執行。在 Pod 清單中設定這些值優先於容器映象中的類似值，這在執行非你擁有的映象時特別有用。
注意
確保你分配給工作負載的使用者或組具有應用程式正常執行所需的許可權。將使用者或組更改為不具有正確許可權的使用者或組可能會導致檔案訪問問題或操作失敗。配置本頁中的核心安全功能可以對叢集中程序可以採取的操作進行細粒度控制，但大規模管理這些配置可能具有挑戰性。以非 root 身份執行容器，或者如果需要 root 許可權，則在使用者名稱空間中執行容器，有助於減少需要強制執行已配置的核心安全功能的可能性。
Linux 核心中的安全功能
Kubernetes 允許你配置和使用 Linux 核心功能來改進隔離並增強容器化工作負載的安全性。常見功能包括：
- 安全計算模式 (seccomp)：過濾程序可以進行的系統呼叫
- AppArmor：限制單個程式的訪問許可權
- Security Enhanced Linux (SELinux)：為物件分配安全標籤，以便更易於管理安全策略強制執行
要配置其中一項功能的設定，你為節點選擇的作業系統必須在核心中啟用該功能。例如，Ubuntu 7.10 及更高版本預設啟用 AppArmor。要了解你的作業系統是否啟用了特定功能，請查閱作業系統文件。
你使用 Pod 規約中的 `securityContext` 欄位來定義適用於這些程序的約束。`securityContext` 欄位還支援其他安全設定，例如使用 UID 和 GID 的特定 Linux 功能或檔案訪問許可權。要了解更多資訊，請參閱為 Pod 或容器配置 SecurityContext。
seccomp
你的一些工作負載可能需要特權才能在節點的宿主機上作為 root 使用者執行特定操作。Linux 使用*權能（capabilities）*將可用特權劃分為多個類別，以便程序可以獲得執行特定操作所需的特權，而無需授予所有特權。每個權能都有一組程序可以進行的系統呼叫（syscalls）。seccomp 允許你限制這些單獨的系統呼叫。它可用於沙盒化程序的特權，限制它從使用者空間到核心的呼叫能力。
在 Kubernetes 中，你使用每個節點上的*容器執行時*來執行你的容器。示例執行時包括 CRI-O、Docker 或 containerd。每個執行時預設只允許 Linux 權能的一個子集。你可以透過使用 seccomp 配置檔案進一步單獨限制允許的系統呼叫。容器執行時通常包含一個預設的 seccomp 配置檔案。Kubernetes 允許你自動將載入到節點上的 seccomp 配置檔案應用於你的 Pod 和容器。
注意
Kubernetes 還為 Pod 和容器提供了 `allowPrivilegeEscalation` 設定。當設定為 `false` 時，這將阻止程序獲得新的權能，並限制非特權使用者將應用的 seccomp 配置檔案更改為更寬鬆的配置檔案。要了解如何在 Kubernetes 中實現 seccomp，請參閱使用 seccomp 限制容器的系統呼叫或Seccomp 節點參考。
要了解有關 seccomp 的更多資訊，請參閱 Linux 核心文件中的Seccomp BPF。
seccomp 的注意事項
seccomp 是一種低階安全配置，只有在你需要對 Linux 系統呼叫進行細粒度控制時才應自行配置。大規模使用 seccomp，尤其是在以下方面存在風險：
- 配置可能在應用程式更新期間中斷
- 攻擊者仍然可以使用允許的系統呼叫來利用漏洞
- 大規模地管理單個應用程式的配置檔案變得具有挑戰性
建議：使用容器執行時捆綁的預設 seccomp 配置檔案。如果需要更隔離的環境，請考慮使用沙盒，例如 gVisor。沙盒解決了上述使用自定義 seccomp 配置檔案帶來的風險，但需要節點上更多的計算資源，並且可能與 GPU 和其他專用硬體存在相容性問題。
AppArmor 和 SELinux：基於策略的強制訪問控制
你可以使用 Linux 基於策略的強制訪問控制 (MAC) 機制（例如 AppArmor 和 SELinux）來增強你的 Kubernetes 工作負載。
AppArmor
AppArmor 是一個 Linux 核心安全模組，它補充了標準的基於 Linux 使用者和組的許可權，以將程式限制在有限的資源集內。AppArmor 可以為任何應用程式配置，以減少其潛在的攻擊面並提供更深入的防禦。它透過配置檔案進行配置，這些配置檔案經過調整以允許特定程式或容器所需的訪問許可權，例如 Linux 功能、網路訪問和檔案許可權。每個配置檔案可以以強制模式執行，該模式阻止對不允許的資源的訪問，或者以抱怨模式執行，該模式只報告違規。
AppArmor 可以透過限制容器可以做什麼和/或透過系統日誌提供更好的審計來幫助你執行更安全的部署。你使用的容器執行時可能附帶一個預設的 AppArmor 配置檔案，或者你可以使用自定義配置檔案。
要了解如何在 Kubernetes 中使用 AppArmor，請參閱使用 AppArmor 限制容器對資源的訪問。
SELinux
SELinux 是一個 Linux 核心安全模組，它允許你限制特定*主體*（例如程序）對系統上檔案的訪問。你定義適用於具有特定 SELinux 標籤的主體的安全策略。當具有 SELinux 標籤的程序嘗試訪問檔案時，SELinux 伺服器會檢查該程序的安全策略是否允許該訪問並做出授權決定。
在 Kubernetes 中，你可以在清單的 `securityContext` 欄位中設定 SELinux 標籤。指定的標籤將分配給這些程序。如果你已配置影響這些標籤的安全策略，則宿主作業系統核心會強制執行這些策略。
要了解如何在 Kubernetes 中使用 SELinux，請參閱為容器分配 SELinux 標籤。
AppArmor 和 SELinux 之間的區別
你的 Linux 節點上的作業系統通常包含 AppArmor 或 SELinux 之一。這兩種機制提供類似型別的保護，但存在以下差異：
- 配置：AppArmor 使用配置檔案來定義對資源的訪問。SELinux 使用適用於特定標籤的策略。
- 策略應用：在 AppArmor 中，你使用檔案路徑定義資源。SELinux 使用資源的索引節點 (inode) 來標識資源。
功能摘要
下表描述了每個安全控制的用例和範圍。你可以將所有這些控制結合使用以構建更強大的系統。
| 安全功能 | 描述 | 如何使用 | 示例 |
|---|---|---|---|
| seccomp | 限制使用者空間中的單個核心呼叫。降低利用受限系統呼叫的漏洞危及系統的可能性。 | 在 Pod 或容器規約中指定已載入的 seccomp 配置檔案，以將其約束應用於 Pod 中的程序。 | 拒絕 `unshare` 系統呼叫，該系統呼叫曾用於 CVE-2022-0185。 |
| AppArmor | 限制程式對特定資源的訪問。減少程式的攻擊面。改進審計日誌記錄。 | 在容器規約中指定已載入的 AppArmor 配置檔案。 | 限制只讀程式寫入系統中任何檔案路徑。 |
| SELinux | 使用標籤和安全策略限制對檔案、應用程式、埠和程序等資源的訪問。 | 為特定標籤指定訪問限制。用這些標籤標記程序以強制執行與標籤相關的訪問限制。 | 限制容器訪問其自身檔案系統之外的檔案。 |
注意
AppArmor 和 SELinux 等機制可以提供超出容器範圍的保護。例如，你可以使用 SELinux 來幫助緩解 CVE-2019-5736。管理自定義配置的注意事項
seccomp、AppArmor 和 SELinux 通常具有提供基本保護的預設配置。你還可以建立滿足工作負載要求的自定義配置檔案和策略。大規模管理和分發這些自定義配置可能具有挑戰性，尤其是當你同時使用所有這三個功能時。為了幫助你大規模管理這些配置，請使用 Kubernetes 安全配置檔案運算子 等工具。
核心級安全功能和特權容器
Kubernetes 允許你指定一些受信任的容器可以在*特權*模式下執行。Pod 中的任何容器都可以在特權模式下執行，以使用通常無法訪問的作業系統管理功能。這適用於 Windows 和 Linux。
特權容器明確覆蓋你可能在工作負載中使用的某些 Linux 核心約束，如下所示：
- seccomp：特權容器以 `Unconfined` seccomp 配置檔案執行，覆蓋你在清單中指定的任何 seccomp 配置檔案。
- AppArmor：特權容器忽略任何應用的 AppArmor 配置檔案。
- SELinux：特權容器以 `unconfined_t` 域執行。
特權容器
如果將容器的 `securityContext` 欄位中的 `privileged: true` 欄位設定為 true，則 Pod 中的任何容器都可以啟用*特權模式*。特權容器會覆蓋或撤銷許多其他強化設定，例如應用的 seccomp 配置檔案、AppArmor 配置檔案或 SELinux 約束。特權容器被賦予所有 Linux 功能，包括它們不需要的功能。例如，特權容器中的 root 使用者可能能夠使用節點上的 `CAP_SYS_ADMIN` 和 `CAP_NET_ADMIN` 功能，從而繞過執行時 seccomp 配置和其他限制。
在大多數情況下，你應該避免使用特權容器，而應使用 `securityContext` 欄位中的 `capabilities` 欄位授予容器所需的特定能力。僅當你有無法透過 securityContext 授予的功能時才使用特權模式。這對於需要使用作業系統管理功能（例如操作網路堆疊或訪問硬體裝置）的容器非常有用。
在 Kubernetes 1.26 及更高版本中，你還可以透過在 Pod 規約的 security context 中設定 `windowsOptions.hostProcess` 標誌，以類似特權模式執行 Windows 容器。有關詳細資訊和說明，請參閱建立 Windows HostProcess Pod。
建議和最佳實踐
- 在配置核心級安全功能之前，你應該考慮實現網路級隔離。有關更多資訊，請閱讀安全清單。
- 除非必要，否則透過在 Pod 清單中設定特定的使用者和組 ID 並指定 `runAsNonRoot: true`，將 Linux 工作負載作為非 root 使用者執行。
此外，你可以透過在 Pod 清單中設定 `hostUsers: false` 來在使用者名稱空間中執行工作負載。這允許你作為使用者名稱空間中的 root 使用者執行容器，但作為節點上宿主名稱空間中的非 root 使用者執行容器。這仍處於開發的早期階段，可能不具備你所需的支援級別。有關說明，請參閱使用 Pod 的使用者名稱空間。