Docker作為應(yīng)用容器中最引人矚目的實現(xiàn)方式，在近幾年得到飛速的發(fā)展，大有成為應(yīng)用容器事實標準的趨勢，國內(nèi)外不少企業(yè)已經(jīng)將其應(yīng)用到生產(chǎn)系統(tǒng)中了，有理由相信隨著docker自身技術(shù)的完善和相關(guān)技術(shù)生態(tài)的建立，將成為下一代云計算的基石。

Docker的優(yōu)點很多，由于其誕生的目的就是便于持續(xù)的集成和快速部署，盡量減少中間環(huán)節(jié)，這也為其安全控制帶來難度， Gartner在確定2017年中最高安全技術(shù),關(guān)于容器安全是其中一項，原文如下：

Containers use a shared operating system (OS) model. Anattack on a vulnerability in the host OS could lead to a compromise of allcontainers. Containers are not inherently unsecure, but they are being deployedin an unsecure manner by developers, with little or no involvement fromsecurity teams and little guidance from security architects. Traditionalnetwork and host-based security solutions are blind to containers. Containersecurity solutions protect the entire life cycle of containers from creationinto production and most of the container security solutions providepreproduction scanning combined with runtime monitoring and protection.

報告分析了容器安全面臨的挑戰(zhàn)：容器使用共享操作系統(tǒng)（OS）模型。對主機操作系統(tǒng)中的漏洞的攻擊可能導致所有容器被攻擊，且容器本身并不完全安全。但真正的問題在于由開發(fā)人員以不安全的方式部署，安全團隊很少或根本沒有參與，安全架構(gòu)師也沒有指導。

Docker容器安全嗎？

本身這個問題就是一個哲學問題，答案是否定的-不安全，因為沒有絕對安全。其實對docker容器安全質(zhì)疑最大的一點就是其隔離的徹底性，與其對比就是當前成熟的虛擬機（VM）技術(shù)。相對于VM，docker容器只是對進程和文件進行虛擬化，而VM做到了OS級別的虛擬化。從這個角度看VM的隔離性確實要好于docker容器，也就是說對宿主機的安全影響VM要遠遠小于docker，但換個角度看，這也恰恰正是docker的一個優(yōu)點：輕量級，高效以及易移植。所以，安全和易用永遠存在在一個平衡點，本文探討的前提是認同docker帶來的便利性，也接受其帶來的安全風險，而要做的是利用一些的安全手段來將其風險降到可接受范圍。

而容器安全如何來實現(xiàn)呢？

其實在Gartner的報告中也提到了，需要對docker全生命周期的安全防護，信息安全本質(zhì)上就是控制風險，如果從一個docker的生命中周期面臨的安全威脅來設(shè)計docker的安全防護策略，那安全控制的思路就會十分清晰。

首先，來簡單捋一下docker容器的生命周期，一個docker容器從產(chǎn)生到運行部署大致分為如下三個狀態(tài)：

–Dockerfile:用于創(chuàng)建image鏡像的模板文件，出于管理和安全的考慮，docker官方建議所有的鏡像文件應(yīng)該由dockerfile來創(chuàng)建，而當前不少用戶把docker當虛擬機來使用，甚至容器中安裝SSH，從安全的角度，這是不恰當?shù)摹?/p>

–Image:鏡像文件，對比PC端的概念，我們可以把它理解為服務(wù)器端的可執(zhí)行軟件包。一旦打包生成，如存在安全問題，那這些問題也被一并打包，最后導致安全事件。

–Container：運行起來的image文件就是容器了，從外來看就是一個應(yīng)用，可對外提供服務(wù)了。

所以不難發(fā)現(xiàn)，docker容器的生命周期，就是一個鏡像文件從產(chǎn)生、運行到停止的過程，對其安全防護的目標就很明確了，那就是：

接下來，我們把docker容器生命周期和實際工作中結(jié)合起來，大致如下圖所示：

