保護叢集安全

本文件涵蓋與保護叢集免於意外或惡意存取相關的主題，並提供關於整體安全性的建議。

開始之前

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

控制 Kubernetes API 的存取

由於 Kubernetes 完全由 API 驅動，因此控制與限制誰可以存取叢集以及他們被允許執行的動作是第一道防線。

針對所有 API 流量使用傳輸層安全性 (TLS)

Kubernetes 預期叢集中所有 API 通訊預設都會使用 TLS 加密，而且大多數安裝方法都會允許建立必要的憑證並將其散佈到叢集元件。請注意，某些元件與安裝方法可能會透過 HTTP 啟用本機連接埠，管理員應熟悉每個元件的設定，以識別可能不安全的流量。

API 驗證

選擇 API 伺服器使用的驗證機制，使其符合您安裝叢集時的常見存取模式。例如，小型、單一使用者叢集可能希望使用簡單的憑證或靜態 Bearer 權杖方法。較大的叢集可能希望整合現有的 OIDC 或 LDAP 伺服器，以允許將使用者細分為群組。

所有 API 用戶端都必須經過驗證，即使是基礎架構的一部分，例如節點、代理伺服器、排程器與磁碟區外掛程式。這些用戶端通常是服務帳戶或使用 x509 用戶端憑證，而且它們會在叢集啟動時自動建立，或設定為叢集安裝的一部分。

請參閱驗證參考文件以取得更多資訊。

API 授權

完成身分驗證後，每個 API 呼叫也需要通過授權檢查。Kubernetes 內建整合的角色型存取控制 (RBAC) 元件，可將傳入的使用者或群組與一組捆綁到角色中的權限進行比對。這些權限結合了動詞（get、create、delete）和資源（Pod、服務、節點），並且可以是命名空間範圍或叢集範圍。系統提供了一組開箱即用的角色，根據用戶端可能想要執行的動作，提供合理的預設職責分離。建議您將 Node 和 RBAC 授權器結合 NodeRestriction 許可控制器外掛程式一起使用。

與身分驗證一樣，簡單而廣泛的角色可能適用於較小的叢集，但隨著更多使用者與叢集互動，可能需要將團隊劃分到不同的命名空間，並使用更受限的角色。

關於授權，重要的是要了解一個物件上的更新如何導致其他地方的動作。例如，使用者可能無法直接建立 Pod，但允許他們建立 Deployment（會在背後建立 Pod），將讓他們間接建立這些 Pod。同樣地，從 API 刪除節點將導致排程到該節點的 Pod 終止並在其他節點上重新建立。開箱即用的角色代表了彈性和常見用例之間的平衡，但應仔細審查更受限的角色，以防止意外的權限提升。如果開箱即用的角色不符合您的需求，您可以建立特定於您的用例的角色。

請參閱授權參考章節以取得更多資訊。

控制對 Kubelet 的存取

Kubelet 公開 HTTPS 端點，這些端點授予對節點和容器的強大控制權。預設情況下，Kubelet 允許未經驗證的存取此 API。

生產叢集應啟用 Kubelet 身分驗證和授權。

請參閱 Kubelet 身分驗證/授權參考以取得更多資訊。

在執行時控制工作負載或使用者的功能

Kubernetes 中的授權在設計上是高層次的，重點在於對資源的粗略動作。更強大的控制以策略的形式存在，以根據用例限制這些物件如何在叢集、自身和其他資源上運作。

限制叢集上的資源用量

資源配額限制授予命名空間的資源數量或容量。這最常用於限制命名空間可以分配的 CPU、記憶體或永久磁碟數量，但也可以控制每個命名空間中存在的 Pod、服務或 Volume 的數量。

限制範圍限制上述某些資源的最大或最小值，以防止使用者請求對於常用保留資源（如記憶體）而言不合理的高或低值，或在未指定限制時提供預設限制。

控制容器執行的權限

Pod 定義包含一個安全環境，允許它請求以節點上的特定 Linux 使用者身分（例如 root）執行、存取以特權模式執行或存取主機網路，以及其他控制項，否則這些控制項將允許它在託管節點上不受限制地執行。

