EKS 安全清單：安全叢集的 10 個最佳實踐

每日分享最新，最流行的軟體開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支援，跪求關注，點贊，留言。

發現十種 EKS 安全政策來保護您的 Kubernetes 叢集并加強您的應用程式安全性。

Kubernetes 充滿了安全挑戰。不可避免地，Amazon Elastic Kubernetes Service (EKS) 等托管 Kubernetes 服務也是如此。加強叢集安全性的最佳方法是實施已成為 Kubernetes 社群推薦的行業标準的實踐。以下是每個團隊保護其叢集所需的十大 EKS 安全政策。

Amazon EKS 安全性到底是關于什麼的？

Amazon EKS 是目前最受歡迎的托管 Kubernetes 服務之一。它允許團隊通過 Kubernetes 編排他們的容器，而無需安裝和操作 Kubernetes 控制平面或 Kubernetes 叢集運作所需的基礎設施。

由于 EKS 是 AWS 提供的一項服務，是以我們可以通過責任共擔模型開始讨論安全性。一般來說，AWS 負責管理其雲服務的安全性，而客戶則負責監督工作負載的安全性。

AWS 通過 EKS 管理 Kubernetes 儀表闆和控制平面，包括雲提供商用來提供安全 Kubernetes 環境的所有基礎設施服務。

IAM、Pod、運作時、網絡安全、工作節點可擴充性和容器映像元件等自我管理的從業人員和 EKS 叢集配置都屬于客戶。

用戶端安全包括資料安全、工作節點的更新和更新檔，以及一切的安全配置，從資料平面和節點開始，到容器和作業系統結束。客戶還需要配置安全組，允許 EKS 控制平面以安全的方式與虛拟私有雲 (VPC) 通信。

AWS 使用者通過以下形式從雲提供商處獲得有關 EKS 安全性的支援：

• 安全使用者指南，
• EKS 最佳實踐指南。

AWS 在其托管的 Kubernetes 服務中内置了 EKS 安全功能

如果每個 AWS 使用者決定使用此托管 Kubernetes 服務運作叢集，以下是一些内置的 EKS 安全功能。

AWS 機密管理器

在 Kubernetes 中，您可以建立鍵/值對并将它們帶到在您的 pod 内運作的應用程式中。如果它們包含任何敏感資料，您可以使用 Secret Store，它是由 AWS Secrets Manager（以及 AWS Parameter Store）實作的容器存儲接口驅動程式。

AWS Secrets Manager 為您提供了一個用于存儲和管理 Kubernetes 密鑰的中心位置。AWS Secrets and Configuration Provider (ASCP) 插件允許使用者處理通過 ETCD 接收密鑰的遺留 Kubernetes 工作負載。您還可以應用 IAM 政策來定義哪些 pod 可以通路密鑰。

身份和通路管理

身份和通路管理 (IAM) 可以幫助希望控制對 AWS 資源的通路的每個管理者。IAM 管理者可以根據特定政策設定誰可以登入并擁有對 EKS 資源的權限。

使用者擷取 Kubernetes 資源的身份驗證和授權憑據。這個想法是隻授予服務使用者通路他們執行工作所需的功能。

記錄和監控

AWS 提供對 CloudWatch 的通路，該日志存儲來自控制平面的診斷和審計日志。每個 EKS 控制平面都有自己的日志組。監控這些日志以及時發現安全和生産問題是關鍵。還有 AWS CloudTrail，它記錄所有 EKS 活動并捕獲使用者、角色、AWS 服務或 EKS 控制台請求進行的 API 調用。

EKS 安全的 10 個最佳實踐

1. 隔離 Kubernetes 節點

避免将 Kubernetes 節點直接暴露在公共網絡中。理想情況下，如果可能，此類節點應位于單獨的網絡上，并且與一般公司網絡沒有直接連接配接。

如何使它工作？保持 Kubernetes 控制和資料流量隔離。否則，它們最終都會流過同一根管道。對資料平面的開放通路意味着對控制平面的開放通路，這對 EKS 安全來說是個壞消息。使用入口控制器配置節點并将其設定為僅允許通過網絡通路控制清單 (ACL) 中的指定端口來自主節點的連接配接。

2、加強認證授權

将 Kubernetes 與第三方身份驗證提供程式內建是明智之舉。這樣，您可以獲得額外的安全功能層——例如，多因素身份驗證。