在一般企業(yè)內(nèi)，一個標準的產(chǎn)品發(fā)布流程大致如下：研發(fā)人員將代碼提交給代碼庫；QA和安全人員通過jekins等工具進行編譯并測試；測試完成后，由運維人員獲取最終上線版本，發(fā)布到生產(chǎn)環(huán)境。也可能是測試完成后，直接發(fā)布到生產(chǎn)環(huán)境。

化繁為簡，可將docker生命周期拆為兩個大階段，非生產(chǎn)環(huán)境階段和生產(chǎn)環(huán)境階段，這兩個階段安全控制的目標如下：非生產(chǎn)環(huán)境中保證鏡像安全可信，生產(chǎn)環(huán)境中保證鏡像正確的運行。

兩個階段安全保護措施

Docker公司與美國互聯(lián)網(wǎng)安全中心（CIS）合作,制定了docker的最佳安全實踐，其中包括了主機安全配置、docker守護進程配置、docker守護程序配置文件、容器鏡像和構(gòu)建、容器運行安全、docker安全操作六大項，99個控制點。幾乎覆蓋了docker安全要求各個方面，我們也對其進行了翻譯和整理，在本專欄的后續(xù)文章中會陸續(xù)發(fā)布。

保證非生產(chǎn)環(huán)境中的鏡像安全

–容器使用非root用戶運行

為了防止容器逃逸而獲得宿主機的權(quán)限，容器內(nèi)應(yīng)用以非root用戶身份運行，如果用戶已經(jīng)在容器鏡像中定義，則默認情況下容器將作為該用戶運行，且不需要特定的用戶命名空間重新映射?？梢栽贒ockerfile中添加用戶：RUN useradd -d / home /username -m -s / bin / bash username USER username

–使用安全的基礎(chǔ)鏡像

如果基礎(chǔ)鏡像存在安全問題，那整個鏡像文件的安全性也無從談起，用戶可根據(jù)自身需求定制基礎(chǔ)鏡像，并強制要求組織內(nèi)使用認可的基礎(chǔ)鏡像；也可使用第三方安全的鏡像，這里推薦使用Alpine-linux，docker所有的官方鏡像都使用其作為基礎(chǔ)鏡像，docker也會對其維護更新，所以安全性有保證。

–刪除鏡像中的setuid和setgid權(quán)限

setuid和setgid權(quán)限可用于提權(quán)。雖然有時候必須要使用到，但如果被濫用，可能會導致非法的提升權(quán)限?？梢栽阽R像中限制這些權(quán)限的使用。具體做法可參考：在構(gòu)建鏡像時通過在Dockerfile中添加以下命令來刪除這些權(quán)限，一般在Dockerfile的末尾添加：RUN find / -perm 6000-type f-exec chmod a-s {} \;|| true

–啟用Docker的內(nèi)容信任

內(nèi)容信任允許當用戶使用遠程Docker倉庫進行操作時，以執(zhí)行鏡像標記的客戶端簽名和驗證。內(nèi)容信任提供了對從Docker倉庫發(fā)送和接收的數(shù)據(jù)使用數(shù)字簽名的能力。這些簽名允許客戶端驗證特定鏡像標簽的完整性。

在默認情況下，內(nèi)容信任是禁用的?？赏ㄟ^如下命令進行啟動：export DOCKER_CONTENT_TRUST = 1

–最小安裝原則：

安全的普適法則，不要安裝任何與應(yīng)用無關(guān)的東西。

–對鏡像進行安全漏洞掃描

鏡像中包含了很多的插件及軟件包，需要對這些軟件包進行漏洞掃描，并根據(jù)結(jié)果安裝補丁或更新軟件，Coreos提供了一款開源docker鏡像安全掃描器-Clair，（github地址鏈接

