數萬臺服務器下的Docker深度安全實踐

本文整理自OPPO互聯網安全團隊劉湛盧的分享，他們主要負責OPPO互聯網安全團隊的研發工做，若是你也關注容器安全問題，但願這篇文章能帶來啓發。

同時歡迎關注OPPO互聯網技術團隊的公衆號：OPPO_tech，與你分享OPPO前沿互聯網技術及活動。

本文主要內容以下：

1. Docker生態與架構
2. 安全問題和應對方案
3. OPPO容器安全實踐
4. 容器生態的安全展望

先簡單介紹一下行業背景。

當前，OPPO在全球有超過2億+的DAU，最近幾年數據量增加超過180倍。從服務器數量和業務量的變化趨勢，能夠看到互聯網業務總體的發展趨勢是呈指數型上升，同時業務量的增加帶來了服務器數量的高速增加，這也與業務指數曲線是相似的。而當下，業界主流技術已經從物理服務器承載業務轉向了Docker化，Docker是當前熱門的雲計算主流技術。

Datadog 2018年6月統計的數據顯示，25%的公司已經採用Docker，預計2020年會達到50%，其餘沒有使用Docker的公司也在追趕過程當中。

1、Docker生態與架構

所謂容器生態，就是圍繞容器周邊的一系列元素和容器一塊兒構成整個容器構建、運行的方案和工具、文件等，而容器的安全並不只僅只是容器自己的安全性，也和容器生態的安全牢牢結合在一塊兒，須要有容器整個生態的安全支撐才能一塊兒構建容器完善的安全方案。

那麼容器的安全具體包括哪些元素？毫無疑問，Docker自己是其中核心的一部分。這是把容器運行起來的關鍵，控制着容器的啓停、管理容器運行所須要的資源、以及容器和外界的交互等容器核心功能點。

同時，Docker容器的運行是須要鏡像做爲支撐點的。每一個業務功能可能會有一個鏡像，當業務衆多，並且有不一樣版本時，尤爲像微服務這種對業務的拆分粒度很小的狀況，會產生大量的鏡像。在Docker裏面是由registry來管理鏡像，他存放着咱們全部的鏡像，當Docker在運行的時候，能夠指定從某個registry拉取相應鏡像到本地運行，固然這個拉取動做Docker本身會去執行。

到了生產環境，尤爲是業務體量比較大的公司或者機構，對如何管理鏡像的分發、容器的調度、業務的高可用能力、容器多副本的維護等方面提出了很大的挑戰，由此kubernetes應運而生。kubernetes的出現更加方便了容器在大規模使用，複雜業務場景上的使用。

先來看一副Docker安全與傳統安全的對比圖：

傳統的主機層安全問題包括操做系統的安全漏洞，webshell，惡意二進制程序，rootkit，內核安全，ssh暴力破解等。

Docker的安全包括：Docker自己的安全（包括主機的安全），鏡像的安全，registry的安全，鏡像分發傳輸的安全，編排系統(kubernetes)的安全將會成爲容器安全建設的核心點。

Docker的架構：

通常而言，Docker會跨私有網絡和互聯網運行，宿主機，企業級本身的私有註冊中心都會在私有網絡中，而Docker hub 這類公有註冊中心，互聯網上的其餘的公共註冊中心會運行在公網。在私有網絡中，宿主機上包括Docker客戶端和Docker的守護程序（Docker daemon），經過Docker客戶端向Docker的守護進程發送Docker指令來啓停容器，或者獲取容器的相關信息。Docker守護程序則接收到來自客戶端的請求則執行Docker命令，包括解析Docker指令，執行容器的啓停，向各個倉庫拉取鏡像等來完成容器的操控。因此Docker守護程序的安全是很是關鍵的，他能直接操控該主機上的全部容器。

2、安全問題和應對方案

幾個核心安全問題，第一是主機與容器守護安全，第二是鏡像安全，第三是容器運行時安全問題，第四是生態安全。

主機與容器守護安全問題。主機上的安全配置是否影響到容器的運行，主機的安全漏洞是否影響到容器運行，容器內的進程是否能夠利用主機上的安全漏洞。

鏡像安全方面。鏡像是否安全，鏡像傳輸過程當中是否會篡改，鏡像被銷燬後是否還存在安全問題。

容器運行時的安全問題。各容器之間的通信是否安全，隔離是否充分，容器在資源使用上是否安全。

生態安全。主要是Docker自己的安全性，還有編排系統的安全問題，容器的祕鑰管理和傳統的祕鑰管理是否不同，容器化之後的數據隱私保護方案是否和傳統方案一致。