您可以設定 Pod 安全許可，以在命名空間中強制使用特定的 Pod 安全標準，或偵測違規行為。

一般而言，大多數應用程式工作負載只需要對主機資源的有限存取權，以便它們可以成功地作為 root 處理程序 (uid 0) 執行，而無需存取主機資訊。但是，考慮到與 root 使用者相關聯的權限，您應該編寫應用程式容器以非 root 使用者身分執行。同樣地，希望防止用戶端應用程式逃脫其容器的管理員應套用 Baseline 或 Restricted Pod 安全標準。

防止容器載入不需要的核心模組

在某些情況下，例如當連接硬體或掛載檔案系統時，Linux 核心會自動從磁碟載入核心模組（如果需要）。與 Kubernetes 特別相關的是，即使是非特權處理程序也可以僅透過建立適當類型的 Socket 來導致載入某些與網路協定相關的核心模組。這可能允許攻擊者利用管理員認為未使用的核心模組中的安全漏洞。

為了防止自動載入特定模組，您可以從節點解除安裝它們，或新增規則來封鎖它們。在大多數 Linux 發行版上，您可以透過建立類似 /etc/modprobe.d/kubernetes-blacklist.conf 的檔案來執行此操作，其內容如下

# DCCP is unlikely to be needed, has had multiple serious
# vulnerabilities, and is not well-maintained.
blacklist dccp

# SCTP is not used in most Kubernetes clusters, and has also had
# vulnerabilities in the past.
blacklist sctp

為了更通用地封鎖模組載入，您可以使用 Linux 安全模組（例如 SELinux）來完全拒絕容器的 module_request 權限，從而防止核心在任何情況下為容器載入模組。（Pod 仍然可以使用手動載入的模組，或由核心代表某些更具特權的處理程序載入的模組。）

限制網路存取

命名空間的網路原則允許應用程式作者限制其他命名空間中的哪些 Pod 可以存取其命名空間內的 Pod 和 Port。許多受支援的 Kubernetes 網路供應商現在都遵循網路原則。

配額和限制範圍也可用於控制使用者是否可以請求節點 Port 或負載平衡服務，這在許多叢集上可以控制這些使用者的應用程式是否在叢集外部可見。

其他保護措施可能可用於控制每個外掛程式或每個環境的網路規則，例如每個節點的防火牆、物理上分隔叢集節點以防止串擾或進階網路原則。

限制雲端中繼資料 API 存取

雲端平台（AWS、Azure、GCE 等）通常在本機向執行個體公開中繼資料服務。預設情況下，這些 API 可由執行個體上執行的 Pod 存取，並且可以包含該節點的雲端憑證或佈建資料（例如 Kubelet 憑證）。這些憑證可用於在叢集內或相同帳戶下的其他雲端服務中升級權限。

在雲端平台上執行 Kubernetes 時，請限制授予執行個體憑證的權限，使用網路原則來限制 Pod 對中繼資料 API 的存取，並避免使用佈建資料來傳遞密碼。

控制 Pod 可以存取的節點

預設情況下，對哪些節點可以執行 Pod 沒有限制。Kubernetes 提供了豐富的策略集，用於控制 Pod 在節點上的放置，以及最終使用者可用的基於污點的 Pod 放置和驅逐。對於許多叢集，使用這些策略來分隔工作負載可能成為作者採用或透過工具強制執行的慣例。

作為管理員，可以使用 Beta 版許可控制器外掛程式 PodNodeSelector 來強制命名空間中的 Pod 預設或需要特定的節點選擇器，如果最終使用者無法變更命名空間，則可以強烈限制特定工作負載中所有 Pod 的放置。

保護叢集元件免受洩露

本節介紹了一些保護叢集免受洩露的常見模式。

限制對 etcd 的存取

