容器正在改變軟件開發。作為CI/CD的新基礎，容器為你提供了一種快速，靈活的方式來部署應用程序，API和微服務，而數字化成功與否取決于可擴展性和性能。但是，容器和容器編排工具（例如Kubernetes）也是黑客們的熱門目標，如果它們沒有得到有效的保護，它們可能會使你的整個環境面臨風險。在本文中，我們將討論容器堆棧每一層安全的最佳實踐。

了解容器安全的含義很重要。作為依賴共享內核的應用程序層構造，容器可以比VM更快地啟動。在配置方面，容器也比VM靈活得多，并且可以執行掛載存儲卷到禁用安全功能的所有操作。

如果繞過容器隔離機制并在主機上獲得特權時，該容器甚至可以在黑客的控制下以root用戶身份運行，然后你就陷入了真正的麻煩。

你可以采取一些措施，將壞蛋拒之門外。

第0層–內核

Kubernetes是一個開源平臺，旨在自動執行容器的部署，擴展和編排，正確配置它可以幫助你增強安全性。在內核級別，你可以：

查看允許的系統調用，并刪除所有不必要或不需要的系統調用

使用gVisor或Kata Containers等容器沙箱進一步限制系統調用

驗證你的內核版本已打補丁并且不包含任何現有漏洞

第1層–容器

靜態

靜態的容器安全性側重于將用于構建容器的Docker鏡像。首先，通過刪除不必要的組件，程序包和網絡實用程序來減少容器的攻擊面-精簡越多越好。考慮使用僅包含應用程序及其運行時依賴項的 distroless鏡像。

“Distroless （https://github.com/GoogleCloudPlatform/distroless） 是谷歌內部使用的鏡像構建文件，包括 Java 鏡像，Node，Python 等鏡像構建文件，Distroless 僅僅只包含運行服務所需要的最小鏡像，不包含包管理工具，shell 命令行等其他功能。

接下來，確保僅從已知可信任的來源中提取鏡像，然后掃描它們中的漏洞和配置錯誤。在你的CI/CD流水線和構建過程中檢查它們的完整性，并在運行之前進行驗證和批準，以確保黑客未安裝任何后門程序。

運行

打包鏡像后，就該進行調試了。臨時容器將使你可以交互式地調試運行中的容器。監視異常和可疑的系統級事件，這些事件可能是破壞的跡象，例如，產生了意外的子進程，在容器內運行的shell或意外讀取了敏感文件。

開源運行時安全工具Falco可以為你提供幫助，它通過以下方式使用系統調用來保護和監視系統：

在運行時從內核解析Linux系統調用

針對強大的規則引擎聲明流

違反規則時發出警報

第2層–工作負載（Pod）

Pod是Kubernetes內的部署單位，是容器的集合，可以共享常見的安全定義和對安全敏感的配置。Pod安全上下文可以設置給定Pod的特權和訪問控制，例如：

容器內的特權容器

進程和卷的組和用戶ID

細粒度的Linux功能（刪除或添加），例如Sys.time

沙箱和強制訪問控制（seccomp，AppArmor，SELinux）

文件系統權限

特權升級

為了加強Pod級別的防御能力，你可以實施嚴格的Pod安全策略，以防止危險的工作負載在集群中運行。要獲得對Pod安全性的更大靈活性和更精細的控制，請考慮使用OPA Gatekeeper項目實施的開放策略代理（OPA）。

第3層–網絡

默認情況下，所有Pod都可以不受限制地與集群中的所有其他Pod對話，這從攻擊者的角度來看非常有利。如果工作負載受到威脅，攻擊者可能會嘗試探測網絡并查看他們還可以訪問什么。Kubernetes API也可以從Pod內部訪問，從而提供了另一個豐富的目標。

嚴格的網絡控制是容器安全的關鍵部分-pod到pod，集群到集群，由內而外和由內而外。使用內置的網絡策略來隔離工作負載通信并構建精細的規則集。考慮實現服務網格以控制工作負載之間的流量以及入口/出口，例如通過定義namespace到namespace的流量。

應用層（L7）攻擊–服務器端請求偽造（SSRF）

最近，我們已經聽到很多關于SSRF攻擊的消息，這也就不足為奇了。在API與其他API對話的云原生環境中，SSRF尤其難以防御。webhooks尤其臭名昭著。一旦找到目標，就可以使用SSRF升級特權并掃描本地Kubernetes網絡和組件，甚至在Kubernetes指標端點上轉儲數據，以了解有關環境的有價值的信息-并有可能將其完全接管。

應用層（L7）攻擊–遠程執行代碼（RCE）

RCE在云原生環境中也非常危險，這使得在容器內運行系統級命令來抓取文件，訪問Kubernetes API，運行鏡像處理工具以及破壞整個機器成為可能。

應用層（L7）防御

保護的第一條規則是遵守安全的編碼和體系結構實踐，這可以減輕你的大部分風險。除此之外，你還可以沿兩個方向對網絡防御進行分層：南北方向，以監視和阻止針對你的應用程序和API的惡意外部流量；東西方向，以監視從一個容器到另一個容器，從一個集群到另一個集群以及從云到云的流量，以確保你不會受到受損的Pod的傷害。

第4層-節點

節點級安全性同樣重要。為防止容器在VM或其他節點上爆發，請限制對節點以及控制平面的外部管理訪問，并注意開放的端口和服務。使基本操作系統保持最少，并使用CIS基準對其進行加固。最后，確保像其他任何VM一樣掃描和修補節點。

第5層–集群組件

Kubernetes集群中發生了各種各樣的事情，并且沒有保護它的多合一工具或策略。在較高的級別上，你應該專注于：

API服務器–檢查你的訪問控制和身份驗證機制，并對動態Webhooks，Pod安全策略以及對Kubernetes API的公共網絡訪問執行其他安全檢查；

訪問控制-使用基于角色的訪問控制（RBAC）對API服務器和Kubernetes secret實施最低特權原則

服務帳戶令牌–為了防止未經授權的訪問，請限制對服務帳戶以及存儲服務帳戶令牌的所有secret的權限

審核日志記錄-確保已啟用

第三方組件–注意帶入集群中的內容，以便知道集群中正在運行的內容以及原因

Kubernetes版本– Kubernetes可以像任何其他系統一樣具有漏洞，并且必須及時進行更新和修補。

Kubelet配置錯誤–負責容器編排以及與容器運行時的交互，Kubelet可能會被濫用和攻擊，以試圖提升特權。

Kubernetes的安全性似乎令人望而生畏，但是通過在堆棧的每一層上遵循最佳實踐，可以使容器與環境達到相同的高級別保護。因此，你可以享受快速，敏捷的開發帶來的好處。

參考：https://www.kubernetes.org.cn/9231.html

文章轉載：K8S中文社區

（版權歸原作者所有，侵刪）

編輯：jq