2.1 主機與Docker守護進程的安全問題

先看Docker守護進程的安全，這個是用root權限建立的文件，經過非root文件就把它刪除掉了，這種主要是Linux對內核隔離性的不足，在Docker使用時隔離級別是由用戶自行決定的，把這個帳號直接加到Docker的帳號組裏就具有了這個權限。

咱們再看一個例子，曾經爆出來的Docker swarm集羣管理配置問題，就是將Docker daemon的相關接口暴露在公網上，而且並無啓用任何保護措施，從而致使任何人均可以使用Docker api來操縱容器，這就形成了一個危險極大的安全隱患。

而一般安全可靠的作法能夠由這幾種方式：

1. 使用Docker自己提供的TLS/HTTPS加密接口通道，但這種在大規模使用的時候在證書和祕鑰的管理方面會帶來必定的挑戰。

2. 經過統一的代理來訪問每一個Docker daemon的接口，而不直接暴露其接口，這樣使用安全代理加固的方式保護Docker daemon的接口安全性。

總的來講 Docker 守護進程的安全問題主要來自這幾個方面：

1. 須要root權限運行，這個在daemon安全上可能會帶來很大的安風險；

2. 守護進程對外提供API服務，用於的容器和整個Docker的管理工做，這使得對這些接口進行安全保護是很是重要的；

應對方案：

1. 儘可能不要直接開啓Docker remote api服務，若是必要則能夠經過中間代理層來作隔離控制；

2. 在隔離層添加ACL，添加控制白名單，增強對訪問源的監管；

3. 啓用TLS認證，增強驗證和通信的傳輸過程；

4. 守護進程的相關安全配置的合規掃描和審計；

2.2 鏡像安全問題

全部容器都是基於鏡像運行，若是鏡像的安全性受到威脅，顯然容器就被攻陷了，甚至主機均可能淪陷。

Docker hub是在行業主流的鏡像倉庫，其由Docker官方提供。曾經有人對其鏡像進行抽樣，使用clair對鏡像掃描，發現安全的鏡像只有24%，而風險鏡像佔到76%，其中高風險的鏡像有67%，這說明鏡像已經成爲Docker安全中的一個重要的安全攻擊防護戰場了。

例子：有人曾經利用Docker hub 傳播了17個惡意鏡像，其中包括有挖礦代碼，後來分析其相關鏡像的惡意代碼，發現其中相關聯的錢包地址顯示，這些惡意鏡像挖出了價值9萬美圓的門羅幣；因此，利用惡意鏡像進行挖礦、傳播惡意文件、勒索病毒、逃逸到主機系統作惡意攻擊等等，這些均可以植入到鏡像中。

總結一下鏡像會產生安全問題的幾個方面：

鏡像內容安全：鏡像能夠攜帶的安全問題如依賴庫漏洞，植入病毒，惡意文件等其餘安全問題，若是使用了基礎鏡像，那麼基礎鏡像是要可信的；

鏡像內容性質：鏡像內容的大小，在磁盤上是否會建立或者包含較大的磁盤空間，由於一個鏡像能夠建立多個容器，容器多了之後容易致使主機資源不夠用，再者是鏡像中文件個數過多，會致使大量的inode被佔用而過多消耗系統資源；

鏡像倉庫安全：包括倉庫自己的問題和安全加固，鏡像的傳輸安全，安全認證，鏡像簽名體系等等；

鏡像中的用戶權限控制：默認在鏡像中的進程是root權限運行，用戶能夠在構建鏡像時聽從相關規範，以最小權限原則執行；

鏡像掃描審計：經過對鏡像的深度掃描和審計，能夠及時發現鏡像的安全問題。

鏡像安全掃描工具：

Clair:當下很是主流的鏡像安全掃描工具，其掃描分析特色是使用靜態分析方式，會把鏡像包拆開，對鏡像進行層級分析，和已知的CVE庫進行版本對比的方式來掃描鏡像。這種分析方式有不少侷限性，只能根據CVE庫的版本進行對比，換言之對0day是毫無防護能力，沒有收錄在CVE或其惡意庫中的將得不到準確的掃描結果。因此掃描效果不是特別明顯。

其餘幾個掃描工具包括 anchore 和 Dockerscan 的掃描工具也是相似的思路。

這些都是當前開源、主流的一些掃描工具，後面咱們也會講講oppo的深度鏡像掃描系統的相關實踐。

2.3 運行時安全問題

