Kubernetes部署的最佳安全實踐

編者按：本文是由 Aqua Security 的Amir Jerbi 和Michael Cherny 所寫，基於他們從本地和雲端上收集到的實際數據，描述了Kubernetes 部署的最佳安全實踐。

Kubernetes提供了許多能夠極大地提升應用程序安全性的選項。配置它們要求你熟悉 Kubernetes 以及其部署的安全要求。

咱們在這裏強調的最佳實踐與容器生命週期相匹配：構建、分發和運行，並專門爲Kubernetes量身打造。咱們在運行在Google雲平臺的kubernetes上使用了這些安全實踐。

如下是咱們部署安全的Kubernetes應用的建議：

◆ 確保鏡像沒有漏洞

運行有漏洞的容器使你的環境會遭受損害的風險。許多攻擊能夠簡單地經過將軟件升級爲沒有漏洞的版原本避免。

實現Continuous Security Vulnerability Scanning （持續安全漏洞掃描）——容器可能包括含有已知漏洞（CVE）的過期包。新的漏洞天天都會發布，因此這不是一個「一次性」的工做，對鏡像持續進行安全評估是相當重要的。

按期對環境進行安全更新，一旦發現運行中容器的漏洞，你應該及時更新鏡像並從新部署容器。儘可能避免直接更新（例如， ‘apt-update’ ）到正在運行的容器，由於這樣打破了鏡像與容器的對應關係。

使用Kubernetes滾動升級功能升級容器很是簡單，該功能容許經過升級鏡像到最新版原本逐步更新正在運行的容器。

◆ 確保在你的環境中只使用受權鏡像

若是沒法保證只運行符合組織策略的鏡像，那麼組織會面臨運行脆弱甚至惡意容器的危險。從未知的來源下載和運行鏡像是危險的，它至關於在生產服務器上運行未知服務商的軟件，因此千萬別這樣作！

使用私有鏡像存儲你的合法鏡像，這樣能大量減小可能進入到你的環境的鏡像數量。將成安全評估（如漏洞掃描）加入持續集成（CI）中，使其成爲構建流程的一部分。

持續集成應確保只使用審查經過的代碼來構建鏡像。當鏡像構建成功後，要對它進行安全漏洞掃描，而後只有當沒有發現問題時，鏡像才能被推送私有鏡像倉庫。在安全評估中失敗的鏡像不該該被推送到鏡像倉庫中。

Kubernetes鏡像受權插件的工做已經完成（預計隨kubernetes 1.4發佈）。該插件容許阻止未受權鏡像的分發。具體請查看此PR （https://github.com/kubernetes...）。

◆ 限制對Kubernetes 節點的直接訪問

應該限制SSH登錄Kubernetes節點，減小對主機資源未受權的訪問。應該要求用戶使用「 kubectl exec 」命令，此命令可以在不訪問主機的狀況下直接訪問容器環境。

你可使用kubernetes受權插件來進一步控制用戶對資源的訪問。它容許設置對指定命名空間、容器和操做的細粒度訪問控制規則。

◆ 建立資源間的管理界限

限制用戶權限的範圍能夠減小錯誤或惡意活動的影響。Kubernetes 命名空間容許將資源劃分爲邏輯命名組。在一個命名空間中建立的資源對其餘命名空間是隱藏的。

默認狀況下，用戶在Kubernetes 集羣中建立的每一個資源運行在名稱爲「default」的默認空間內。你也能夠建立額外的命名空間並附加資源和用戶給它們。你可使用Kubernetes 受權插件來建立策略，以便將不一樣用戶的訪問請求隔離到不一樣的命名空間中。

例如：如下策略將容許 ‘alice’ 從命名空間 ‘fronto’ 讀取pods。

◆ 定義資源配額

運行沒有資源限制的容器會將你的系統置於DoS或被其餘租戶干擾的風險中。爲了防止和最小化這些風險，你應該定義資源配額。

默認狀況下，Kubernetes 集羣中的全部資源沒有對CPU 和內存的使用限制。你能夠建立資源配額策略，並附加到Kubernetes命名空間中來限制Pod對CPU和內存的使用。

下面的例子將限制命名空間中Pod 的數量爲4個，CPU使用在1和2之間，內存使用在1GB 和 2GB 之間。

compute-resources.yaml：

分配資源配額到命名空間：

◆ 實現網絡分段

在相同的Kubernetes集羣上運行不一樣的應用程序會致使惡意程序攻擊其餘應用程序的風險。因此網絡分割對確保容器只與那些被容許的容器進行通訊很重要。

Kubernetes 部署的挑戰之一是建立Pod,服務和容器之間的網絡分段。緣由在於容器網絡標識符（IP地址）動態的「天性」，以及容器能夠在同一節點或節點間進行通訊的事實。

谷歌雲平臺的用戶受益於自動防火牆規則，可以防止跨集羣通訊。相似的實現可使用網絡防火牆或SDN解決方案部署。這方面的工做由Kubernetes 網絡特別興趣小組（Special Interest Group）完成，這將大大提升 pod到pod 的通訊策略。

新的網絡策略API應該解決 Pod之間建立防火牆規則的需求，限制容器化能夠進行的網絡訪問。

下面展現了只容許前端（frontend）Pod訪問後端（backend）Pod的網絡策略：

點擊這裏（http://blog.kubernetes.io/201...）閱讀更多網絡策略的內容。

◆ 將安全環境應用到你的Pods和容器中

當設計你的容器和 pods時，確保爲你的pods，容器和存儲卷配置安全環境。安全環境是定義在yaml文件中的一項屬性。它控制分配給 pod/容器/存儲卷的安全參數。一些重要的參數是：

如下是一個具備安全環境參數的pod 定義示例：

◆ 記錄全部的事情

Kubernetes提供基於集羣的日誌，容許將容器活動日誌記錄到一個日誌中心。當集羣被建立時，每一個容器的標準輸出和標準錯誤均可以經過運行在每一個節點上的Fluentd 服務記錄到Stackdriver或Elasticsearch中，而後使用Kibana進行查看。

◆ 總結

Kubernetes 對建立安所有署提供多種選擇，沒有適合全部狀況的萬能解決方案，因此熟悉這些安全選項、瞭解它們如何提升應用程序安全性是很重要的。

咱們推薦這篇文章中提到的安全實踐，將Kubernetes的靈活配置能力加入到持續集成中，自動將安全性無縫融合到整個流程中。

時速雲每兩週將於微信羣進行技術分享，感興趣的小夥伴能夠添加微信號（tenxcloud6）時速雲小助手，而後咱們會拉您進羣

本文由時速雲翻譯，如若轉載，需註明轉載自「時速雲」

原文連接: http://blog.kubernetes.io/201...