安全清單
此檢查清單旨在提供基本指南列表，並附帶指向每個主題的更全面文件的連結。它不聲稱詳盡無遺，並且旨在不斷發展。
如何閱讀和使用此文件
- 主題的順序不反映優先順序順序。
- 某些檢查清單專案在每個部分列表下面的段落中進行了詳細說明。
注意
僅憑檢查清單不足以實現良好的安全狀況。良好的安全狀況需要持續的關注和改進，但檢查清單可以是通往永無止境的安全準備之旅的第一步。此檢查清單中的某些建議可能對你的特定安全需求來說過於嚴格或過於寬鬆。由於 Kubernetes 安全不是“一刀切”的，因此應根據其優點評估每個類別的檢查清單專案。認證與授權
-
system:masters組在引導後不用於使用者或元件認證。 - kube-controller-manager 啟用了
--use-service-account-credentials執行。 - 根證書受到保護（要麼是離線 CA，要麼是具有有效訪問控制的託管線上 CA）。
- 中間證書和葉證書的有效期不超過未來 3 年。
- 存在定期訪問審查流程，且審查間隔不超過 24 個月。
- 遵循 基於角色的訪問控制最佳實踐 以獲取與認證和授權相關的指導。
在引導之後，使用者和元件都不應以 system:masters 身份對 Kubernetes API 進行認證。同樣，應避免將所有 kube-controller-manager 以 system:masters 身份執行。實際上，system:masters 應僅用作緊急機制，而不是管理員使用者。
網路安全
- 使用的 CNI 外掛支援網路策略。
- 入站和出站網路策略應用於叢集中的所有工作負載。
- 每個名稱空間中都存在預設網路策略，選擇所有 Pod，拒絕所有操作。
- 如果合適，使用服務網格來加密叢集內的所有通訊。
- Kubernetes API、kubelet API 和 etcd 不在 Internet 上公開暴露。
- 從工作負載到雲元資料 API 的訪問受到過濾。
- 限制 LoadBalancer 和 ExternalIPs 的使用。
許多 容器網路介面 (CNI) 外掛 提供了限制 Pod 可以通訊的網路資源的功能。這通常透過 網路策略 來實現，網路策略提供了一個名稱空間資源來定義規則。在每個名稱空間中，選擇所有 Pod 的預設網路策略（阻止所有出站和入站流量）有助於採用白名單方法，以確保沒有遺漏任何工作負載。
並非所有 CNI 外掛都提供傳輸中加密。如果所選外掛缺少此功能，替代解決方案可能是使用服務網格來提供該功能。
控制平面的 etcd 資料儲存應具有限制訪問的控制，並且不應在 Internet 上公開暴露。此外，應使用相互 TLS (mTLS) 進行安全通訊。此證書頒發機構應是 etcd 獨有的。
對 Kubernetes API 伺服器的外部 Internet 訪問應受到限制，以免公開暴露 API。請注意，許多託管 Kubernetes 發行版預設會公開暴露 API 伺服器。然後你可以使用堡壘主機訪問伺服器。
kubelet API 訪問應受到限制，不應公開暴露，當未透過 --config 標誌指定配置檔案時，預設的認證和授權設定過於寬鬆。
如果使用雲提供商託管 Kubernetes，則 Pod 對雲元資料 API 169.254.169.254 的訪問也應受到限制或阻止（如果不需要），因為它可能會洩露資訊。
有關 LoadBalancer 和 ExternalIPs 使用限制的更多資訊，請參閱 CVE-2020-8554: 使用 LoadBalancer 或 ExternalIPs 進行中間人攻擊 和 DenyServiceExternalIPs 准入控制器。
Pod 安全
- 只有在必要時才授予對工作負載進行
create、update、patch、delete的 RBAC 許可權。 - 所有名稱空間都應用並強制執行適當的 Pod 安全標準策略。
- 為工作負載設定記憶體限制，且限制等於或低於請求。
- 可以在敏感工作負載上設定 CPU 限制。
- 對於支援的節點，為程式啟用帶有適當系統呼叫配置檔案的 Seccomp。
- 對於支援的節點，為程式啟用帶有適當配置檔案的 AppArmor 或 SELinux。
RBAC 授權至關重要，但 無法足夠精細地對 Pod 資源進行授權（或對任何管理 Pod 的資源進行授權）。唯一的粒度是對資源本身的 API 動詞，例如對 Pod 的 create。如果沒有額外的准入，建立這些資源的授權將允許對叢集中可排程的節點進行直接無限制的訪問。
Pod 安全標準 定義了三種不同的策略：特權、基線和受限，它們限制瞭如何在 PodSpec 中設定與安全相關的欄位。這些標準可以透過新的 Pod 安全 准入（預設啟用）或第三方准入 webhook 在名稱空間級別強制執行。請注意，與它取代的已移除的 PodSecurityPolicy 准入相反，Pod 安全 准入可以輕鬆地與准入 webhook 和外部服務結合使用。
Pod 安全准入的 restricted 策略是 Pod 安全標準 集中最嚴格的策略，可以在多種模式下執行，如 warn、audit 或 enforce，以根據安全最佳實踐逐步應用最合適的 安全上下文。儘管如此，對於特定用例，仍應單獨研究 Pod 的 安全上下文，以限制 Pod 在預定義安全標準之外可能擁有的許可權和訪問。
有關 Pod 安全 的實踐教程，請參閱部落格文章 Kubernetes 1.23: Pod Security Graduates to Beta。
應設定 記憶體和 CPU 限制，以限制 Pod 在節點上可消耗的記憶體和 CPU 資源，從而防止惡意或被攻破的工作負載可能發動的 DoS 攻擊。此類策略可以透過准入控制器強制執行。請注意，CPU 限制將限制使用，從而可能對自動擴縮功能或效率產生意想不到的影響，例如在可用 CPU 資源下以盡力而為的方式執行程序。
注意
如果記憶體限制高於請求，可能會導致整個節點出現 OOM 問題。啟用 Seccomp
Seccomp 代表安全計算模式，自 Linux 核心版本 2.6.12 以來一直是其一項功能。它可用於沙箱化程序的許可權，限制其能夠從使用者空間向核心進行的呼叫。Kubernetes 允許你將載入到節點上的 seccomp 配置檔案自動應用於你的 Pod 和容器。
Seccomp 可以透過減少容器內可用的 Linux 核心系統呼叫攻擊面來提高工作負載的安全性。seccomp 過濾模式利用 BPF 建立特定系統呼叫的允許或拒絕列表，稱為配置檔案。
自 Kubernetes 1.27 起，你可以將 RuntimeDefault 作為所有工作負載的預設 seccomp 配置檔案。有關此主題的 安全教程 可用。此外，Kubernetes Security Profiles Operator 是一個旨在簡化叢集中 seccomp 管理和使用的專案。
注意
Seccomp 僅在 Linux 節點上可用。啟用 AppArmor 或 SELinux
AppArmor
AppArmor 是一個 Linux 核心安全模組，可以提供一種簡單的方法來實現強制訪問控制 (MAC) 並透過系統日誌進行更好的審計。預設的 AppArmor 配置檔案在支援它的節點上強制執行，或者可以配置自定義配置檔案。與 seccomp 一樣，AppArmor 也透過配置檔案進行配置，每個配置檔案都以強制模式執行，阻止對不允許資源的訪問，或者以投訴模式執行，只報告違規行為。AppArmor 配置檔案透過註解在每個容器的基礎上強制執行，允許程序獲得恰到好處的許可權。
注意
AppArmor 僅在 Linux 節點上可用，並且在 某些 Linux 發行版 中啟用。SELinux
SELinux 也是一個 Linux 核心安全模組，可以為支援訪問控制安全策略（包括強制訪問控制 (MAC)）提供機制。SELinux 標籤可以透過其 securityContext 部分 分配給容器或 Pod。
注意
SELinux 僅在 Linux 節點上可用，並且在 某些 Linux 發行版 中啟用。日誌和審計
- 審計日誌（如果啟用）受保護，不受一般訪問。
Pod 排程
- Pod 排程根據應用程式的敏感度層級進行。
- 敏感應用程式在節點上隔離執行，或使用特定的沙箱化執行時。
敏感度級別不同的 Pod，例如應用程式 Pod 和 Kubernetes API 伺服器，應部署到單獨的節點上。節點隔離的目的是防止應用程式容器逃逸直接提供對敏感度級別更高的應用程式的訪問，從而在叢集中輕鬆進行橫向移動。應強制執行這種隔離，以防止 Pod 意外地部署到同一節點上。這可以透過以下功能強制執行：
- 節點選擇器
- 作為 Pod 規約一部分的鍵值對，用於指定要部署到的節點。這些可以在名稱空間和叢集級別透過 PodNodeSelector 准入控制器強制執行。
- PodTolerationRestriction
- 一個准入控制器，允許管理員限制名稱空間內允許的 容忍度。名稱空間內的 Pod 只能使用名稱空間物件註解鍵上指定的一組預設和允許的容忍度。
- RuntimeClass
- RuntimeClass 是一個用於選擇容器執行時配置的功能。容器執行時配置用於執行 Pod 的容器，並且可以以效能開銷為代價提供或多或少的與主機的隔離。
Secret
- ConfigMap 不用於儲存機密資料。
- Secret API 已配置靜態加密。
- 如果適用，部署並提供了一種機制來注入儲存在第三方儲存中的 Secret。
- ServiceAccount Token 未掛載到不需要它們的 Pod 中。
- 使用 繫結 ServiceAccount Token 卷 代替不限期的 Token。
Pod 所需的 Secret 應儲存在 Kubernetes Secret 中，而不是 ConfigMap 等替代方案。儲存在 etcd 中的 Secret 資源應進行 靜態加密。
需要 Secret 的 Pod 應透過卷自動掛載這些 Secret，最好儲存在記憶體中，例如使用 emptyDir.medium 選項。也可以使用機制將第三方儲存中的 Secret 作為卷注入，例如 Secrets Store CSI Driver。這應優先於為 Pod 的 ServiceAccount 提供對 Secret 的 RBAC 訪問。這將允許將 Secret 作為環境變數或檔案新增到 Pod 中。請注意，由於日誌中的崩潰轉儲以及 Linux 中環境變數的非機密性質，環境變數方法可能更容易洩露，而檔案上的許可權機制則不同。
不需要 ServiceAccount Token 的 Pod 不應掛載這些 Token。這可以透過將 automountServiceAccountToken 設定為 false 來配置，無論是針對整個名稱空間中的 ServiceAccount，還是專門針對某個 Pod。對於 Kubernetes v1.22 及更高版本，請使用 繫結 ServiceAccount 以獲取有時限的 ServiceAccount 憑據。
映象
- 最小化容器映象中不必要的內容。
- 容器映象配置為以非特權使用者身份執行。
- 透過 sha256 摘要（而不是標籤）引用容器映象，或者透過在部署時 透過准入控制 驗證映象的數字簽名來驗證映象的來源。
- 容器映象在建立和部署過程中定期掃描，並修補已知存在漏洞的軟體。
容器映象應只包含執行其打包程式所需的最低限度內容。最好只包含程式及其依賴項，並從儘可能小的基礎構建映象。特別是，生產中使用的映象不應包含 shell 或除錯工具，因為可以使用 臨時除錯容器 進行故障排除。
透過在 Dockerfile 中使用 USER 指令，構建映象以直接以非特權使用者身份啟動。安全上下文 允許容器映象以特定的使用者和組（使用 runAsUser 和 runAsGroup）啟動，即使在映象清單中未指定。然而，映象層中的檔案許可權可能會導致無法在不修改映象的情況下以新的非特權使用者身份啟動程序。
避免使用映象標籤來引用映象，特別是 latest 標籤，因為標籤背後的映象很容易在登錄檔中修改。建議使用唯一的完整 sha256 摘要，它對映象清單是唯一的。此策略可以透過 ImagePolicyWebhook 強制執行。映象簽名也可以在部署時透過 准入控制器 自動驗證，以驗證其真實性和完整性。
掃描容器映象可以防止在部署容器映象時將關鍵漏洞引入叢集。映象掃描應在將容器映象部署到叢集之前完成，並且通常作為 CI/CD 流水線部署過程的一部分進行。映象掃描的目的是獲取有關容器映象中可能存在的漏洞及其預防措施的資訊，例如 通用漏洞評分系統 (CVSS) 分數。如果映象掃描結果與流水線合規性規則相結合，只有正確修補的容器映象才能進入生產環境。
准入控制器
- 已啟用適當選擇的准入控制器。
- Pod 安全策略由 Pod 安全准入或/和 webhook 准入控制器強制執行。
- 准入鏈外掛和 webhook 已安全配置。
准入控制器有助於提高叢集的安全性。然而，它們本身也可能帶來風險，因為它們擴充套件了 API 伺服器，並且 應妥善保護。
以下列表列出了可用於增強叢集和應用程式安全態勢的一些准入控制器。它包括本文件其他部分可能引用的控制器。
第一組准入控制器包括 預設啟用的 外掛，除非你清楚自己在做什麼，否則請考慮保持啟用它們。
CertificateApproval- 執行額外的授權檢查，以確保批准使用者具有批准證書請求的許可權。
CertificateSigning- 執行額外的授權檢查，以確保簽署使用者具有簽署證書請求的許可權。
CertificateSubjectRestriction- 拒絕所有指定
system:masters組（或“組織屬性”）的證書請求。 LimitRanger- 強制執行 LimitRange API 限制。
MutatingAdmissionWebhook- 允許透過 webhook 使用自定義控制器，這些控制器可能會修改它們審查的請求。
PodSecurity- Pod Security Policy 的替代品，限制部署 Pod 的安全上下文。
ResourceQuota- 強制執行資源配額以防止資源過度使用。
ValidatingAdmissionWebhook- 允許透過 webhook 使用自定義控制器，這些控制器不會修改它們審查的請求。
第二組包括預設未啟用但處於通用可用狀態並建議用於改善安全狀況的外掛
DenyServiceExternalIPs- 拒絕所有新使用
Service.spec.externalIPs欄位的行為。這是針對 CVE-2020-8554：使用 LoadBalancer 或 ExternalIPs 進行中間人攻擊 的緩解措施。 NodeRestriction- 限制 kubelet 的許可權，使其只能修改其擁有的 Pod API 資源或代表其自身的節點 API 資源。它還防止 kubelet 使用
node-restriction.kubernetes.io/註解，攻擊者可以使用具有 kubelet 憑據的攻擊者影響 Pod 排程到受控節點。
第三組包括預設未啟用但可考慮用於特定用例的外掛
AlwaysPullImages- 強制使用標籤映象的最新版本，並確保部署者有許可權使用該映象。
ImagePolicyWebhook- 允許透過 webhook 對映象實施額外的控制。
下一步
- 透過 Pod 建立進行許可權提升 警告你一個特定的訪問控制風險；請檢查你如何管理該威脅。
- 如果你使用 Kubernetes RBAC，請閱讀 RBAC 最佳實踐 以獲取有關授權的更多資訊。
- 保護叢集 以獲取有關保護叢集免受意外或惡意訪問的資訊。
- 叢集多租戶指南 用於多租戶的配置選項建議和最佳實踐。
- 部落格文章 “A Closer Look at NSA/CISA Kubernetes Hardening Guidance”，是關於強化 Kubernetes 叢集的補充資源。