一、前置知識
容器是系統虛擬化的實現技術，容器技術在操作系統層面實現了對計算機系統資源的虛擬化，通過對CPU、內存和文件系統等資源的隔離、划分和控制，實現進程間的資源使用，實現系統資源的共享。docker容器是使用最廣、也是最具代表性的容器，這篇文章就來簡單探討docker容器的安全性，學習docker容器的風險與攻擊面。
容器技術的發展史：
容器與虛擬化的區別
虛擬化(Virtualization)和容器(Container)都是系統虛擬化的實現技術，可實現系統資源的“一虛多”共享。 容器技術是一種“輕量”的虛擬化方式，此處的“輕量”主要是相比於虛擬化技術而言的。例如，虛擬化通常在 Hypervisor 層實現對硬件資源的虛擬化，Hypervisor 為虛擬機提供了虛擬的運行平台，管理虛擬機的操作系統運行， 每個虛擬機都有自己的操作系統、系統庫以及應用。而容器並沒有 Hypervisor 層，每個容器是和主機 共享硬件 資源及操作系統 。容器技術在操作系統層面實現了對計算機系統資源的虛擬化，在操作系統中，通過對 CPU、內存和文件系統 等資源的隔離、划分和控制，實現進程之間透明的資源使用。
docker的安全風險與攻擊面
如下主要從承載容器運行的負載平台、容器自身、容器中運行的應用、容器編排工具 這幾個維度來說明，當然也有別的維度。
承載容器運行的負載
我們都知道，容器與宿主機共享操作系統內核，因此宿主機的配置對容器的運行安全有着至關重要的影響。
然而，隨着雲原生時代的到來，此處的『宿主機』不限於物理主機，可能是公有雲、私有雲、甚至混合雲的環境，可以統稱為『工作負載』；這種橫跨物理機、公有雲、私有雲、混合雲等環境時，可以參考雲工作負載保護平台（CWPP），當然CWPP不在本次的討論范圍內。
常見的加固建議有：
- 最小化安裝：禁止不必要的端口、不安裝額外的服務與軟件等；
- 為容器的存儲安裝單獨的分區；
- 工作負載加固：主機安全加固、雲工作負載平台加固，保證符合安全規范；
- 更新容器到最新版本；
- 守護進程的控制權限、行為審計
- docker相關的文件和目錄進行審計
docker容器本身
- docker的幾種網絡模式
-
橋接模式（bridge）：在默認的bridge網絡模式下，docker主機上的容器都會使用docker0這個網關，容易造成ARP欺騙、端口嗅探等，建議是自行給容器分配網絡 或使用docker swarm、kubernetes等容器集群管理平台，創建集群間的overlay網絡。
-
主機模式（host）:host模式會有更好的網絡性能，因為其使用了主機的本地網絡堆棧；但此時 容器將共享主機的網絡堆棧，容器能看到主機的所有端口，使容器有了訪問主機本地系統服務的全部權限。
-
MacVLAN模式：這是一種輕量級網絡虛擬化技術，MacVLAN 與主機的網絡接口連接，MacVLAN 相比 於橋接網絡驅動加強了與實體網絡的隔離性，但是在該網絡驅動中，同一個虛擬網絡下的容器之間沒有進行權限 管控，攻擊者可以輕易獲得容器權限並進行網絡攻擊。對此 Docker 官方提供了一些擴展插件來實現對容器權限細粒度的控制，例如網絡插件（Network Plugins） 可以提供容器間互聯網絡模型；數據卷插件（Volume Plugins）可以使docker數據卷跨多個主機；驗證插件（Authorization Plugins）可提供基於權限的訪問控制等。
-
overlay network模式：利用VXLAN技術，在不同主機間的Underlay網絡之上再組成新的虛擬網絡。最為明顯的弊端是VXLAN網絡上的流量沒有加密，傳輸內容很容易被攻擊者盜取或篡改。
- 逃逸風險
容器逃逸攻擊與虛擬機逃逸攻擊相似，利用虛擬化軟件存在的漏洞，通過容器獲取主機權限入侵主機，以達到攻擊主機的目的。
具體地，一些 PoC 工具，如 Shocker[48]，可展示如何從 Docker 容器逃逸並讀取到主機某個目錄的文件內容。 Shocker 攻擊的關鍵是執行了系統調用 open_by_handle_at 函數，Linux 手冊中特別提到調用 open_by_handle_at 函數需要具備 CAP_DAC_READ_SEARCH 能力，而 Docker1.0 版本對 Capability 使用黑名單管理策略，並且沒有 限制CAP_DAC_READ_SEARCH 能力，因而引發了容器逃逸的風險。
- 鏡像風險
-
構建安全
構建方式有基於容器的和基於dockerfile的，風險包括如下：
1）. pull 的基礎鏡像並不是由可信的組織和人員發布，鏡像本身存在后門或者其它風險項。
2）. 在 Dockerfile 中存儲敏感信息。例如配置服務時中使用明文固定密碼或憑證等。
3）. 安裝不必要的軟件擴大了攻擊面。 -
倉庫安全
1）.公共倉庫安全：
例如：docker hub，據說30%的docker鏡像存在安全漏洞，在享受docker hub帶來的便利時也要確保下載鏡像的安全性：
- 選擇官方鏡像最新版本
- 下載的鏡像需要經過漏洞掃描，需要覆蓋操作系統層面和應用層面
- 對於提供了公開dockerfile的鏡像優先選擇自己構建，可避免鏡像后門植入，確保構建過程的安全可控
2). 私有倉庫的安全
例如 docker registry和harbor
- 對於docker registry，一方面是考慮docker registry本身的安全性，例如在使用時配置相應的安全證書；另一方面是考慮docker客戶端與docker registry交互過程中的安全性，也就是實現用戶訪問權限限制（密碼鑒權、雙向ssl機制等）
- 鏡像掃描
比較主流的鏡像掃描引擎有docker security scanning（不開源）、clair（開源）和anchore（開源）等。
鏡像檢測的核心目前仍然是已知系統 CVE 檢測。掃描器獲取到鏡像后，將它分離成相應的層和軟件包 （Package）。然后這些 Package 將與多個 CVE 數據庫 Package 的名稱和版本進行對比，從而判定是否存在漏洞。還有一些通過掃描鏡像中的環境變量、操作命令以及端口開放信息來識別惡意鏡像的方案，但仍然需要使用 者自己基於結果來判斷，還不能直接給出一個明確的結果。
容器上承載的應用
- 微服務
服務軟件從單一的應用程序遷移為基於容器的大量微服務，在帶來許多好處的同時也改變了軟件內部的通訊 模式。從網絡和安全角度來看，最顯著的變化是內部網絡的東西向通信流量劇增，邊界變得更加模糊。盡管每個 運行中的容器都可以被加固，也可限定有限的對外網絡通信接口，但因為通信接口總量的激增，也給網絡攻擊者 探測和發現漏洞帶來更多機會在這種動態變化的容器環境中，傳統網絡防火牆不僅難以看到容器之間的網絡流量，而且隨着容器的快速啟 動和消失，它也無法適應這種持續的變化。正如一位網絡安全架構師所說：“在一個容器化的世界里，你無法手 動配置 Iptables 或手動更新防火牆規則。”
雲原生的環境中，需要對應的雲原生容器防火牆，它能夠隔離和保護應用程序容器和服務。即使在容器動態擴展或縮小的情況下也會自動實現發現、跟隨和保護。
微分段是比傳統以網絡地址為粒度的分段更細的隔離機制，例如可以是單個容器、同網段的容器集合或容器 應用等。微分段也是容器防火牆的基本功能之一，容器防火牆可感知第七層或者應用層，根據上層應用對連接進 行動態的控制，因而容器防火牆可實現面向業務的動態微分段，成為了保護東西向流量場景中容器免受惡意攻擊 第一道防線。
容器防火牆主要是針對保護容器之間的網絡會話，面向東西向場景，所以並不會取代部署在數據中心入口處 的防火牆等系統，比如 NGFW、IDS/IPS或WAF。相反，容器防火牆和傳統防火牆協同合作，可以有效防止內部應用程序級別的攻擊。
編排安全
容器技術的成熟推動者微服務的發展和落地，企業逐漸采用微服務架構來組件自己的應用，其中容器編排工具管理者承載各類服務的容器集群。以社區熱度最高的kubernetes編排工具來舉例說明編排工具的需要的安全防護措施。
-
計算資源安全：PodSecurityPolicy是集群級別的資源控，用於控制 Pod 規范以及管理 Pod 安全，PodSecurityPolicy 對象定義了一組必須運行的條件以及相關字段的默認值， 集群管理員通過 PodSecurityPolicy 可以控制以下內容。
-
集群安全
-
控制kubermetes API訪問
Kubernetes 的 API Server 針對所有 API 流量使用了安全傳輸協議(TLS)以確保服務間訪問的安全性，另外 又提供了訪問認證、訪問授權、Admission Control 等訪問控制機制。 -
控制對kubelet的訪問
kubelet的HTTPS端點公開了API，這些API授予了節點上容器強大的控制權，默認情況下允許對此API進行未授權認證的訪問。生產環境集群中建議開啟kubelet身份驗證和授權。 -
控制集群運行時工作負載和用戶的能力：限制集群中資源的使用、控制root權限運行容器、限制網絡訪問、控制pod訪問
-
保護集群中各組件
限制對etcd的訪問：對於 API 來說，擁有 Etcd 服務器后端的寫權限相當於獲得了整個集群的 root 權限。在 API Server 訪問 Etcd 服務器時，管理員應該使用廣受信任的憑證，比如通過 TLS 客戶端證書的相互認證。通常建議將 Etcd 服務器隔 離到只有 API Server 可以訪問的防火牆后面； -
對Etcd數據進行加密；
-
啟用審計日志
Kubernetes 啟用審計日志來記錄 API 發生破壞時進行后續的分析操作。 -
限制對Alpha或Beta的訪問（Alpha和Beta的特性還處在開發階段，可能會有限制而導致安全漏洞）
-
開啟集成前審查第三方：許多集成至 Kubernetes 的第三方插件都可以改變集群的安全配置，所以在啟用第三方插件時，應當檢查擴展請求的權限，Kubernetes 中的 Pod 安全策略(PodSecurityPolicy)可以提高其安全性。
-
頻繁回收基礎證書：Kubernetes 中一個 Secret 或憑據的壽命越短，攻擊者就越難使用該憑據，所以在證書上設置短生命周期並 實現自動回收證書是安全防護的一個好辦法。因此使用身份驗證機制時，應該設置發布令牌的可用時間，盡量縮 短壽命。
開源檢測工具
- [Anchore] (https://anchore.com/) ：漏洞分析與鏡像掃描。
- [Apparmor] (https://gitlab.com/apparmor/) ：RASP功能。
- [Cilium] (https://cilium.io/) ：網絡及HTTP層安全。
- Coreos Clair ：靜態代碼分析。
- Dagda ：靜態漏洞分析與監視。
- [Saucelabs] (https://saucelabs.com/open-source)：免費實時自動化代碼測試。
主流廠商
- Alertlogic ：管理容器身份和日志分析。
- [AquaSec] (https://www.aquasec.com/) ：RASP、審計、鏡像掃描和容器IDS
- [Flawcheck] (https://www.tenable.com/products/tenable-io/container-security) ：被Tenable收購並融入其容器鏡像掃描器以利用其Nessus安全專業技術。
- [Twistlock] (https://www.twistlock.com/platform/) ：RASP和附加機器學習防護。
- [Threatstack] (https://www.threatstack.com/securing-containerized-environments) ：作為漏洞監視工具融入其雲安全平台。