容器運行時安全是從Docker daemon根據鏡像拉起一個容器開始，那麼在運行過程中，容器的安全性就和容器的運行機制、運行時庫、系統調用、讀寫行爲等這一系列的動態動做關聯起來了。前不久爆發的runC容器逃逸的漏洞，簡單來講這個漏洞就是經過在拉起一個惡意鏡像的過程當中，把Docker-runc這個關鍵程序覆蓋了，固然Docker daemon下次再啓動容器時就會執行替換的Docker-runc惡意代碼。除了runc容器逃逸的安全問題，主機層內核若是存在dirty cow漏洞也能夠溢出到主機上。

容器運行時安全，除了從容器內逃逸到主機上以外還有其餘的方式，容器運行時的安全問題還有下面這些：

• 磁盤資源限制上，例如某個容器把磁盤寫滿了致使其餘容器沒法正常工做。

• 容器之間的Ddos攻擊，某個容器把當前主機的帶寬打滿，致使其餘容器沒法工做。

• 因爲kernel層的隔離性不足上面，例如/proc，/sys等子系統的隔離性不足，容器內看到的cpu個數/mem等數據不許確等等。

那麼應對這些問題都有哪些辦法？Docker自己在這個層面上的安全控制能力是比較弱的，主要依靠內核層面有提供一些能力和權限限制工具來輔助處理，包括seccomp，capability，selinux，apparmor，tc流量控制，quota技術等。

2.4 容器生態安全問題

除了容器的運行時安全，鏡像安全，守護進程的安全問題，容器生態中還有很是重要的一環，容器編排和調度，當下最主流的容器編排和調度系統kubernetes，那麼kubernetes的安全性是怎麼樣的呢，其實kubernetes也發生過好多安全問題，包括曾經遭遇的大範圍的劫持等。

對於kubernetes的安全應對方案：

• 對系統使用最小特權。

• 按期更新系統軟件來確保已經被官方修復的漏洞獲得保護。

• 對其操做日誌進行記錄和審計，是系統保持在一個被安全監控的環境下運行。

• 權衡好安全和生產力的依託關係，經過調整產品形態把對一下有安全風險的功能關閉，或者使用其它方式替代使用。

• 使用安全端口進行通訊等。

3. OPPO容器安全實踐

整個容器的生命週期，包括了從鏡像構建到編排分發，從容器建立到運行、銷燬這一系列階段，所以咱們須要從容器生命週期全階段進行安全加固和保護。

在鏡像的生成階段：從鏡像構建到把鏡像推送到註冊服務器，鏡像構建中須要根據業務狀況來定製安全構建策略，聽從鏡像的安全構建規範，例如建立專門用在容器的用戶來啓動容器內業務進程、使用可信鏡像、涉密信息不存儲在Dockerfile、在Dockerfile中使用copy而不是add等等；那麼在註冊服務器，鏡像倉庫中會進行鏡像的深度掃描、簽名驗證等以防止惡意鏡像流入生產環境的鏡像倉庫，同時須要對鏡像倉庫接口進行加固和鏡像操做日誌進行審計以防止鏡像倉庫系統的入侵攻擊和被惡意修改。

編排分發階段：編排系統一樣須要作安全基線審查掃描，提供有效的安全策略配置，編排系統kubernetes的接口層安全加固，這是由kubenetes自己所提供的一系列機制來實現集羣安全控制，其中包括API Server的認證受權、准入控制機制以及保護敏感信息的securet機制等。同時在編排系統也須要作好日誌審計，以便於風險問題的預警分析和溯源。

容器鏡像的傳輸：在傳輸途徑中須要使用https進行加密傳輸，以防止中間人攻擊篡改鏡像。

鏡像的運行：鏡像最終是須要流轉到主機來真正使用，由Docker守護程序根據鏡像建立容器運行，那麼在主機層的鏡像審計和回掃都是很關鍵的，同時也須要對鏡像進行深度分析、鏡像的合規基線掃描，來檢測在主機側是否有惡意鏡像。

3.1 鏡像安全構建

安全構建，是在業務側進行，咱們須要給業務側提供鏡像的安全構建規範，業務方嚴格強流程按照安全構建規範完成構建。

主要是爲了達到如下幾個目的：

1. 有可信的安全的基礎鏡像，能夠由運維或者基礎鏡像團隊統一提供安全基礎鏡像；

2. 鏡像內業務權限最小化，依賴資源最小化，例如使用專用的容器運行帳號來啓動業務進程而非root用戶，移除沒必要要的權限如setuid/setgid等系統調用能力防止提權攻擊；

3. 儘可能減小鏡像中外部資源的使用；包括使用COPY替代ADD，由於ADD能夠經過外部連接來加載資源，不在Dockerfile中單獨使用更新命令等等。

3.2 鏡像倉庫加固

