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

Amazon EKS 安全性到底是關(guān)于什么的？

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

由于 EKS 是 AWS 提供的一項服務(wù)，因此我們可以通過責任共擔模型開始討論安全性。一般來說，AWS 負責管理其云服務(wù)的安全性，而客戶則負責監(jiān)督工作負載的安全性。

AWS 通過 EKS 管理 Kubernetes 儀表板和控制平面，包括云提供商用來提供安全 Kubernetes 環(huán)境的所有基礎(chǔ)設(shè)施服務(wù)。

IAM、Pod、運行時、網(wǎng)絡(luò)安全、工作節(jié)點可擴展性和容器映像組件等自我管理的工作人員和 EKS 集群配置都屬于客戶。

客戶端安全包括數(shù)據(jù)安全、工作節(jié)點的升級和補丁，以及一切的安全配置，從數(shù)據(jù)平面和節(jié)點開始，到容器和操作系統(tǒng)結(jié)束?？蛻暨€需要配置安全組，允許 EKS 控制平面以安全的方式與虛擬私有云 (VPC) 通信。

AWS 用戶通過以下形式從云提供商處獲得有關(guān) EKS 安全性的支持：

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

AWS 在其托管的 Kubernetes 服務(wù)中內(nèi)置了 EKS 安全功能

如果每個 AWS 用戶決定使用此托管 Kubernetes 服務(wù)運行集群，以下是一些內(nèi)置的 EKS 安全功能。

AWS 機密管理器

在 Kubernetes 中，您可以創(chuàng)建鍵/值對并將它們帶到在您的 pod 內(nèi)運行的應(yīng)用程序中。如果它們包含任何敏感數(shù)據(jù)，您可以使用 Secret Store，它是由 AWS Secrets Manager（以及 AWS Parameter Store）實現(xiàn)的容器存儲接口驅(qū)動程序。

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

身份和訪問管理

身份和訪問管理 (IAM) 可以幫助希望控制對 AWS 資源的訪問的每個管理員。IAM 管理員可以根據(jù)特定策略設(shè)置誰可以登錄并擁有對 EKS 資源的權(quán)限。

用戶獲取 Kubernetes 資源的身份驗證和授權(quán)憑據(jù)。這個想法是只授予服務(wù)用戶訪問他們執(zhí)行工作所需的功能。

記錄和監(jiān)控

AWS 提供對 CloudWatch 的訪問，該日志存儲來自控制平面的診斷和審計日志。每個 EKS 控制平面都有自己的日志組。監(jiān)控這些日志以及時發(fā)現(xiàn)安全和生產(chǎn)問題是關(guān)鍵。還有 AWS CloudTrail，它記錄所有 EKS 活動并捕獲用戶、角色、AWS 服務(wù)或 EKS 控制臺請求進行的 API 調(diào)用。

EKS 安全的 10 個最佳實踐

1. 隔離 Kubernetes 節(jié)點

避免將 Kubernetes 節(jié)點直接暴露在公共網(wǎng)絡(luò)中。理想情況下，如果可能，此類節(jié)點應(yīng)位于單獨的網(wǎng)絡(luò)上，并且與一般公司網(wǎng)絡(luò)沒有直接連接。

如何使它工作？保持 Kubernetes 控制和數(shù)據(jù)流量隔離。否則，它們最終都會流過同一根管道。對數(shù)據(jù)平面的開放訪問意味著對控制平面的開放訪問，這對 EKS 安全來說是個壞消息。使用入口控制器配置節(jié)點并將其設(shè)置為僅允許通過網(wǎng)絡(luò)訪問控制列表 (ACL) 中的指定端口來自主節(jié)點的連接。

2、加強認證授權(quán)

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

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

3. 利用 Kubernetes 基于角色的訪問控制 (RBAC)

EKS 安全性的另一個與訪問相關(guān)的最佳實踐是使用 RBAC 來定義誰可以訪問 Kubernetes API 以及他們擁有什么權(quán)限。在 Kubernetes 1.6 及更高版本中，RBAC 通常默認啟用。鑒于 Kubernetes 結(jié)合了授權(quán)控制器，在打開 RBAC 時會禁用傳統(tǒng)的基于屬性的訪問控制 (ABAC)。

