電商業務容器化遇瓶頸，公有云Docker鏡像P2P加速很安全

當前，電商平臺會採用基於Docker的容器技術來承載618大促期間的一些關鍵業務版塊，包括最簡單的商品圖片展現、訂單詳情頁面等等。

經過容器化改造，電商平臺的每一個業務版塊解耦，能夠獨立開發、部署和上線，從而讓後臺業務系統具有更高的穩定性、可擴展性和安全性，即使某個環節出現問題，也能保障平臺高峯值期間的平穩運行。

鏡像是Docker容器的基石，只有經過它才能夠建立容器，而Registry是存放Docker鏡像的倉庫。但在實際應用中，因爲須要頻繁地從Registry下載鏡像運行容器應用（好比發佈新版本，打補釘等情形），其間的文件傳輸成爲鏡像分發的瓶頸，

P2P加速鏡像下載是有效的解決方案，但如何確保用戶數據在公有云環境下的P2P傳輸安全性尤其關鍵，本文主要從鏈路層和業務層的安全加固，闡述了公有云Docker鏡像P2P加速的安全性。

1.1 問題

       在使用Docker運行容器化應用時，宿主機一般先要從Registry服務（如Docker Hub）下載相應的鏡像(image)。這種鏡像機制在開發環境中使用仍是頗有效的，團隊成員之間能夠很方便地共享一樣的鏡像。然而在實際的生產環境中，當大量主機須要同時從Registry下載鏡像運行容器應用時（好比發佈新版本，打補釘等情形），Registry 服務每每會成爲鏡像分發的瓶頸，應用鏡像須要較長時間才能傳送到全部主機上，使得應用發佈的週期大大延長。

很多企業提出了P2P加速鏡像下載的解決方案，但都是私有云及內部環境的使用場景，在公有云未獲得使用。其中很大一部分緣由是公有云使用P2P的安全性問題，如何確保用戶數據在P2P傳輸中是安全的成爲了其中的難點。咱們就該問題設計實現了確保用戶數據安全的P2P鏡像分發系統。本文就其安全性展開闡述。

 

1.2 架構

華爲P2P容器鏡像分發系統示例圖

華爲P2P容器鏡像分發系統包含3個組件：客戶端代理（Proxy）、BT客戶端和BT Tracker。

客戶端代理（Proxy）

客戶端代理部署在集羣的每一個節點中，配置爲Docker的Http Proxy，截獲Docker Daemon的鏡像下載請求，通知Client下載，並最終將鏡像導入到Docker daemon中。

BT客戶端

部署在集羣節點的BT客戶端和Tracker共同組成了一個完整的P2P文件傳輸系統。在整個鏡像的分發過程當中，它們利用BT協議完成鏡像下載。

BT Tracker

Tracker是BT系統的一部分，它存儲了BT客戶端下載過程當中所須要的元數據信息和種子信息，並協助各個BT客戶端完成整個通訊過程。

 

1.3 安全：

首先，咱們限制了跨集羣的P2P下載，最大限度防止租戶間的數據泄露。

以後，在鏈路層面的安全性和業務層面的安全性作了加強。

1.3.1 鏈路安全

一想到鏈路安全，咱們首先會想到的是加密。

對稱加密服務端和客戶端採用相同的祕鑰加密和解密，只要這個祕鑰不公開，而且祕鑰足夠安全，那麼鏈路就是安全的。可是在網絡中都使用相同的對稱加密祕鑰，無異於公開傳輸，若是祕鑰被劫持，那麼就能夠篡改鏈路的全部數據。

而後咱們確定會想到HTTPS，它是怎麼實現安全的？咱們先來了解下HTTPS的實現方式。

在具體的數據傳輸過程當中，HTTPS採用的是對稱加解密的方式，可是它在鏈接創建時增長了握手協商的過程。

什麼是公鑰：

公鑰是非對稱加密中的概念。非對稱加密算法方式基於一個祕鑰對，數據經過一個祕鑰加密，只有經過另一個祕鑰才能解密。服務端保存私鑰，公鑰發給客戶端。

咱們假設一個場景，咱們生成祕鑰對，客戶端經過公鑰加密數據，服務端經過私鑰解密。那麼即便用戶劫持到公鑰，他沒法劫持篡改用戶的數據。然而從服務端到客戶端的鏈路仍是不安全的。

HTTPS藉助了非對稱加密的這個特性，確保對稱機密祕鑰的傳輸是安全的，最後採用對稱加密傳輸數據。

證書的意義：

然而，這又產生了一個新的問題，公鑰被劫持了怎麼辦？

HTTPS固然不會這麼簡單就被劫持，爲了解決上訴問題，它引入了數字證書和第三方機構。證書是由第三方認證機構經過公鑰簽發的，其中不只包含公鑰，還包含簽名（ 由簽發節點的私鑰加密產生）、有限期、簽發機構、網址、失效日期等。

