為雲端管理員提供用Kubernetes進行容器編排時該如何制定安全策略的建議

Kubernetes是雲端環境最常用的容器編排（container orchestration）系統之一。因此跟其他被廣泛使用的應用程式一樣，它也成為吸引網路犯罪分子或其他惡意份子的誘人目標。雲端管理員在保護自己的部署時必須要特別注意三大領域的問題，因為它們可能對用Kubernetes驅動的容器化策略帶來威脅風險：

• 外部攻擊：來自組織外部的攻擊（任何未經身份認證的攻擊都屬此類）
• 設定不當問題：由不安全的設定所引起的問題
• 有漏洞的應用程式：由軟體或應用程式的漏洞所引起的問題

外部攻擊

圖1秀出了Kubernetes官方文件所列出Kubernetes部署或集群（cluster）的元件。

所有的通訊都是透過kube-api-server封送，這是個提供API服務的控制面板元件。它其實就是作為控制面板前端的REST API，並且可以讓使用者定義和控制所有的Kubernetes管理功能。使用API最簡單的方法是在命令列用命令kubectl（或是在OpenShift使用oc）。

如果攻擊者可以成功存取API就幾乎可以做到所有想做的事情。例如可以安裝惡意容器來從資料庫提取資訊，或使用所有的資源進行虛擬貨幣挖礦活動。

確保只有集群內的電腦以及管理集群的電腦可以存取此API，這樣有助於阻止外部攻擊者。

為了做到一點，雲端管理員需要記住kube-api-server預設會使用兩個端口：

• 端口8080只接受來自本地主機（localhost）的連線
  • 透過此端口對API的任何請求都會繞過身份認證和授權模組。
  • 可以用–insecure-bind-address標記讓此端口接受來自其他主機的連線。
  • 可以用–insecure-port標記來變更預設端口。

• 端口6443開放在公開IP地址上
  • 預設是第一個非localhost的網路介面，也被稱為”安全端口”。
  • 請求可以經過身份認證和授權來正確地發送。
  • 可以用–secure-port標記變更預設端口。

加強對端口8080和6443的安全防護並且注意有哪些事情不該做有助於防止入侵。

保護集群（cluster）抵禦外部攻擊的建議

• 利用防火牆規則來確保只有需要存取API的電腦可以進行連線。
• 不要用–insecure-bind-address選項在非本地主機開啟純文字端口。
• 使用像趨勢科技TippingPoint Threat Protection System解決方案這樣有SSL解密功能的入侵防禦系統（IPS）能夠監控對API的進出流量來偵測零時差和已知漏洞攻擊。

不當設定的問題

Kubernetes是個複雜的系統，它提供許多設定選項帶來了相當大的靈活度。但這些設定選項需要被正確地理解且以安全的方式設置，以免集群（cluster）遭受駭客入侵破壞。

光是身份認證設定一項在Kubernetes中就已經相當複雜了，因為有許多種可用的身份認證模式（基於角色、基於屬性或基於節點）。為了幫助管理此問題，雲端管理員可以用命令kubectl auth can-i查詢特定權限。Kubernetes使用者和服務帳號應該被鎖定只用所需的權限。

我們會特別在Kubernetes強調這一方面是因為我們已經看到太多不當設定的執行實例在全世界運行著。像圖2的Shodan快速掃描結果顯示出全球大約有3,000台主機的etcd（Kubernetes使用的鍵值伺服器，因此是不該對外暴露的服務）可以被公開存取。

雲端管理員另一件需要特別注意的事情是，如果沒有為特定命名空間（namespace）指定網路政策，則預設政策是允許所有對此命名空間（namespace）內所有Pod的進出流量。每個Pod都可以跟其他Pod對話，所以當攻擊者可以進入對外開放的Pod（比方說有網頁應用程式），就可以用它來連上其他Pod。這使得在發生入侵事件時更容易進行橫向移動。

最佳做法是預設拒絕存取，除了明確允許的流量之外。至少也必須有預設政策來拒絕進入流量。雲端管理員可以用Kubernetes官方文件所提供的程式碼來建立此政策。

保護集群（cluster）防止不當設定問題的建議

• 對所有的Kubernetes使用者和服務帳號進行徹底審核，確保只能進行必要的操作。此後要定期進行檢查以確保繼續執行。
• 考慮用如RedHat的OpenShift這樣整合Kubernetes的版本，儘管可能會有些受限，但卻提供現成可用的安全設定，。
• 檢視雲端服務商所提供指南內的相關說明。（根據集群被部署的地方，多數雲端服務商都有此指南）。也可以到Center for Internet Security查看CIS Kubernetes Benchmark。
• 確保Kubernetes所用的服務都有用防火牆加以保護並且沒有對外開放。
• 注意網路政策，預設要拒絕對內流量。

有漏洞的應用程式

就跟一般的伺服器和作業系統一樣，不管為保護Kubernetes集群付出了多少努力，它的安全等級取決於執行中和對外開放裡最脆弱的服務。容器和容器編排工具不僅有助於在異質環境中部署各種應用程式，還可以自由的排列組合使用應用程式。但它們不能解決所有的問題。事實上，容器的特性使得讓所有需要的地方保持更新變得更加困難，因為每個應用程式都有自己的一份程式庫副本。

如圖3所示，同一個程式庫可以安裝在不同基礎映像的多個映像內。而這些都需要被更新並安裝修補程式。這時候將趨勢科技Deep Security Smart check這樣的解決方案整合進DevOps流程可以有所幫助。

圖3. 程式庫被部署到多個映像，其中許多映像使用不同基礎，可能需要接受多方更新。

保護集群（cluster）解決有漏洞應用程式的建議

• 至少要確保所使用的容器映像都是最新版本且下載自可信任的來源。
• 使用如趨勢科技Deep Security Smart Check – Container Image Security這樣為容器設計的自動掃描技術來為應用程式掃描映像，成為持續整合和發布（CI/CD）流程的一部分。

透過雲端專屬防護來保護集群（cluster）

容器透過更好的流程隔離在DevOps和安全性（DevSecOps）方面向前邁進了一步。而Kubernetes這樣的容器編排工具提供了一層重要的抽象化，使其在可擴展環境中更加有用。雖然部署起來可能複雜，但按照上述步驟有助於確保雲端環境安全。如Hybrid Cloud Security(混合雲防護)和趨勢科技Cloud One這樣為雲端設計的安全解決方案可以為這些執行實例帶來更加有效的保護。

Hybrid Cloud Security提供威脅防禦能力來保護執行時期（runtime）中實體、虛擬和雲端工作負載（workload）以及容器。還可以在開發階段掃描容器映像。

Cloud One，一個給雲端建構者的安全服務平台，可以為CI/CD管道和應用程式提供自動化的保護。它還可以協助更快地識別和解決安全問題，並且縮短DevOps團隊的交付時間。它包括了：

• Workload Security：工作負載（workload）的執行時期（runtime）保護
• Container Security：自動化容器映像及登錄表掃描
• File Storage Security：提供給雲端檔案和物件儲存服務的安全防護
• Network Security：雲端網路層IPS安全防護
• Application Security：提供給無伺服器功能、API和應用程式的安全防護

@原文出處：Guidance on Kubernetes Threat Modeling 作者：Brandon Niemczyk（雲端安全研究負責人）