微軟在臺剖析Kubernetes資安風險，近年K8s攻擊技術手法有3大面向值得關注

隨著輕量虛擬化的容器技術（container）成為熱門應用，管理容器化的Kubernetes（K8s）系統也備受關注，而了解容器化環境的各種威脅與安全風險，更是成為近年矚目焦點，特別的是，在2020年4月，微軟仿效MITRE ATT&CK，發布了Kubernetes攻擊威脅矩陣（Threat matrix for Kubernetes），期望剖析攻擊面，並建立業界面對容器資安威脅的共通描述語言。

相隔一年，微軟首度更新K8s攻擊威脅矩陣，今年4月該公司首席雲端解決方案架構師李匡正提出更多說明，闡釋K8s值得關注的安全議題。

值得關注的安全議題，包含網路安全政策、敏感資料與應用程式面

基本上，K8s攻擊威脅矩陣參考MITRE ATT&CK框架，將相關攻擊技術手法系統予以歸納，各戰略階段名稱幾乎與ATT&CK相同，但與現行ATT＆CK相比，數量顯然較少。

以K8s攻擊威脅矩陣而言，目前最新版共畫分10個階段（第一版為9個階段），從入侵初期、執行、權限提升、防禦逃避、憑證存取、發現、橫向移動、收集，以至最終的衝擊，並統整歸納出48個技術手法（第一版為40項技術手法）。

而在這些統整的這些K8s攻擊技術手法中，近年有那些安全議題值得關注？李匡正表示，可從三大面向著手，包括：網路安全政策、敏感資料保存與應用程式面。

首先，是在網路安全政策方面，以攻擊手法而言，是列為發現階段的Network Mapping，以及橫向移動階段的Clusterinternal networking。

對於網路安全政策面的資安風險，李匡正表示，部署於同一K8s叢集的Pod與Pod之間，預設是允許相互連線，也就是不會有任何攔阻，而這樣的設計並不安全。

他進一步解釋原因。以傳統規畫機房為例，每個網段可能會配置防火牆，作業系統本身有防火牆，而在雲端每個虛擬網路的網段，也都會有類似網火牆的機制。

因此，在K8s 1.7版本之後，CNCF基金會開始定義Network policy規格，來因應這樣的需求，而這等同於實體網路環境中防火牆的角色，可定義Pod與Pod之間流量進出規則，市面上，已有多套實作Network Policy的機制，李匡正表示，若以Azure Kubernetes Service（AKS）為例，微軟本身的相關實作，稱為Azure Network Policy，也支援Calico專案。

他特別提醒，雖然開發人員在測試環境中會盡量簡化應用程式的架構，不過在正式營運環境中，需考慮到透過這樣網路政策，預設就要擋掉所有對外及對內的流量，在依照政策規則，開放特定網路埠供特定的Pod來使用。

第二個常見的風險，在於敏感資料保存方面的K8s Secrets，而對應的攻擊手法，主要是列於該威脅矩陣中，在憑證存取階段的List K8s Secrets。

李匡正說，K8s提供給開發者用來存放敏感資訊的機制稱為Secrets，可存放access token、帳號密碼與資料庫連線字串等機密資訊，不過，由於K8sSecrets預設並沒有加密，只是用Base64編碼寫入，因此懂得寫程式的人，都能用Base64解碼的方式將這些機密還原。

因此，在K8s的相關文件，已經強調須使用加密的方案來達到安全。李匡正表示，在Azure環境當中，他們提供了HSM硬體加密的Azure Key Vault，可與K8s Secrets結合應用。

同時，雖然套用加密，但在存取時還是會解密， 因此，做到以角色為基礎的存取控制（RBAC）就相當重要。他舉例，在開發測試環境中，往往可能為了除錯方便，而沒有做到細部的存取管控，但是，到了正式環境，存取管控千萬不能省略，不論是開發人員、系統管理人員的權限，都需要被定義清楚。

因此，對於K8s Secrets的基本安全防護，他提醒，必須使用加密解決方案，以及制定嚴謹存取權限管控。

