Docker鏡像安全性舉例分析

這篇文章主要講解了“Docker鏡像安全性舉例分析”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Docker鏡像安全性舉例分析”吧！

一、問題

在使用Docker運(yùn)行容器化應(yīng)用時(shí)，宿主機(jī)通常先要從Registry服務(wù)（如Docker Hub）下載相應(yīng)的鏡像(image)。這種鏡像機(jī)制在開發(fā)環(huán)境中使用還是很有效的，團(tuán)隊(duì)成員之間可以很方便地共享同樣的鏡像。

然而在實(shí)際的生產(chǎn)環(huán)境中，當(dāng)大量主機(jī)需要同時(shí)從Registry下載鏡像運(yùn)行容器應(yīng)用時(shí)（比如發(fā)布新版本，打補(bǔ)丁等情形），Registry 服務(wù)往往會(huì)成為鏡像分發(fā)的瓶頸，應(yīng)用鏡像需要較長時(shí)間才能傳送到所有主機(jī)上，使得應(yīng)用發(fā)布的周期大大延長。

對此，許多企業(yè)提出了P2P加速鏡像下載的解決方案，但都是私有云及內(nèi)部環(huán)境的使用場景，在公有云未得到使用，主要原因是用戶擔(dān)心數(shù)據(jù)在P2P傳輸中會(huì)出現(xiàn)安全問題。本文將重點(diǎn)闡述確保用戶數(shù)據(jù)安全的P2P鏡像分發(fā)系統(tǒng)。

二、架構(gòu)

華為云P2P容器鏡像分發(fā)系統(tǒng)示例圖

華為云容器鏡像服務(wù)SWR的P2P容器鏡像分發(fā)系統(tǒng)包含3個(gè)組件：客戶端代理（Proxy）、BT客戶端和BT Tracker。

客戶端代理（Proxy）

客戶端代理部署在集群的每個(gè)節(jié)點(diǎn)中，配置為Docker的Http Proxy，截獲Docker Daemon的鏡像下載請求，通知Client下載，并最終將鏡像導(dǎo)入到Docker daemon中。

BT客戶端

部署在集群節(jié)點(diǎn)的BT客戶端和Tracker共同組成了一個(gè)完整的P2P文件傳輸系統(tǒng)。在整個(gè)鏡像的分發(fā)過程中，它們利用BT協(xié)議完成鏡像下載。

BT Tracker

Tracker是BT系統(tǒng)的一部分，它存儲了BT客戶端下載過程中所需要的元數(shù)據(jù)信息和種子信息，并協(xié)助各個(gè)BT客戶端完成整個(gè)通信過程。

三、安全

首先，我們限制了跨集群的P2P下載，最大限度的租戶間的數(shù)據(jù)泄露。

之后，在鏈路層面的安全性和業(yè)務(wù)層面的安全性做了增強(qiáng)。

1、鏈路安全

一想到鏈路安全，我們首先會(huì)想到的是加密。

對稱加密服務(wù)端和客戶端采用相同的秘鑰加密和解密，只要這個(gè)秘鑰不公開，并且秘鑰足夠安全，那么鏈路就是安全的。但是在網(wǎng)絡(luò)中都使用相同的對稱加密秘鑰，無異于公開傳輸，如果秘鑰被劫持，那么就可以篡改鏈路的所有數(shù)據(jù)。

然后我們肯定會(huì)想到HTTPS，它是怎么實(shí)現(xiàn)安全的？我們先來了解下HTTPS的實(shí)現(xiàn)方式。

在具體的數(shù)據(jù)傳輸過程中，HTTPS采用的是對稱加解密的方式，但是它在連接建立時(shí)增加了握手協(xié)商的過程。

什么是公鑰：

公鑰是非對稱加密中的概念。非對稱加密算法方式基于一個(gè)秘鑰對，數(shù)據(jù)通過一個(gè)秘鑰加密，只有通過另外一個(gè)秘鑰才能解密。服務(wù)端保存私鑰，公鑰發(fā)給客戶端。

我們假設(shè)一個(gè)場景，我們生成秘鑰對，客戶端通過公鑰加密數(shù)據(jù)，服務(wù)端通過私鑰解密。那么即使用戶劫持到公鑰，他無法劫持篡改用戶的數(shù)據(jù)。然而從服務(wù)端到客戶端的鏈路還是不安全的。

HTTPS借助了非對稱加密的這個(gè)特性，確保對稱機(jī)密秘鑰的傳輸是安全的，最后采用對稱加密傳輸數(shù)據(jù)。

證書的意義：

然而，這又產(chǎn)生了一個(gè)新的問題，公鑰被劫持了怎么辦？

HTTPS當(dāng)然不會(huì)這么簡單就被劫持，它引入了數(shù)字證書和第三方機(jī)構(gòu)。證書是由第三方認(rèn)證機(jī)構(gòu)通過公鑰簽發(fā)的，其中不僅包含公鑰，還包含簽名（ 由簽發(fā)節(jié)點(diǎn)的私鑰加密產(chǎn)生）、有限期、簽發(fā)機(jī)構(gòu)、網(wǎng)址、失效日期等。

HTTPS返回的不在是私鑰，而是證書。當(dāng)客戶端接收到證書，會(huì)對證書做一個(gè)校驗(yàn)。在各個(gè)機(jī)器中都會(huì)維護(hù)一個(gè)權(quán)威的第三方機(jī)構(gòu)列表（包括它們的公鑰），當(dāng)客戶端需要公鑰時(shí)，可根據(jù)頒發(fā)機(jī)構(gòu)信息本地查找到公鑰?？蛻舳送ㄟ^頒發(fā)機(jī)構(gòu)的公鑰驗(yàn)證簽名的有效性和證書的完整性，保證公鑰未被篡改。