對 API 的 etcd 後端進行寫入存取相當於獲得整個叢集的 root 權限，而讀取存取可用於相當快速地升級權限。管理員應始終使用來自 API 伺服器的強憑證來存取其 etcd 伺服器，例如透過 TLS 用戶端憑證進行相互驗證，並且通常建議將 etcd 伺服器隔離在只有 API 伺服器可以存取的防火牆之後。

注意

允許叢集內的其他元件使用讀取或寫入權限存取主 etcd 執行個體的完整金鑰空間，相當於授予叢集管理員存取權限。強烈建議為非主元件使用單獨的 etcd 執行個體，或使用 etcd ACL 來限制對金鑰空間子集的讀取和寫入存取權限。

啟用稽核日誌記錄

稽核記錄器是一項 Beta 版功能，用於記錄 API 採取的動作，以便在發生洩露事件後進行後續分析。建議啟用稽核日誌記錄，並將稽核檔案封存到安全伺服器上。

限制對 Alpha 版或 Beta 版功能的存取

Alpha 版和 Beta 版 Kubernetes 功能正在積極開發中，可能存在限制或錯誤，從而導致安全漏洞。始終評估 Alpha 版或 Beta 版功能可能提供的價值與可能對您的安全態勢造成的風險。如有疑問，請停用您不使用的功能。

頻繁輪換基礎架構憑證

密碼或憑證的生命週期越短，攻擊者就越難以利用該憑證。為憑證設定短生命週期並自動化其輪換。使用可以控制發行 Token 可用時長的身份驗證提供者，並在可能的情況下使用短生命週期。如果您在外部整合中使用服務帳戶 Token，請計劃頻繁輪換這些 Token。例如，一旦引導階段完成，用於設定節點的引導 Token 應被撤銷或移除其授權。

在啟用第三方整合之前先審查它們

許多 Kubernetes 的第三方整合可能會改變您叢集的安全配置。在啟用整合時，始終在授予擴充功能存取權限之前審查擴充功能請求的權限。例如，許多安全整合可能會請求存取檢視您叢集上的所有密碼，這實際上使該元件成為叢集管理員。如有疑問，請盡可能將整合限制為在單一命名空間中運作。

如果可以建立在 kube-system 命名空間等命名空間內的 Pod，則建立 Pod 的元件也可能異常強大，因為這些 Pod 可以存取服務帳戶密碼，或者在這些服務帳戶被授予寬鬆的 PodSecurityPolicies 存取權限的情況下以提升的權限執行。

如果您使用 Pod 安全許可並允許任何元件在允許特權 Pod 的命名空間中建立 Pod，則這些 Pod 可能能夠逃脫其容器並使用此擴大的存取權限來提升其權限。

您不應允許不受信任的元件在任何系統命名空間（名稱以 kube- 開頭的命名空間）或任何允許權限升級可能性的命名空間中建立 Pod。

靜態加密密碼

一般而言，etcd 資料庫將包含可透過 Kubernetes API 存取的任何資訊，並且可能會讓攻擊者顯著了解您叢集的狀態。始終使用經過良好審查的備份和加密解決方案來加密您的備份，並考慮在可能的情況下使用全磁碟加密。

Kubernetes 支援 Kubernetes API 中資訊的選用靜態加密。這讓您可以確保當 Kubernetes 儲存物件資料時（例如，Secret 或 ConfigMap 物件），API 伺服器會寫入物件的加密表示形式。這種加密意味著即使有人可以存取 etcd 備份資料，也無法檢視這些物件的內容。在 Kubernetes 1.32 中，您也可以加密自訂資源；Kubernetes v1.26 版本新增了 CustomResourceDefinitions 中定義的擴充 API 的靜態加密。

接收安全更新警報和報告漏洞

加入 kubernetes-announce 群組以接收有關安全公告的電子郵件。請參閱安全報告頁面，以取得有關如何報告漏洞的更多資訊。

下一步

安全檢查清單，以取得有關 Kubernetes 安全指南的更多資訊。
Seccomp 節點參考

上次修改時間：2024 年 9 月 17 日上午 10:57 PST：新增專用的 seccomp 節點參考 (c2b49fee37)