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 安全方面遇到的另一個挑戰是安全問題的優先級 - 根據應用程序的大小，優先級可能會變得非常耗時。自動化可以加快這一進程，為工程師贏得其他任務的時間。