第三個常見的K8s資安風險面向，是在應用程式方面，對應的攻擊技術手法有4項，分別是入侵初期階段的Using cloud credentials、Compromised images in registry與Application vulnerability，以及橫向移動階段的Container service account。

在雲端環境中，系統管理員對於整個叢集的管控上，用戶驗證機制如何設定？是否開啟多因素驗證？ 都是至關重要的事情， 還有惡意映像檔的風險，包括：下載來歷不明的映像檔， 或是容器映像檔建立時本身已經被發現有資安漏洞，當用戶從網路上的免費Docker Hub下載這些映像檔使用，有可能會造成嚴重的問題，而上述面向，經常是攻擊發起點。

李匡正也提醒大家注意應用程式的弱點，雖然這與容器無關，不過，當應用程式有弱點，且一併進到K8s環境之際，這些弱點也會浮現。

需仰賴多重防護配合，以達到安全性要求

對於上述K8s攻擊面的防護，雖然初期測試環境可能很簡單，但在正式環境下需要注意一些細節，因為要做到相關的要求，背後其實是要有多重防護的配合。

以Azure環境而言，例如：包含Azure Firewall Subnet、Azure App Gateway Subnet，可控制由內往外的網路流量、搭配網站應用程式防火牆（WAF）保護，以及在Azure Kubernetes Serveice Subnet中，將透過內部負載平衡器來連接，並藉由Calico提供網路政策給Kubernetes使用，透過Azure AD Pod Identity，讓Pod存取各項Azure服務。之後，再經過Azure VNET內部私有IP位址，存取Azure File與Azure Container Registry。

李匡正特別強調，要讓人員經手接觸機密資訊的機會降低，透過CI/CD工具將整個環節串起來，而微軟本身也使用WhiteSource公司發展的Bolt，來執行開放原始碼軟體套件的資安監控。此外，他也提醒，開發測試與正式營運應完全分開，避免共同環境底下的資安風險。

李匡正表示，企業若要防護K8s攻擊，需注意多種機制的搭配，顧及許多細節才能要做到相關的要求，他並以Azure環境下來說明。同時，他也提醒，開發測試與正式營運的作業區應完全分開，避免因共同環境而產生資安風險。

新增8項攻擊技術手法，以Sidecar injection最受關注

另外值得一提的是，由於今年微軟K8s攻擊威脅矩陣改版，對於相關攻擊技術手法的統整，作了更動，當中刪除3項並額外增加8項，似乎透露K8s在基本安全性的提升，以及新的威脅趨勢，到底當中有哪些變化值得關注？

對此問題，李匡正表示，在本次改版當中，微軟已經移除了儀表板相關的攻擊手法，包括：Exposed Kubernetes Dashboard，以及Access Kubernetes dashboard。

主要原因是，對於K8s儀表板方面的威脅，之前微軟已經建議，不要在網際網路上暴露Kubernetes儀表板，同時，只應授與儀表板服務帳號必要的權限等。

以實際狀況來看，包括微軟AKS，以及Google Kubernetes Engine（GKE）等服務，現在都關閉K8s儀表板，用戶需從Azure Portal、Google CloudConsole來檢視資訊。同時，在新版K8s攻擊框架中，也用涵蓋範圍更廣泛的exposed sensitive interfaces，取代相關威脅。

至於Access tiller endpoint項目被移除，主要是K8s應用程式管理工具Helm第3版中，不再需要使用API通訊工具Tiller。換言之，若是現在仍繼續使用Helm第2版與Tiller，在安全面是有疑慮的。

關於新增的攻擊手法中，何者特別值得關注？ 李匡正表示，以Sidecar injection為例，目前Kubernetes邊車模式（Sidecar）大量用在Service Mesh，而在Service Mesh扮演邊車Proxy的Pod，如果被注入惡意軟體，代表主程式的所有網路存取，都可能會被這類資安威脅攔截，如此將造成很嚴重的問題。

微軟Azure團隊於今年3月針對K8s威脅矩陣進行首度改版，相關彙整技術手法有些變化，新增8項並刪除3項。（圖片來源：微軟）