本篇內(nèi)容主要講解“公有云Docker鏡像安全嗎”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“公有云Docker鏡像安全嗎”吧!

創(chuàng)新互聯(lián)公司專注于安定網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供安定營(yíng)銷型網(wǎng)站建設(shè)，安定網(wǎng)站制作、安定網(wǎng)頁(yè)設(shè)計(jì)、安定網(wǎng)站官網(wǎng)定制、成都小程序開(kāi)發(fā)服務(wù)，打造安定網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供安定網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

當(dāng)前，電商平臺(tái)會(huì)采用基于Docker的容器技術(shù)來(lái)承載618大促期間的一些關(guān)鍵業(yè)務(wù)版塊，包括最簡(jiǎn)單的商品圖片展示、訂單詳情頁(yè)面等等。

通過(guò)容器化改造，電商平臺(tái)的每個(gè)業(yè)務(wù)版塊解耦，可以獨(dú)立開(kāi)發(fā)、部署和上線，從而讓后臺(tái)業(yè)務(wù)系統(tǒng)具備更高的穩(wěn)定性、可擴(kuò)展性和安全性，即便某個(gè)環(huán)節(jié)出現(xiàn)問(wèn)題，也能保障平臺(tái)高峰值期間的平穩(wěn)運(yùn)行。

鏡像是Docker容器的基石，只有通過(guò)它才可以創(chuàng)建容器，而Registry是存放Docker鏡像的倉(cāng)庫(kù)。但在實(shí)際應(yīng)用中，由于需要頻繁地從Registry下載鏡像運(yùn)行容器應(yīng)用（比如發(fā)布新版本，打補(bǔ)釘?shù)惹樾危溟g的文件傳輸成為鏡像分發(fā)的瓶頸，

P2P加速鏡像下載是有效的解決方案，但如何確保用戶數(shù)據(jù)在公有云環(huán)境下的P2P傳輸安全性尤為關(guān)鍵，本文主要從鏈路層和業(yè)務(wù)層的安全加固，闡述了公有云Docker鏡像P2P加速的安全性。

問(wèn)題：

在使用Docker運(yùn)行容器化應(yīng)用時(shí)，宿主機(jī)通常先要從Registry服務(wù)（如Docker Hub）下載相應(yīng)的鏡像(image)。這種鏡像機(jī)制在開(kāi)發(fā)環(huán)境中使用還是很有效的，團(tuán)隊(duì)成員之間可以很方便地共享同樣的鏡像。然而在實(shí)際的生產(chǎn)環(huán)境中，當(dāng)大量主機(jī)需要同時(shí)從Registry下載鏡像運(yùn)行容器應(yīng)用時(shí)（比如發(fā)布新版本，打補(bǔ)釘?shù)惹樾危?，Registry 服務(wù)往往會(huì)成為鏡像分發(fā)的瓶頸，應(yīng)用鏡像需要較長(zhǎng)時(shí)間才能傳送到所有主機(jī)上，使得應(yīng)用發(fā)布的周期大大延長(zhǎng)。

不少企業(yè)提出了P2P加速鏡像下載的解決方案，但都是私有云及內(nèi)部環(huán)境的使用場(chǎng)景，在公有云未得到使用。其中很大一部分原因是公有云使用P2P的安全性問(wèn)題，如何確保用戶數(shù)據(jù)在P2P傳輸中是安全的成為了其中的難點(diǎn)。我們就該問(wèn)題設(shè)計(jì)實(shí)現(xiàn)了確保用戶數(shù)據(jù)安全的P2P鏡像分發(fā)系統(tǒng)。本文就其安全性展開(kāi)闡述。

架構(gòu)：

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

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

客戶端代理（Proxy）

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

BT客戶端

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

BT Tracker

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

安全：

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

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

鏈路安全

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

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

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

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

什么是公鑰：

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

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

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

證書(shū)的意義：

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

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

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

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

我們是怎么做的

• Client之間

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

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

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

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

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

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

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

• Docker Daemon 到 Proxy

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

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

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

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

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

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

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

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

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

（1）用戶信息

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

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

（4）用于解析Token簽名的證書(shū)

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

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

到此，相信大家對(duì)“公有云Docker鏡像安全嗎”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！