HTTPS返回的不在是私鑰，而是證書。當客戶端接收到證書，會對證書作一個校驗。在各個機器中都會維護一個權威的第三方機構列表（包括它們的公鑰），當客戶端須要公鑰時，可根據頒發機構信息本地查找到公鑰。客戶端經過頒發機構的公鑰驗證簽名的有效性和證書的完整性，保證公鑰未被篡改。

HTTPS經過私鑰、證書、和CA（簽發機構）確保了鏈路的安全性。在P2P場景下，BT Client之間是對等的，他們相互傳輸數據，更應該是服務端校驗客戶端，而不是HTTPS的客戶端校驗服務端。而且因爲BT Client是部署在用戶的節點，還須要考慮證書和私鑰都被劫持的風險。

 

咱們是怎麼作的

• Client之間

BT Client間傳輸數據確定是須要加密的，防止鏈路的數據被劫持。可是隻增長HTTPS，雖然鏈路被加密，可是客戶端可能會被假冒，只要假冒者不校驗服務端的證書，直接和服務端握手，就能從其餘BT Client獲取到他想要的數據。

 

咱們借鑑HTTPS的實現，採用了雙向驗證的模式。

須要有證書，首先須要一個統一的CA（簽發機構），所以咱們在Tracker中保存證書和私鑰作爲簽發機構，Proxy獲取種子的同時返回CA，用戶校驗客戶端的證書。

而後，只使用一個證書對而且放在Bt Client是危險的，頗有可能性被入侵截獲到證書，所以咱們獲取證書的方式改成從Tracker獲取，獲取種子的同時獲取Tracker生成的臨時證書私鑰對，把它加入BT Client的下載隊列。在BT Client開始相互鏈接時，首先相互確認對方的證書的有效性（簽名、簽發機構等信息），校驗經過後才能請求並相互下載數據。

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

1. 鏈路通過證書加密，直接截獲鏈路是不可行的
2. 即便仿照BT Client的方式，因爲Client每一個鏈接都須要進行雙向的證書校驗，想經過這個方式截獲數據就必須請求Tracker去獲取，而訪問Tracker首先是HTTPS的，而後咱們還作了業務層的安全校驗（下文業務層安全會說起），也是不可行的。

• Docker Daemon 到 Proxy

咱們在Proxy中須要劫持Docker的請求，由於Docker在不配置時訪問Registry採用的是HTTPS，所以Proxy劫持Docker請求就必須和Docker保持HTTPS鏈接。

咱們讓客戶端代理只監聽localhost端口，杜絕外部使用該代理的可能性。同時，客戶端代理綁定一套臨時生成的簽發給registry域名的自簽名證書和CA證書，用於劫持Docker Daemon的請求，並將CA證書添加到機器的信任證書當中。

代理綁定的證書只保存在內存中，即便經過特定方式獲取到當前節點的CA證書和服務端證書，也沒法截取其餘節點數據。

• 從用戶節點到Registry、Tracker

首先，爲了確保鏈路的安全，Regstry、Tracker都綁定從權威第三方機構購買的HTTPS證書私鑰對。Proxy和BT Client在訪問它們的時候都會去校驗證書的有效性，只要在證書有效的狀況下才發送請求，這從根源上杜絕了Regstry、Tracker被假冒的可能。

 

1.3.2 業務加密

在確保鏈路安全後，咱們還作了一層業務安全加固。首先咱們先了解下JWT Token。

Json web token（JWT）是爲了網絡應用環境間傳遞聲明而執行的一種基於JSON的開發標準（RFC 7519），該Token被設計爲緊湊且安全的，特別適用於分佈式站點的單點登錄（SSO）場景。JWT的聲明通常被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也能夠增長一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

在咱們使用Docker命令下載鏡像時，Docker首先會到Registy獲取Token，在以後的獲取鏡像層的過程當中，多會帶上該Token用於鑑權。其中Token時組要包含如下信息：

1. 用戶信息
2. 資源信息，爲操做的鏡像和namespace的名稱
3. 權限信息：是否有PULL/PUSH權限
4. 用於解析Token簽名的證書

利用JWT Token中自帶解析Token證書這個特性，咱們在BT Client間通訊又增長了Token的校驗。在前文中的證書校驗經過後，客戶端須要發送Token給服務端用於校驗。爲了防止Token被假冒，入侵者採用第三方生成，咱們使用服務端截從Docker截取的Token中的證書解析校驗客戶端的Token，杜絕這種狀況。

同時，Proxy 訪問Tracker的接口也會帶上這個Token，Tracker會校驗Token的權限，完成業務層的安全驗證，防止證書和種子被盜取。

經過以上鍊路層和業務層的安全加固，用戶數據被盜取的可能性已幾乎爲零。若是你們有更好的建議，歡迎點評。

 

點擊這裏，瞭解更多精彩內容