《云原生安全： 攻防實踐與體系構建》解讀：攻防對抗篇

與云原生技術紅利相伴而來的是安全威脅和風險。近年來，在云原生蓬勃發展的產業背景下，新的安全漏洞、安全事件同樣層出不窮。隨著越來越多重要業務云原生化，安全已經成為業務落地的必要保障條件。有哪些因素會讓云原生環境變得不安全？怎樣保障云原生安全？《云原生安全： 攻防實踐與體系構建》希望能夠給出一個答案。本文為《云原生安全： 攻防實踐與體系構建》一書的精華解讀，重點介紹云原生環境下的攻防對抗。本書已在京東等各大平臺上發售，歡迎購買。

1. 容器與編排系統的威脅和風險

作為云原生生態的兩大技術基石，容器和編排系統（以Kubernetes為代表）的安全性對集群來說非常重要。然而，容器與編排系統面臨的威脅和風險客觀存在，我們必須了解并認真對待這些威脅風險。

針對容器鏡像的軟件供應鏈攻擊：隨著容器技術的普及，容器鏡像成為軟件供應鏈中重要的一部分。然而，業務依賴的基礎鏡像無論是存在安全漏洞還是包含惡意代碼，潛在危害都可能比外部發起的攻擊嚴重。這種攻擊方式主要包含兩種類型：鏡像漏洞利用和鏡像投毒。前者指的是鏡像本身存在漏洞時，依據鏡像創建并運行的容器也通常會存在相同漏洞，攻擊者利用鏡像中存在的漏洞去攻擊容器，往往具有事半功倍的效果。后者指的是攻擊者通過某些方式——如上傳鏡像到公開倉庫、入侵系統后上傳鏡像到受害者本地倉庫以及修改鏡像名稱假冒正常鏡像等，欺騙、誘導受害者使用攻擊者指定的惡意鏡像創建并運行容器，從而實現入侵或利用受害者的主機進行惡意活動的行為。

容器逃逸：與其他虛擬化技術類似，逃逸是最為嚴重的安全風險，直接危害了底層宿主機和整個云計算系統的安全。根據層次的不同，容器逃逸的類型可以分為三類：危險配置、掛載導致的容器逃逸；相關程序漏洞導致的容器逃逸；內核漏洞導致的容器逃逸。另外，在2020年Black Hat北美會議上，安全容器也首次被成功逃逸。

資源耗盡型攻擊：容器運行時默認情況下并未對容器內進程在資源使用上做任何限制，以Pod為基本單位的容器編排管理系統也是類似的，Kubernetes在默認情況下同樣未對用戶創建的Pod做任何CPU、內存使用限制。限制的缺失使得云原生環境面臨資源耗盡型攻擊風險。

Kubernetes控制權限陷落風險：Kubernetes集群的管理控制權限實質上等價于集群內每臺節點的root權限之和，其重要性可想而知。然而，不安全的組件配置、權限提升漏洞和容器逃逸漏洞等安全問題和風險都可能導致攻擊者獲取Kubernetes控制權限，從而實現對整個集群的控制，后果非常嚴重。

針對Kubernetes的拒絕服務攻擊：Kubernetes通過一系列機制來保證云原生應用的持續穩定運行，然而，如果集群控制平面自身遭受拒絕服務攻擊，后果不堪設想。拒絕服務攻擊有多種類型，常見的是基于流量的拒絕服務攻擊和基于漏洞的拒絕服務攻擊。傳統環境和云原生環境的流量攻擊的差異性較小，基于漏洞的拒絕服務攻擊則不然，存在于云原生組件的拒絕服務漏洞很可能并不存在于傳統主機環境。諸如CVE-2019-11253、CVE-2019-9512等拒絕服務漏洞可能導致Kubernetes API Server陷入癱瘓。

