【資料圖】

引言：

Kubernetes為我們提供了一套很好的核心軟件安全原則，但我們仍然需要理解并實施它們。對于 Kubernetes 集群分布式部署，攻擊向量的數量也會增加，了解并盡可能限制這些攻擊面的最佳實踐非常重要。

即使在使用托管的 Kubernetes 服務時，例如：EKS、AKS、TKE等，一些安全所有權仍然落在我們最終用戶身上。云供應商通常負責管理和保護 Kubernetes 集群的控制平面（API 服務器、調度程序、etcd、控制器），客戶負責保護數據平面（節點池、入口、網絡、服務網格等）。

1、使用基于角色的訪問控制（RBAC）

基于角色的訪問控制 (RBAC) 讓客戶可以控制誰可以訪問 Kubernetes API 以及他們擁有什么權限。RBAC 通常在 Kubernetes 中默認啟用。但是，如果您從非常舊的 Kubernetes 版本升級并且之前沒有啟用它，則應檢查 RBAC 設置以確保它們已啟用。另一件要記住的事情是僅僅啟用 RBAC 是不夠的。您還應該管理授權策略并正確使用它們。使用 RBAC 將用戶和組限制為他們可能需要的操作和任務。始終遵循最小權限原則，以確保用戶和 Kubernetes 服務帳戶具有所需的最小權限集。確保不授予集群范圍的權限，除非絕對必要，否則不要授予任何集群管理員權限。有關詳細信息，請參閱官方 Kubernetes RBAC 文檔 。對于使用云服務創建和管理的 Kubernetes 集群的操作，供應商可能會提供身份和訪問管理 服務。此處的文檔 提供了更多詳細信息。如果您需要多個因素來驗證身份，多因素身份驗證 (MFA) 是另一種增強 Kubernetes API 身份驗證安全性的選項。

2、Secret應該是機密的

機密包含敏感數據，例如密碼、令牌或 SSH 密鑰。Kubernetes 機密有助于使用密鑰、密碼、令牌等工件安全地初始化 pod。當 pod 啟動時，它通常需要訪問其機密。每當創建服務帳戶時，都會自動生成存儲其授權令牌的 Kubernetes 秘密。Kubernetes 支持靜態加密。這將加密 etcd 中的秘密資源，防止訪問您的 etcd 備份和查看這些秘密的內容。當備份未加密或攻擊者獲得對 etcd 的讀取權限時，加密提供了額外的防御級別。確保用戶與 API 服務器之間以及從 API 服務器到 kubelet 的通信使用 SSL/TLS 進行保護，如此 處所述。推薦的做法是使秘密或憑據的生命周期較短，以使攻擊者更難使用它們。為證書設置較短的生命周期并自動輪換是一個很好的做法。另一件要記住的事情是了解第三方集成請求訪問 Kubernetes 集群的秘密。在這種情況下，請仔細檢查請求的 RBAC 權限和訪問權限，否則您可能會危及集群的安全配置文件。如果您使用的是Oracle Kubernetes Engine，請參閱 在 Etcd 中靜態加密 Kubernetes 機密以 獲取更多信息。

3、私有 Kubernetes API 端點

Kubernetes 集群管理員和操作員可以將集群的 Kubernetes API 端點配置為私有或公共子網的一部分。在私有集群中，控制平面內的 API 服務器（端點）有一個私有 IP 地址，使主服務器無法從公共互聯網訪問。除了專用工作程序節點之外，您還應確保將 Kubernetes API 端點配置為專用端點。如果您需要創建不使用或公開任何公共 IP 并且不允許流量進出公共互聯網的完全私有集群，這一點很重要?？梢允褂冒踩L問控制列表或使用網絡安全設置在粒度級別控制對集群 API 端點的網絡訪問。例如，

4、保護節點和 Pod