對于安全控制平面通路，不要在 API 伺服器級别管理使用者，而是使用 AWS Identity and Access Management (IAM) 解決方案。如果您無法獲得 CSP IAM，請選擇 OpenID Connect (OIDC) 以及您習慣的 SSO 提供商。1

3. 利用 Kubernetes 基于角色的通路控制 (RBAC)

EKS 安全性的另一個與通路相關的最佳實踐是使用 RBAC 來定義誰可以通路 Kubernetes API 以及他們擁有什麼權限。在 Kubernetes 1.6 及更高版本中，RBAC 通常預設啟用。鑒于 Kubernetes 結合了授權控制器，在打開 RBAC 時會禁用傳統的基于屬性的通路控制 (ABAC)。

選擇特定于命名空間的權限而不是叢集範圍的權限是一個好主意。即使在調試時，也要避免授予叢集管理者權限。否則，您的容器安全性可能會受到影響。

4. 避免在環境變量中保密

確定您的對象在環境變量中使用機密，因為系統的其他部分可以輕松通路環境變量。将機密用作檔案或從 secretKeyRef 中受益以最大程度地減少潛在威脅。

5. 不要在特權模式下運作容器

如果您的部署有容器以特權 (root) 模式運作，它允許容器通路重要的主機資源。這可能會導緻安全問題。避免在特權模式下運作容器或打開 podSecurityPolicy 并将特權參數設定為 false。這将確定容器無法在主機上運作需要 root 權限的程序。

6. 不要共享主機的 IPC 或網絡命名空間

檢視您的 pod 并檢視它們是否共享主機的 IPC 或網絡命名空間。為 pod 和主機程序間通信共享命名空間是危險的，因為它可能會打開對共享資訊的通路。出于這個原因，不應允許 pod 通路主機命名空間。

共享 pod 和主機網絡命名空間允許從 pod 對主機網絡進行網絡通路。這打破了網絡隔離。在 PodSecurityPolicy 中将 hostNetwork 參數設定為 false 并在晚上睡得更好，因為您知道您的叢集受到保護。

7.禁用NET_RAW

如果您的 Kubernetes 容器不放棄 NET_RAW 功能，您可能會在叢集内啟用廣泛的網絡攻擊。為確定 EKS 安全，請使用 Open Policy Agents、Kyverno 或 Kubernetes Pod Security 準入控制器等政策實施解決方案來遵循最佳行業實踐。

在 pod 的 securityContext 定義中為 ALL 或 NET_RAW 功能設定 drop 以確定 NET_RAW 功能被禁用。[2, 3]

8. 檢查 Unsafe /Proc Mount

使用 unsafe /proc mount (procMount=Unmasked) 的部署允許其他人繞過容器運作時的預設屏蔽行為。如果将容器設定為 Unmasked /procs 挂載類型，則可能會将主機資訊暴露給容器，進而導緻潛在的資料洩漏或容器逃逸。設定 procMount=Default 以確定容器不暴露 /proc 的任何部分。

9. 不要将根檔案系統用于容器安全

如果您的容器在沒有隻讀根檔案系統的情況下運作，請做好應對麻煩的準備。使用隻讀檔案系統可以防止各種惡意二進制檔案寫入系統或被攻擊者接管系統。確定容器僅使用隻讀檔案系統，并在 Pod securityContext 定義中将 readOnlyRootFilesystem 設定為 true。

10. 建立滾動更新政策

最後，為了確定您的 EKS 安全，制定滾動更新政策。滾動更新讓部署更新通過使用新執行個體增量更新 pod 執行個體來最大限度地減少應用程式停機時間。檢視Kubernetes 文檔中的此頁面以擷取更多詳細資訊。

另一點是在運作時進行漏洞掃描，因為存在供應鍊攻擊，是以即使您在 CI/CD 階段掃描了部署工件，您也需要檢視叢集真正得到了什麼。一般來說，基于代理的安全解決方案比“無代理”解決方案更好甚至更好。

Kubernetes 生态系統在不斷發展，其安全性也不例外。随着新威脅的出現和問題的暴露，工程師被迫跟上很多事情——這需要大量的時間和精力。

他們在 EKS 安全方面遇到的另一個挑戰是安全問題的優先級 - 根據應用程式的大小，優先級可能會變得非常耗時。自動化可以加快這一程序，為工程師赢得其他任務的時間。