Kubernetes （K8s）是現代雲原生世界中的容器管理平臺。它實現了靈活、可擴充套件地開發、部署和管理微服務。K8s 能夠與各種雲提供商、容器執行時介面、身份驗證提供商和可擴充套件整合點一起工作。然而 K8s 的整合方法可以在任何基礎設施上執行任何容器化應用程式，這使得圍繞 K8s 和其上的應用程式堆疊建立整體安全性面臨挑戰。根據 Red Hat 的 2022 年 K8s 安全報告，在過去 12 個月的過程中，幾乎所有參與研究的 K8s 使用者都經歷過至少一次安全事件。因此，可以說 K8s 環境在預設情況下並不安全，並且容易面臨風險。
本文將討論 10 大 K8s 安全風險，並就如何避免這些風險給出提示。
1. K8s Secret
Secret 是 K8s 的核心構建塊之一，用於儲存密碼、證書或令牌等敏感資料，並在容器內使用它們。與 K8s Secret 相關的三個關鍵問題：
- Secrets 將敏感資料儲存為 base-64 編碼字串，但預設情況下不加密。K8s 確實提供了儲存資源的加密，但使用者需要對其進行配置。此外，關於機密的最大威脅是同一名稱空間中的任何 pod，以及在 pod 內執行的任何應用程式都可以訪問和讀取它們。
- 基於角色的訪問控制（RBAC）控制誰有權訪問 K8s 資源。使用者需要正確配置 RBAC 規則，以便只有相關人員和應用程式才能訪問機密。
- Secrets 和 ConfigMaps 是將資料傳遞給正在執行的容器的兩種方法。如果有舊的和未使用的 Secrets 或 ConfigMap 資源，會造成混亂並洩漏易受攻擊的資料。例如，如果使用者刪除了後端應用程式部署但忘記刪除包含的資料庫密碼的機密，那麼將來任何惡意 pod 都可以使用這些敏感資料。
2. 存在漏洞的容器映象
K8s 是一個容器編排平臺，在工作節點上分發和執行容器。但是它不會檢查容器的內容是否存在安全漏洞或暴露。因此，需要在部署前對映象進行掃描，以確保只有來自可信映象倉庫且沒有嚴重漏洞（如遠端程式碼執行）的映象才會在叢集上執行。容器映象掃描也應該整合到 CI/CD 系統中，以實現自動化和更早地檢測問題和缺陷。
3. 執行時威脅
K8s 工作負載（即容器）在工作節點上執行，容器在執行時由主機作業系統控制。如果存在寬鬆政策或存在漏洞的容器映象，可能會為整個叢集開啟後門。因此，需要作業系統級別的執行時保護來加強執行時的安全性，而針對執行時威脅和漏洞的最重要的保護，在整個 K8s 中實現最小特權原則。
4. 叢集錯誤配置和預設配置
K8s API 及其元件由一組複雜的資源定義和配置選項組成。因此，K8s 為其大部分配置引數提供了預設值，並試圖消除建立長 YAML 檔案的負擔。但是，使用者需要注意與叢集和資源配置相關的三個關鍵問題：
- 雖然預設的 K8s 配置很實用，因為可以提高使用的靈活性和敏捷性，但它們並不總是最安全的選擇。
- K8s 資源的線上示例有助於入門，但在參考時需要檢查這些示例資源定義將部署到叢集的內容。
- 在叢集上工作時，通常使用“kubectl edit”命令更改 K8s 資源。但如果使用者忘記更新原始檔，更改將在下一次部署中被覆蓋，並且未跟蹤的修改可能會埋下安全隱患。
5. K8s 中的 RBAC 策略
RBAC 管理和控制 K8s 資源授權方式。因此，配置和維護 RBAC 策略對於保護叢集避免不必要的訪問至關重要。使用 RBAC 策略時需要考慮兩個關鍵點。首先，一些 RBAC 策略過於寬鬆，比如 cluster_admin 角色，它基本擁有叢集中的所有許可權。這些角色被分配給一般開發人員，使他們能夠敏捷完成開發人。但如果出現安全漏洞，攻擊者可以使用 cluster_admin 快速獲得對叢集的高階訪問許可權。為避免這種情況，使用者需要為特定資源配置 RBAC 策略並將全線分配給特定的使用者組。
另外，軟體開發生命週期中存在各種環境，如開發、測試、預釋出和生產。此外，還有開發人員、測試人員、運營人員和雲管理員等多個側重點不同的團隊。應為每個組和每個環境正確分配 RBAC 策略。
6. 網路接入
在 K8s 中，一個 pod 可以連線到叢集外部的其他 pod 和外部地址；預設情況下，其他人可以從叢集內部連線到此 pod。網路策略用於管理和限制 pod、名稱空間和 IP Blocks 之間的網路訪問。網路策略可以與 pod 上的標籤一起使用，而標籤的不當使用可能會導致不必要的訪問。此外，當叢集位於雲提供商處時，叢集網路應該與虛擬私有云 (VPC) 的其餘部分隔離。
7. 整體監控和審計日誌
當使用者將應用程式部署到 K8s 叢集時，僅依靠監控應用程式指標是不夠的。還必須觀察 K8s 叢集的狀態、雲基礎設施和雲控制器，以全面瞭解整個堆疊。監視漏洞和檢測異常也很重要，因為惡意攻擊者會測試從每個可能的開口來訪問叢集。K8s 為叢集中與安全相關的事件提供開箱即用的審計日誌。即便如此，使用者依舊需要從各種應用程式收集記錄並在一箇中心位置監控叢集健康狀況。
8. K8s API
K8s API 是整個系統的核心，所有內部和外部客戶端都與 K8s 進行連線和通訊。如果使用者在內部部署和管理 K8s 元件則需要更加小心，因為** K8s API 伺服器及其元件是具有潛在和實際漏洞的開源工具**。因此使用者應該使用最新的穩定版本的 K8s 並儘早修復叢集。
如果使用雲提供商，K8s 控制皮膚由提供商控制，雲基礎設施會自動更新和打補丁。但是在大多數情況下使用者需要自行負責升級工作節點。因此，使用者可以使用自動化和資源供應工具輕鬆升級節點或更換新節點。
9. K8s 資源請求和限制
除了排程和執行容器，K8s 還可以在 CPU 和記憶體方面限制容器的資源使用。資源請求和限制至關重要，原因有兩點：
- 安全性：當 pod 和名稱空間不受限制時，即使是具有安全漏洞的單個容器也可以訪問叢集內的敏感資料。
- 成本：當請求的資源超過實際使用量時，節點將耗盡可用資源。如果啟用自動縮放，這將導致節點池增加，新節點將不可避免地增加您的雲費用。
當資源請求被正確計算和分配時，整個叢集在 CPU 和記憶體方面高效工作。此外，當設定資源限制時，故障應用程式和惡意攻擊者都將在資源使用方面受到限制。如果沒有資源限制，惡意容器可能會消耗節點中幾乎所有的資源並使應用程式無法使用。
10. 資料與儲存
K8s 讓有狀態的容器化應用程式可擴充套件且可靠地執行成為可能。藉助 StatefulSet 資源，使用者可以快速將資料庫、資料分析工具和機器學習應用程式部署到 K8s 中。這些資料將作為連線到容器的卷供 Pod 訪問。
透過策略和標籤限制訪問來避免叢集中其他 pod 進行不必要的訪問至關重要。此外，K8s 中的儲存是由外部系統提供的，因此使用者應該考慮對叢集中的關鍵資料進行加密。如果使用者管理儲存外掛，還應該檢查安全引數以確保它們已啟用。
參考連結：
https://www.darkreading.com/dr-tech/top-10-K8s-security-risks-every-devsecops-needs-to-know
https://www.redhat.com/en/blog/state-K8s-security-2022-1
https://K8s.io/docs/concepts/workloads/controllers/statefulset/