關(guān)于Clair的實現(xiàn)原理，會在后續(xù)的文章介紹，同時我們參考了Clair的實現(xiàn)方式，優(yōu)化了開發(fā)了一款docker鏡像掃描器，也會在適當?shù)臅r候推出并開源。

如何保證生產(chǎn)環(huán)境中容器的安全？

–對docker宿主機進行安全加固

務(wù)必保證docker宿主機的安全，需要對宿主機的系統(tǒng)進行安全加固處理，主機加固可以參考相關(guān)的安全checklist以及各企業(yè)制定的主機安全規(guī)范，在這里就不在贅述。

–限制容器之間的網(wǎng)絡(luò)流量

在默認情況下，同一主機上的所有容器之間網(wǎng)絡(luò)流量不受限制。因此，每個容器都有可能在同一主機上的容器網(wǎng)絡(luò)上讀取所有數(shù)據(jù)包。這可能會導致意外泄露信息。因此，需要限制容器間通信具體操作：在守護進程模式下運行docker，并將’–icc = false’作為參數(shù)。如：/ usr / bin / dockerd –icc = false

–配置Docker守護程序的TLS身份驗證

在默認情況下，Docker守護程序綁定到非聯(lián)網(wǎng)的Unix套接字，并以root權(quán)限運行。若將默認的docker守護程序更改為綁定到TCP端口或任何其他Unix套接字，那么任何有權(quán)訪問該端口或套接字的人都可以完全訪問Docker守護程序。因此，不應(yīng)該將Docker守護程序綁定到另一個IP /端口或Unix套接字。如果必須通過網(wǎng)絡(luò)套接字暴露Docker守護程序，需為守護程序和Docker Swarm API配置TLS身份驗證。

–啟用用戶命名空間支持

防止容器內(nèi)的提權(quán)攻擊的最佳方法是將容器的應(yīng)用程序配置為無特權(quán)用戶運行。對于必須使用roo身份運行的容器，可以將該用戶重新映射到Docker主機上特定用戶。映射的用戶被分配一個范圍的UID，它們在命名空間內(nèi)作為正常的UID，但對主機本身沒有特權(quán)。關(guān)于使用用戶命名空間隔離容器在后續(xù)文章中詳細介紹。

–限制容器的內(nèi)存使用量

在默認情況下，容器可以使用主機上的所有內(nèi)存。可以使用內(nèi)存限制機制來防止一個容器消耗所有主機資源的拒絕服務(wù)攻擊，具體可使用使用“-m”或“–memory”參數(shù)運行容器。如下：

$> docker run <運行參數(shù)> –memory <memory-size> <Container ImageName或ID> <Command>

–適當設(shè)置容器CPU優(yōu)先級

在默認情況下，CPU時間在容器間平均分配，可使用CPU共享功能來設(shè)定優(yōu)先級。 CPU共享允許將一個容器優(yōu)先于另一個容器，并禁止較低優(yōu)先級的容器頻繁地占用CPU資源。這樣可確保高優(yōu)先級的容器更好地運行，且可以有效的防止資源耗盡攻擊。

針對docker安全配置檢查，docker官方提供了一個腳本工具docker-bench-secruity（github地址鏈接

通過前文介紹，列舉了在docker容器生命周期需要進行的安全控制措施，但如果僅靠人工實施和監(jiān)督，可能效果不會太好。若能將docker各個生命周期的安全管理自動化才是最佳實現(xiàn)方式，docker安全剛剛開始呀:)

后續(xù)預告

由于docker安全涉及內(nèi)容較多，dosec專欄會發(fā)布一系列的原創(chuàng)文章，目前擬定有：

《docker鏡像安全掃描器的實現(xiàn)》

《利用docker插件實現(xiàn)細粒度權(quán)限控制》

《配置安全的docker運行l(wèi)iunx主機》

《docker最佳安全實踐詳解》

《docker內(nèi)容信任詳解》

《docker安全管理平臺的架構(gòu)設(shè)計》

歡迎關(guān)注?。?！

專欄

2