HTTPS通過私鑰、證書、和CA（簽發(fā)機(jī)構(gòu)）確保了鏈路的安全性。在P2P場景下，BT Client之間是對等的，他們相互傳輸數(shù)據(jù)，更應(yīng)該是服務(wù)端校驗(yàn)客戶端，而不是HTTPS的客戶端校驗(yàn)服務(wù)端。并且由于BT Client是部署在用戶的節(jié)點(diǎn)，還需要考慮證書和私鑰都被劫持的風(fēng)險(xiǎn)。

我們是怎么做的

Client之間

BT Client間傳輸數(shù)據(jù)肯定是需要加密的，防止鏈路的數(shù)據(jù)被劫持。但是只增加HTTPS，雖然鏈路被加密，但是客戶端可能會(huì)被假冒，只要假冒者不校驗(yàn)服務(wù)端的證書，直接和服務(wù)端握手，就能從其他BT Client獲取到他想要的數(shù)據(jù)。

我們借鑒和HTTPS的實(shí)現(xiàn)，采用了雙向驗(yàn)證的模式。

需要有證書，首先需要一個(gè)統(tǒng)一的CA（簽發(fā)機(jī)構(gòu)），因此我們在Tracker中保存證書和私鑰做為簽發(fā)機(jī)構(gòu)，Proxy獲取種子的同時(shí)返回CA，用戶校驗(yàn)客戶端的證書。

然后，只使用一個(gè)證書對并且放在Bt Client是危險(xiǎn)的，很有可能性被入侵截獲到證書，因此我們獲取證書的方式改為從Tracker獲取，獲取種子的同時(shí)獲取Tracker生成的臨時(shí)證書私鑰對，把它加入BT Client的下載隊(duì)列。在BT Client開始相互連接時(shí)，首先相互確認(rèn)對方的證書的有效性（簽名、簽發(fā)機(jī)構(gòu)等信息），校驗(yàn)通過后才能請求并相互下載數(shù)據(jù)。

這種方式下，Client之間的鏈路是安全的。

（1）鏈路經(jīng)過證書加密，直接截獲鏈路是不可行的

（2）即使仿照BT Client的方式，由于Client每個(gè)連接都需要進(jìn)行雙向的證書校驗(yàn)，想通過這個(gè)方式截獲數(shù)據(jù)就必須請求Tracker去獲取，而訪問Tracker首先是HTTPS的，然后我們還做了業(yè)務(wù)層的安全校驗(yàn)（下文業(yè)務(wù)層安全會(huì)提及），也是不可行的。

Docker Daemon到 Proxy

我們在Proxy中需要劫持Docker的請求，因?yàn)镈ocker在不配置時(shí)訪問Registry采用的是HTTPS，因此Proxy劫持Docker請求就必須和Docker保持HTTPS連接。

我們讓客戶端代理只監(jiān)聽localhost端口，杜絕外部使用該代理的可能性。同時(shí)，客戶端代理綁定一套臨時(shí)生成的簽發(fā)給registry域名的自簽名證書和CA證書，用于劫持Docker Daemon的請求，并將CA證書添加到機(jī)器的信任證書當(dāng)中。

代理綁定的證書只保存在內(nèi)存中，即使通過特定方式獲取到當(dāng)前節(jié)點(diǎn)的CA證書和服務(wù)端證書，也無法截取其他節(jié)點(diǎn)數(shù)據(jù)。

從用戶節(jié)點(diǎn)到Registry、Tracker

首先，為了確保鏈路的安全，Regstry、Tracker都綁定從權(quán)威第三方機(jī)構(gòu)購買的HTTPS證書私鑰對。Proxy和BT Client在訪問它們的時(shí)候都會(huì)去校驗(yàn)證書的有效性，只要在證書有效的情況下才發(fā)送請求，這從根源上杜絕了Regstry、Tracker被假冒的可能。

2、業(yè)務(wù)加密

在確保鏈路安全后，我們還做了一層業(yè)務(wù)安全加固。首先我們先了解下JWT Token。

Json web token（JWT）是為了網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開發(fā)標(biāo)準(zhǔn)（RFC 7519），該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登陸（SSO）場景。JWT的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

在我們使用Docker命令下載鏡像時(shí)，Docker首先會(huì)到Registy獲取Token，在之后的獲取鏡像層的過程中，多會(huì)帶上該Token用于鑒權(quán)。其中Token時(shí)組要包含以下信息：

（1）用戶信息

（2）資源信息，為操作的鏡像和namespace的名稱

（3）權(quán)限信息：是否有PULL/PUSH權(quán)限

（4）用于解析Token簽名的證書

利用JWT Token中自帶解析Token證書這個(gè)特性，我們在BT Client間通信又增加了Token的校驗(yàn)。在前文中的證書校驗(yàn)通過后，客戶端需要發(fā)送Token給服務(wù)端用于校驗(yàn)。為了防止Token被假冒，入侵者采用第三方生成，我們使用服務(wù)端截從Docker截取的Token中的證書解析校驗(yàn)客戶端的Token，杜絕這種情況。

同時(shí)，Proxy訪問Tracker的接口也會(huì)帶上這個(gè)Token，Tracker會(huì)校驗(yàn)Token的權(quán)限，完成業(yè)務(wù)層的安全驗(yàn)證，防止證書和種子被盜取。

感謝各位的閱讀，以上就是“Docker鏡像安全性舉例分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Docker鏡像安全性舉例分析這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！