鏡像倉庫的架構中，通常倉庫API不要直接對外提供服務，能夠經過增長一箇中間代理層proxy來負責全部訪問對接，不管是在開發環境構建鏡像仍是掃描引擎對鏡像進行安全掃描，仍是產環境對容器進行編排部署都經過proxy進行來作鏡像的操做審計，客戶端認證、受權等操做。

中間層的做用主要包括：

• 鏡像的提交審計；

• 傳輸加密；

• 客戶端認證、受權；

• 掃描引擎和鏡像倉庫的掃描對接；

• 對鏡像倉庫服務器IP作訪問控制，接口惡意調用攔截等安全加固。

鏡像倉庫上能夠給它進行角色上的權限認證，好比不一樣角色分配不一樣權限，像開發、掃描和生產環境上分別配置不一樣的角色和配置不一樣權限，對業務進行劃分，不一樣業務使用時也有不一樣的權限，能夠設置黑白名單進行訪問控制，日誌操做審計，在操縱流程中包括上傳、下載及全部操做。

3.3 鏡像深度掃描

把鏡像從鏡像倉庫拉取下來，對鏡像的Dockerfile作指令分析，固然鏡像裏面並無直接攜帶Dockerfile文件，而是對其產生的history指令進行分析掃描，檢測其是否有不合規指令，包括基礎鏡像進行分析，帳號權限分析，ADD指令分析，內容信任分析，setuid/setgid等合規檢查。

鏡像是由各個層疊加而成，在history指令分析之後，咱們須要對其各個層進行拆解，對每個層級進行深度掃描分析；拆解之後，會對全部文件進行惡意特徵掃描，包括從公司內部收集和沉澱的惡意版本特徵庫，cve漏洞庫，黑白名單等進行版本特徵掃描。

在版本特徵掃描以後，會進入到深度掃描部分，包括webshell的深度掃描，例如使用yara規則，語法分析，大數據機器學習，模糊hash檢測等；惡意elf文件的深度掃描，一樣的，elf的掃描也有相應的yara規則，黑白名單，符號表分析，模糊hash，病毒、木馬特徵庫檢測；敏感信息檢測，分析鏡像各層中的文件，查看裏面是否存在敏感信息，好比說是鏡像裏面寫的有各種帳號密碼（如mysql/redis），咱們會對其進行統一分析掃描，用於保護密碼泄露，及早發現和預警。如今各種敏感信息泄露的事件層出不窮，敏感信息泄露也是咱們很是關注的一個層面。這個就是總體的深度鏡像掃描流程。

剛纔咱們介紹的是單個鏡像的掃描全流程，整個鏡像倉庫應該如何去掃描？OPPO當前的用戶體量也是很是龐大，有超過兩億+的用戶，業務體系也很是龐大，像瀏覽器，信息流，內容分發等互聯網業務很是豐富，如今微服務的架構大行其道，成千上萬的鏡像該如何組織，如何掃描，這是很是值得咱們深度思考的問題，從鏡像構建到鏡像管理都是很是具備挑戰性的。

從實踐來看，鏡像的組織通常劃分三大層次：

1. 由運維提供的基礎鏡像層，該層鏡像只提供系統基礎能力，必要的通用工具，運行時庫；

2. 基礎組件層，基礎組件層會對各業務提供基礎組件，包括相關的業務通用庫文件等等，提供相關共性業務所須要的通用能力；

3. 業務服務層，這個層面的鏡像是徹底業務化的，不一樣的業務有不一樣的鏡像，一個業務有多個鏡像；

4. 而且這個三個層次通常都有繼承關係，基礎組件層會繼承自運維提供的base鏡像，業務會繼承基礎鏡像。

3.4 主機安全加固

除了鏡像的安全掃描，主機層也須要對Docker進行安全加固，包括兩個層面：

1. 內核層面的加固：使用apparmor/selinux等配置精細的安全策略，針對進程級的通信訪問權限作限制，seccomp:(secure computing mode)，是一種內核特性，可用於限制進程可以調用的系統調用範圍，從而減小內核的攻擊面，用於構建沙箱；capability，用戶權限的能力限制，把相同的用戶劃分爲不一樣的各個組，能夠給每一個組賦予的系統調用能力不同，例如系統超級權限用戶root，能夠把它劃分紅多個組，每一個組給作一些不一樣的能力削減，一樣是root用戶所能操做的能力是不同的，從而達到權限的精細化管理。

2. 用戶層加固：儘量的縮小容器用戶的權限，限制掛載敏感目錄，磁盤單獨分區用於運行容器，主機安全的基線配置規範，Docker守護進程的日誌和相關配置目錄進行操做審計等這些層面來增強對主機的安全加固。