節點： Kubernetes 節點是工作節點，可以是通常在 Linux 操作系統 (OS) 上運行的虛擬機或物理機。節點上運行的服務包括容器運行時、kubelet 和 kube-proxy。加固和保護節點上運行的操作系統很重要；這是云提供商和 Kubernetes 管理員的責任。例如，Oracle Kubernetes Engine 節點帶有強化的 Linux 映像。Kubernetes 管理員應定期在這些節點上運行的 Linux 映像上應用安全補丁，或者在客戶提供這些補丁后使用服務提供商的自動升級功能。對節點使用互聯網安全中心 (CIS) Kubernetes 基準測試是另一種好的做法。除了 OS 安全之外，建議節點位于專用網絡上并且不能從 Internet 訪問。如果需要，可以配置網關以訪問集群網絡之外的其他服務。節點上的網絡端口訪問應通過網絡訪問列表進行控制。還建議限制對節點的安全外殼 (SSH) 訪問。Oracle Kubernetes Engine 節點池安全文檔 提供了更多指導。Pod: Pod 是一 組在節點上運行的一個或多個容器，可以使用共享或專用存儲。默認情況下，對于哪些節點可以運行 pod 沒有限制。使用 網絡策略來定義集群中 pod 的通信規則。網絡策略由網絡插件實現，使用它們可能需要支持策略的網絡驅動程序。例如，Oracle Kubernetes Engine 提供了多種選項 來保護與集群中的工作負載之間的通信。為獲得最佳網絡安全態勢，評估使用網絡策略組合來保護 pod 級網絡通信和安全列表以保護主機級網絡通信。Kubernetes pod 安全上下文有助于定義 pod 或容器的權限和訪問控制設置。檢查并利用 pod 和容器清單正在使用的安全上下文設置。Pod 安全策略允許客戶控制 Pod 的運行時執行屬性，例如將容器作為特權容器運行的能力、主機文件系統、網絡和端口的使用。默認情況下，一個 pod 可以被調度到集群中的任何節點上。Kubernetes 提供了多種方式來控制 pod 分配給節點，例如用于控制 Pod 在節點上的放置 以及 基于污點的 Pod 放置和驅逐的策略。如果使用 Oracle Kubernetes Engine，您可以按照文檔中的說明為集群設置 pod 安全策略。

5、消除容器安全風險

應用程序被打包為容器鏡像，通常是 Docker 鏡像。容器映像存儲在容器注冊表中并從中提取，并實例化為 Pod 內的運行時容器。當您處理源代碼和庫以為您的應用程序構建容器映像時，安全性必須是開發過程開始時的設計原則。在 CI/CD 工具鏈中以及容器映像的整個構建、存儲和部署過程中實施安全實踐。其中包括安全地存儲容器鏡像、掃描這些鏡像以查找安全漏洞以及管理容器的運行時安全性。作為 DevSecOps 周期的一部分，自動掃描您可能用于構建應用程序的第三方庫的漏洞是個好主意。例如，如果您使用的是 Oracle Kubernetes Engine，您還可以查看 NeuVector、Deepfence、Aqua Security 和 Prisma Cloud Security 等合作伙伴解決方案。您還可以找到本機容器鏡像掃描、簽名和驗證功能作為平臺的一部分。在構建 Docker 鏡像和容器時，使用強化的 slim 操作系統鏡像，并確保運行應用程序的用戶擁有運行容器內進程所需的最低操作系統權限。另一件需要記住的重要事情是定期對源鏡像應用安全更新，然后將它們重新部署為更新的容器。使用私有 Docker 注冊表（如Oracle Cloud Infrastructure Registry）也很重要，它具有適當的訪問控制和適當的策略以及容器映像管理的治理。建議簽署容器鏡像并維護容器內容的信任系統。

6、審計、日志記錄和監控必不可少

審計、日志記錄和監控是重要的安全方面，可以幫助改善集群的安全狀況，不容忽視。Kubernetes 審計日志是對 Kubernetes API 服務器的每次調用的詳細描述。這些審計日志提供有關集群中發生的事情的有用信息，甚至可以用于審計、合規性和安全分析。Kubernetes 審計 記錄包括捕獲完整活動序列的安全記錄，可以幫助檢測異常行為和對敏感資源的訪問。建議啟用審核日志并將審核日志保存在安全存儲庫中，以便在發生危害時進行分析。Kubernetes 還提供基于集群的 日志記錄 ，將容器活動記錄到中央日志子系統中。Kubernetes 集群中每個容器的標準輸出和標準錯誤輸出可以使用 在每個節點上運行 的代理（如Fluentd）提取到Elasticsearch等工具中，并使用 Kibana 查看。最后，使用Prometheus、 Grafana或 Jaeger等工具監控容器、pod、應用程序、服務和集群的其他組件， 以監控、查看和跟蹤集群。 O"Reilly 的Liz Rice 和 Michael Hausenblas 合著的“Kubernetes Security”一書是了解有關該主題的更多信息的好資源。如果像我一樣使用 Oracle Kubernetes Engine，您可以查看 OCI 安全指南 和一些關于 保護 Oracle Kubernetes Engine的額外建議。如上所述，我還利用了 Oracle Cloud Infrastructure 中的本地身份和身份驗證功能。

關于HummerRisk

HummerRisk 是開源的云原生安全平臺，以非侵入的方式解決云原生的安全和治理問題，核心能力包括混合云的安全治理和K8S容器云安全檢測。

Github 地址：https://github.com/HummerRisk/HummerRisk

Gitee 地址：https://gitee.com/hummercloud/HummerRisk