選擇特定于命名空間的權(quán)限而不是集群范圍的權(quán)限是一個好主意。即使在調(diào)試時，也要避免授予集群管理員權(quán)限。否則，您的容器安全性可能會受到影響。

4. 避免在環(huán)境變量中保密

確保您的對象在環(huán)境變量中使用機密，因為系統(tǒng)的其他部分可以輕松訪問環(huán)境變量。將機密用作文件或從 secretKeyRef 中受益以最大程度地減少潛在威脅。

5. 不要在特權(quán)模式下運行容器

如果您的部署有容器以特權(quán) (root) 模式運行，它允許容器訪問重要的主機資源。這可能會導(dǎo)致安全問題。避免在特權(quán)模式下運行容器或打開 podSecurityPolicy 并將特權(quán)參數(shù)設(shè)置為 false。這將確保容器無法在主機上運行需要 root 權(quán)限的進程。

6. 不要共享主機的 IPC 或網(wǎng)絡(luò)命名空間

查看您的 pod 并查看它們是否共享主機的 IPC 或網(wǎng)絡(luò)命名空間。為 pod 和主機進程間通信共享命名空間是危險的，因為它可能會打開對共享信息的訪問。出于這個原因，不應(yīng)允許 pod 訪問主機命名空間。

共享 pod 和主機網(wǎng)絡(luò)命名空間允許從 pod 對主機網(wǎng)絡(luò)進行網(wǎng)絡(luò)訪問。這打破了網(wǎng)絡(luò)隔離。在 PodSecurityPolicy 中將 hostNetwork 參數(shù)設(shè)置為 false 并在晚上睡得更好，因為您知道您的集群受到保護。

7.禁用NET_RAW

如果您的 Kubernetes 容器不放棄 NET_RAW 功能，您可能會在集群內(nèi)啟用廣泛的網(wǎng)絡(luò)攻擊。為確保 EKS 安全，請使用 Open Policy Agents、Kyverno 或 Kubernetes Pod Security 準入控制器等策略實施解決方案來遵循最佳行業(yè)實踐。

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

8. 檢查 Unsafe /Proc Mount

使用 unsafe /proc mount (procMount=Unmasked) 的部署允許其他人繞過容器運行時的默認屏蔽行為。如果將容器設(shè)置為 Unmasked /procs 掛載類型，則可能會將主機信息暴露給容器，從而導(dǎo)致潛在的數(shù)據(jù)泄漏或容器逃逸。設(shè)置 procMount=Default 以確保容器不暴露 /proc 的任何部分。

9. 不要將根文件系統(tǒng)用于容器安全

如果您的容器在沒有只讀根文件系統(tǒng)的情況下運行，請做好應(yīng)對麻煩的準備。使用只讀文件系統(tǒng)可以防止各種惡意二進制文件寫入系統(tǒng)或被攻擊者接管系統(tǒng)。確保容器僅使用只讀文件系統(tǒng)，并在 Pod securityContext 定義中將 readOnlyRootFilesystem 設(shè)置為 true。

10. 建立滾動更新策略

最后，為了確保您的 EKS 安全，制定滾動更新策略。滾動更新讓部署更新通過使用新實例增量更新 pod 實例來最大限度地減少應(yīng)用程序停機時間。查看Kubernetes 文檔中的此頁面以獲取更多詳細信息。

另一點是在運行時進行漏洞掃描，因為存在供應(yīng)鏈攻擊，因此即使您在 CI/CD 階段掃描了部署工件，您也需要查看集群真正得到了什么。一般來說，基于代理的安全解決方案比“無代理”解決方案更好甚至更好。

Kubernetes 生態(tài)系統(tǒng)在不斷發(fā)展，其安全性也不例外。隨著新威脅的出現(xiàn)和問題的暴露，工程師被迫跟上很多事情——這需要大量的時間和精力。

他們在 EKS 安全方面遇到的另一個挑戰(zhàn)是安全問題的優(yōu)先級 - 根據(jù)應(yīng)用程序的大小，優(yōu)先級可能會變得非常耗時。自動化可以加快這一進程，為工程師贏得其他任務(wù)的時間。