云原生網絡安全風險：默認情況下，Kubernetes集群中所有pod組成了一個小型的局域網絡，那么就可能發生像中間人攻擊這樣的針對局域網的攻擊行為。通過ARP欺騙、DNS劫持等技術，攻擊者能夠潛伏在集群中，不斷對其他Pod的網絡流量進行竊聽，甚至可以悄無聲息地劫持、篡改集群其他Pod的網絡通信，危害極大。

以上是我們可以從容器和編排系統的角度梳理出的部分威脅風險，除此以外，在具體應用場景中，微服務、服務網格和Serverless的安全風險也不容忽視。安全具有木桶效應，只有全面防御，方能萬無一失。本書第三章、第四章對這些威脅進行了深入而詳盡的分析。

2. 復雜的安全問題

各行各業都在積極上云，然而，如何安全上云？進一步地，如何安全應用云原生技術促進產業發展？云原生環境仍然存在許多安全問題亟待解決。在云原生技術的落地過程中，安全是必須要考慮的重要因素。

通過對過去云原生安全事件的梳理，我們發現“服務暴露”、“數據泄露”和“惡意挖礦”是三類高發安全問題。這些安全問題可能不僅可能導致集群被控制、敏感信息被竊取、大量資源被濫用，還可能引起一系列嚴重的社會安全問題（如關鍵基礎設施出現問題、醫療信息被不法分子利用等），亟需人們的重視。

本書第六章對典型的云原生安全事件的前因后果進行了剖析，供大家在云原生技術落地的過程中進行參考。

3. 云原生異常檢測

基于規則的已知威脅檢測

幾乎任何一個有意義的進程在運行期間都會執行系統調用（System call），惡意進程也不例外，甚至調用得更多更為頻繁。另外，惡意進程的調用方式往往具有區別于正常進程的特征。

例如，2019年著名的runC容器逃逸漏洞CVE-2019-5736，它的特征是，在利用過程中需要以/proc/self/exe為路徑參數執行open系統調用，在后續過程中，還會以/proc/self/fd/為路徑參數前綴采用寫方式執行open系統調用，以覆蓋宿主機上的runC二進制文件。這樣的參數內容在容器內業務進程中非常罕見的。因此，特定系統調用+特定參數就是該漏洞的明顯特征。

同CVE-2019-5736漏洞利用一樣，多數攻擊行為都可以通過直接檢測某次系統調用或連續幾次系統調用的異常來判斷是否發生了某一類攻擊行為。

基于行為模型的未知威脅檢測

檢測系統定期收集集群各宿主機節點上所有運行容器內部的所有進程數據，第一次收到數據后，利用本次數據為該次數據涉及到的每一個鏡像初始化進程行為模型。行為模型是對該鏡像生成的容器在運行時的正常行為范圍的界定。

在學習期間，此后每一次收到與該鏡像關聯的容器進程信息時，利用這些新增信息不斷更新該鏡像的模型，即更新模型中的進程列表，直到學習期結束，將模型狀態改為“已就緒”。

在學習期結束后，每一次收到數據后，檢測系統將該次數據中屬于同一鏡像的數據與數據庫中該鏡像的進程行為模型做匹配，如果待測數據中的進程屬性不在模型的鏡像進程列表描述的對應進程的屬性中，或待測數據的CPU、內存等資源使用情況超出了鏡像進程列表中記錄的對應進程的歷史最大CPU、內存資源使用率，則判定異常，并輸出告警。

本書第十六章給出了云原生異常檢測的方案和思路，供大家在部署云原生防御體系時參考。

4. 總結

未知攻焉知防。知道了攻擊手段后，能不能把“防”做起來，做到行之有效？這是一個問題。另外，攻與防是一個動態對抗的狀態，技術每發展一段時間，總會有一些未知的攻擊手段和攻擊面出現，我們能不能把這些未知的威脅檢測出來？或者至少能檢測出異常，再交給專家去判斷？這是另一個問題。

《云原生安全：攻防實踐與體系構建》試圖回答這些問題。我們系統梳理云原生安全可能面臨的威脅與風險，并給出了切實可行的防護方案。欲了解更多詳情，大家可參考《云原生安全：攻防實踐與體系構建》。