3.5 容器日誌收集

主機日誌審計，須要有一套高效日誌收集系統，統一日誌規範，在主機上有統一的日誌收集容器，不一樣的業務容器的日誌統一收集發送到大數據平臺，進行惡意日誌分析，包括使用日誌規則庫進行惡意日誌掃描，對惡意樣本日誌進行訓練，使用機器學習方式作補充識別等業界主流日誌分析方式。分析到異常日誌對接到統一的安全預警平臺進行容器安全預警。

3.6 流量分析

網絡流量安全：Docker daemon會幫容器在主機上創建一個網橋Docker0用於容器間的通信，所以咱們在主機上作流量分析時須要同時監聽Docker0和eth0（固然這裏的名字須要根據具體的主機配置來定）確保同主機和跨主機的各容器之間的流量都能被分析到；流量分析還有一種方式，交換機旁路鏡像分析，這種方式的優勢是不影響主機的計算力，能夠分析到容器跨主機之間的通信，可是不能分析同主機的容器流量，也沒法檢測和防護同主機的容器之間Ddos攻擊。

流量分析主要是檢測容器間的惡意訪問，包括惡意域名檢測，網址檢測，入侵檢測，病毒檢測，內容審計等，同時會作到協議還原，文件內容還原等，包括像主流的協議，TCP/UDP/DNS/HTTP/MYSQL/REDIS等等。同時在網絡層進行網絡安全配置規範化，例如只映射必要端口到主機，特權端口禁止映射，不共享主機網絡的namespace等。在主機上作TC，traffic control，防止容器間的Ddos行爲；

3.7 對容器進程的監控

1. 獲取容器的進程列表，把容器ID和其相關進程映射起來；

2. 在主機層監控異常進程，發現有異常進程，例如容器中的反彈shell，肯定其所屬容器並預警；

3. 對敏感目錄的掛載進行文件監控，發現有異常操做進行預警。

除了作進程監控外，進程的審計調用也很是關鍵，包括網絡是否有外聯網絡聯到惡意的地址或域名，Exec函數族審計，還有域名解析審計。Docker的關鍵命令程序進行監控，須要監控Docker目錄下像Docker-runc、Dockerd、Docker的程序有沒有被篡改，須要進行監控和預警保護。

3.8 主機入侵檢測與Docker的結合

主機入侵檢測中，首先須要把進程和容器ID、鏡像ID都關聯起來，對進程和相關的webshell/惡意二進制文件進行疑似惡意分析，對於疑似的惡意文件提交到後臺進行yara，符號表，特徵庫，ssdeep的模糊hash等方面的深度分析從而造成檢測結果。在這過程當中也會遇到比較大的挑戰，例如webshell掃描，掃描過程當中容器啓停問題，業務混布，文件多並且混雜，在基線掃描方面也須要考慮的針對容器自身的安全基線和安全策略的掃描。

這是oppo在入侵檢測方面覆蓋到Docker的檢測實踐：第一個是檢測到容器中的一個反彈shell的問題；第二個是容器外部掛載的一個目錄中發現了webhsell；第三個則是在容器運行中發現的一個惡意二進制的後門。

4. 容器生態的安全展望

整體來講容器的安全方面包括：

1. 容器的安全運維方案：自動編排，編排系統的安全性，對接到現有業務中，爲了兼容業務架構，在容器上線的初期有可能會作出調整而破壞一部分安全機制；

2. Docker方案代替傳統方案以後對數據的安全審計和祕鑰管理也會帶來很大的挑戰，像容器的漂移性，部分流量並不會過交換機，因此其安全審計方案會變得更加複雜；

3. 容器自身的安全機制，包括0day，並且目前容器主要仍是依靠主機來提供安全機制，而Docker自己對安全方面所作的較少；

4. 對內核的安全機制依賴，目前內核的隔離機制尚不完善，同時內核的安全問題也透露到容器層面；

5. 防護與檢測方面：容器漂移很是頻繁，同時與主機上文件的映射關係較複雜等等，這一些列問題都會給讓與檢測的帶來很大的挑戰，並且方案也會更加複雜。

最後重點來啦：

OPPO互聯網運維雲存儲團隊急招多個崗位，歡迎對MongoDB內核源碼、Wiredtiger存儲引擎、RocksDB存儲引擎、數據庫機房多活、數據鏈路同步系統、中間件、數據庫等有興趣的同窗加入，一塊兒參與OPPO百萬級高併發文檔數據庫研發。

工做地點：深圳 / 成都

聯繫郵箱：yangyazhou@oppo.com（最好註明來源掘金）