2020年4月，微軟官方發布了《Kubernetes威脅矩陣》第一版，首次嘗試以系統方式描繪Kubernetes威脅態勢。該報告采用了MITER ATT&CK?框架結構，希望與行業標準盡可能保持一致。
（編者注：Kubernetes是由Google在2014年開源的容器集群管理平臺，用于管理容器化環境中的工作負載和服務。）
自去年的威脅矩陣報告發布以來，情況發生了如下變化：
Kubernetes工作負載吸引到更多攻擊者的注意，新的威脅也由此而生；
安全社區采納了該矩陣，并添加更多安全保障技術；
隨著Kubernetes的發展，其默認安全性得到顯著提升，因此上份報告中的某些方法已經不再適用。
3月23日，微軟安全發布了《Kubernetes威脅矩陣》第二版，將上述變化納入其中。第二版報告添加了微軟研究人員發現的新方法與社區解決方案，并淘汰了部分過時內容，因為其不再適用于Kubernetes的較新版本。報告還添加了“數據收集”這一新增單元。
淘汰了哪些內容？
Kubernetes一直快速發展，默認安全水平也在持續提升。去年矩陣中出現的某些技術已經不適用于較新環境，因此我們決定淘汰以下內容：
ONE
1、Kubernetes儀表板暴露
Kubernetes儀表板的使用率近來有所下降。各類云托管集群（包括微軟AKS與谷歌GKE）紛紛棄用這項服務，轉而通過門戶內的集中界面提供等效功能。此外，最新版本的Kubernetes儀表板已經要求身份驗證，因此這種意外暴露的風險已經顯著降低。同理，我們還取消了橫向移動策略下的“訪問Kubernetes儀表板”部分。但請注意，Kubernetes的較舊版本（包括手動安裝儀表板的較新集群）仍會受到這類問題的影響。為了體現最新情況，我們將此問題的概念匯總到新的“敏感界面暴露”部分（詳見下文）。
TWO
2、Tiller被訪問
從版本3開始，Helm不再使用其服務器端組件Tiller。這是一項重要安全改進，因此現在Helm在默認情況下將使用kubeconfig文件中的用戶憑證執行操作。但使用較舊版本的Helm用戶仍會受到此問題的影響。
威脅矩陣中的新內容
ONE
1.、初始訪問
敏感接口暴露
將敏感接口直接暴露在互聯網下當然會引發安全風險。某些流行框架在設計上也沒有考慮到直接暴露于互聯網中的情況，因此默認并不要求身份驗證。一旦開放其中的敏感接口，攻擊者很可能以未授權方式訪問敏感接口，進而在集群當中運行代碼或部署容器。目前，已經發現的此類敏感接口包括Apache NiFi、Kubeflow、Argo Workflows、Weave Scope以及Kubernetes儀表板。
TWO
2.、代碼執行
Sidecar注入
Kubernetes Pod是一組共享存儲與網絡資源的單一或多個容器。Sidecar容器是專用術語，代表與主容器并排放置的其他容器。例如，服務網格（service-mesh）代理在應用程序的Pod中充當Sidecar。攻擊者可以將Sidecar容器注入至集群內的合法Pod，借此運行代碼并隱藏行跡。相較于在集群中運行獨立Pod，這種方法無疑更難被發現。
THREE
3、持久駐留
惡意準入控制器
準入控制器（admission controller）是Kubernetes提供的組件，負責攔截并修改指向Kubernetes API服務器的請求。準入控制器分為兩種類型：驗證控制器與變異控制器。顧名思義，變異準入控制器能夠修改攔截到的請求并更改其屬性。Kubernetes還提供名為MutatingAdmissionWebhook的內置通用準入控制器，其行為由用戶在集群中部署的準入webhook決定。攻擊者可以使用此類webhook持久駐留在集群當中。例如，攻擊者可以攔截并修改集群內的Pod創建操作，借此向所有新創建的Pod添加惡意容器。
FOUR
4、憑證訪問
訪問托管身份憑證
托管身份，是指由云服務商負責托管的身份，我們可以將其分配給虛擬機等多種云資源。這些身份用于對云服務進行身份驗證。身份secret信息由云服務商全面托管，確保用戶無需因憑證管理而分神。應用程序則訪問實例元數據服務（IMDS）以獲取身份令牌。一旦獲得對Kubernetes Pod的訪問權，攻擊者就可以利用指向IMDS端點的訪問權限獲取托管身份令牌，進而訪問各類云資源。
惡意準入控制器
除了持久駐留之外，惡意準入控制器還可用于訪問憑證信息。Kubernetes提供內置準入控制器ValidatingAdmissionWebhook。與MutatingAdmissionWebhook類似，這種準入控制器同樣具有通用性且具體行為由部署在集群中的準入Webhook決定。攻擊者可以使用此Webhook攔截指向API服務器的請求，借此記錄secret信息及其他敏感信息。
FIVE
5.、橫向移動
CoreDNS污染
CordDNS是由Go語言編寫而成的模塊化域名系統（DNS）服務器，目前由云原生計算基金會（CNCF）負責管理。CoreDNS也是Kubernetes中使用的主要DNS服務。用戶可以通過corefile文件修改CoreDNS的具體配置。在Kubernetes中，此文件存儲在ConfigMap對象當中，此對象又位于kube-system命名空間內。如果攻擊者具有修改ConfigMap的權限（例如通過使用容器的服務賬戶），即可更改集群的DNS行為、實現DNS污染并奪取其他服務的網絡身份。
ARP污染與IP欺詐
Kubernetes提供多種可在集群內使用的網絡插件（被稱為容器網絡接口，簡稱CNI），并在多數場景下默認使用。在這類配置中，各個節點（cbr0）上都創建有一個網橋，且不同節點使用veth接入其他節點。跨Pod流量將通過網橋（2級組件）傳輸，意味著攻擊者完全可以在集群當中執行ARP污染。一旦攻擊者成功訪問到集群內的某一Pod，即可執行ARP污染并對其他Pod進行流量欺詐。如此一來，攻擊者即可實現橫向轉移，例如實施DNS欺詐或竊取其他Pod的云身份（CVE-2021-1677）。
SIX
6.、數據收集
在本次更新中，我們還在報告中新增了“數據收集”策略。在Kubernetes中，數據收集是指攻擊者從集群處或者經由集群進行數據收集的方法。
來自私有注冊表的鏡像
集群中運行的鏡像可以被存儲在私有注冊表內。要提取這些鏡像，容器運行時引擎（Docker或者containerd）需要具備指向這些注冊表的有效憑證。如果注冊表由云服務商負責托管，則在Azure容器注冊表（ACR）或者Amazon彈性容器注冊表（ECR）等服務中，我們需要使用云憑證在注冊表上完成身份驗證。一旦攻擊者能夠訪問到集群，則有可能順利訪問私有注冊表并從中提取鏡像。例如，攻擊者可以按照“訪問托管身份憑證”部分中提到的方式使用托管身份令牌。同樣，在EKS中，攻擊者也可以使用默認綁定至節點IAM角色的AmazonEC2ContainerRegistryReadOnly策略。
保護您的容器化環境
要為容器化環境構建行之有效的安全解決方案，我們首先需要邁出了解容器化環境這重要的第一步。希望此次修訂后的《Kubernetes威脅矩陣》報告能夠幫助大家發現針對Kubernetes的各類威脅行為，厘清實際防御能力與當前威脅形勢之間的實際差距。