问题：
在使用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下载，最大限度的租户间的数据泄露。
之后，在链路层面的安全性和业务层面的安全性做了增强。
链路层面的安全性：
Docker Daemon<------->Proxy
首先是Docker Daemon到Proxy这条链路。我们让客户端代理只监听localhost端口，杜绝外部使用该代理的可能性。同时，客户端代理绑定一套签发给registry域名的自签名证书，用户劫持Docker Daemon的请求。各个代理绑定的服务端证书和CA证书都是Proxy在启动的过程中临时生成的，并将CA证书添加到机器的信任证书当中。
代理绑定的证书只保存在内存中，即使通过特定方式获取到当前节点的CA证书和服务端证书，也无法截取其他节点数据。
BT Client通信安全和一致性：
在P2P下载过程中，种子包含以下信息：• length:文件长度，单位字节(整数)
• md5sum(可选):长32个字符的文件的md5校验和，bt不使用这个值，只是为了兼容一些程序所 保留!(字符串)
• name:文件名(字符串)
• piece length:每个块的大小，单位字节(整数)
• pieces:每个块的20个字节的sha1hash的值(二进制格式)
常用的BT Client未做Client之间的数据加密，只在每块数据下载完成后校验数据的sha1hash值是否与pieces中的值一致。
我们在BT Client之间增加了SSL双向认证及加密通信，为每个layer生成了CA证书，并为每个下载该layer的Client生成服务端证书。当Client间握手时，需确保对方的服务端证书为layer的CA证书签发的，并且对方的服务端证书必须是签发给当前layer的。
这种增强，确保了在传输过程中，用户的layer数据时加密的，即使劫持了链路也无法获得数据。业务层的安全性 ：
在确保链路安全后，我们还做了一层业务安全加固。在Client间SSL握手成功后，还需要完成用户JWT Token的校验。
JWT Token中包含Token解密证书、用户的基本信息和对镜像的操作权限，解密证书让用户可本地解析Token的信息。
根据JWT Token的这个特性， 我们增加了Token校验的逻辑。
采用本地Token的解密证书校验连接发起者的Token，可以确保连接发起者的Token不是自签发的Token。
校验Token中的操作权限，确保连接发起者的对该镜像层有下载权限。
上述链路层和业务层安全性的增强，使得P2P镜像下载适用于公有云场景，确保用户数据的安全。目前，菊厂容器镜像新上线特性P2P，据说实力超群可以超越蜻蜓，有兴趣的朋友可以前来一试~
https://www.huaweicloud.com/product/swr.html