电商业务容器化遇瓶颈，公有云Docker镜像P2P加速很安全

当前，电商平台会采用基于Docker的容器技术来承载618大促期间的一些关键业务版块，包括最简单的商品图片展示、订单详情页面等等。

通过容器化改造，电商平台的每个业务版块解耦，可以独立开发、部署和上线，从而让后台业务系统具备更高的稳定性、可扩展性和安全性，即便某个环节出现问题，也能保障平台高峰值期间的平稳运行。

镜像是Docker容器的基石，只有通过它才可以创建容器，而Registry是存放Docker镜像的仓库。但在实际应用中，由于需要频繁地从Registry下载镜像运行容器应用（比如发布新版本，打补钉等情形），其间的文件传输成为镜像分发的瓶颈，

P2P加速镜像下载是有效的解决方案，但如何确保用户数据在公有云环境下的P2P传输安全性尤为关键，本文主要从链路层和业务层的安全加固，阐述了公有云Docker镜像P2P加速的安全性。

问题：

在使用Docker运行容器化应用时，宿主机通常先要从Registry服务（如Docker Hub）下载相应的镜像(image)。这种镜像机制在开发环境中使用还是很有效的，团队成员之间可以很方便地共享同样的镜像。然而在实际的生产环境中，当大量主机需要同时从Registry下载镜像运行容器应用时（比如发布新版本，打补钉等情形），Registry 服务往往会成为镜像分发的瓶颈，应用镜像需要较长时间才能传送到所有主机上，使得应用发布的周期大大延长。

不少企业提出了P2P加速镜像下载的解决方案，但都是私有云及内部环境的使用场景，在公有云未得到使用。其中很大一部分原因是公有云使用P2P的安全性问题，如何确保用户数据在P2P传输中是安全的成为了其中的难点。我们就该问题设计实现了确保用户数据安全的P2P镜像分发系统。本文就其安全性展开阐述。

架构：

华为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客户端完成整个通信过程。

安全：

首先，我们限制了跨集群的P2P下载，最大限度防止租户间的数据泄露。

之后，在链路层面的安全性和业务层面的安全性做了增强。

链路安全

一想到链路安全，我们首先会想到的是加密。

对称加密服务端和客户端采用相同的秘钥加密和解密，只要这个秘钥不公开，并且秘钥足够安全，那么链路就是安全的。但是在网络中都使用相同的对称加密秘钥，无异于公开传输，如果秘钥被劫持，那么就可以篡改链路的所有数据。

然后我们肯定会想到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被假冒的可能。