<p>在Docker内部，我们花了很多时间讨论一个话题：如何将运行时安全和隔离作为容器架构的一部分？然而这只是软件流水线的一部分。</p>    <p>我们需要的不是一次性的标签或设置，而是需要将安全放到软件生命周期的每个阶段。</p>    <p>由于软件供应链上的人、代码和基础设施一直在改变，交互也越来多，组织（公司）必须将安全纳入供应链的核心部分。</p>    <p>考虑一个实际存在的产品：如电话，仅仅考虑到最终产品的安全性是不够的。除了决定使用什么样的防盗包装，你可能也想知道材料的来源，以及他们是如何组装，包装，运输。因为，重要的是我们还要确保手机不被改造或运输途中被盗。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/1bfc1befa75495e2d010adf33d6f5250.jpg"></p>    <p>软件供应链几乎跟实际产品的供应链是相同的。你必须能够识别和信任原材料（代码、依赖、打包），把它们组装在一起后，将它们从海上、陆上或空中（网络）运输到一个存储地（存储库），以便将项目（应用）出售（部署）给终端用户。</p>    <p>确保软件供应链也十分相似。你需要：</p>    <ul>     <li> <p>确定流水线中的所有东西，从人，代码，依赖关系，到基础设施</p> </li>     <li> <p>确保一个一致和优质的构建过程</p> </li>     <li> <p>在存储和运输中保护产品</p> </li>     <li> <p>对材料清单的交付保证并验证最终产品</p> </li>    </ul>    <p>在这篇文章中，我们将诠释Docker的安全特性如何为软件供应链提供持续的安全。</p>    <h2><strong>身份</strong></h2>    <p>整个流水线构建在身份验证和访问控制之上 。从根本上说，你需要知道谁可以访问什么资产，可以使用哪些操作。</p>    <p>Docker 架构中的身份认证理念很清晰，它隐藏在软件供应链策略中：加密密钥允许发布者对镜像进行签名，以保证其来源的真实性。</p>    <h2><strong>一致的构建：好的输入= 好的输出</strong></h2>    <p>确定一致的构建允许你创建一个可重复的过程，并控制你的应用程序依赖和组件，以便使它更容易测试出缺陷和漏洞。当你对你的组件有一个清晰认识的时候，它变得更容易识别异常的组件。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c8f642945528677481e7d1a0b5fb4c88.png"></p>    <p>要获得一致的构建，你必须确保你添加了优质的组件：</p>    <ul>     <li> <p>评价依赖的质量，确保它是最新/兼容的版本，并用你的软件进行测试</p> </li>     <li> <p>验证组件来自于你期望的来源，并且在传输过程中没有损坏或改变</p> </li>     <li> <p>确定依赖后不要轻易改变，确保后续重建是一致的，因此如果一个缺陷是由代码或依赖的变化引起的，很容易被发现</p> </li>     <li> <p>使用Docker Content Trust ，从可信的、有标识的基础镜像中构建你的镜像</p> </li>    </ul>    <h2><strong>使用签名”密封”构建结果</strong></h2>    <p>应用程序签名是从构建进行有效“密封”的一步。通过镜像签名，可以确保任何在接收端（docker pull）的签名验证与镜像发布者建立一个安全链。</p>    <p>这种关系保证了镜像在传输过程中不被改变、添加、或删除。此外，签名表明发布者“赞同”你拉取的该镜像是没问题的 。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/731ef063f897c4913b4ac2bd678c7f71.png"></p>    <p>在构建机器和运行环境上启用 Docker Content Trust后，一个策略就会生效：只有签名镜像才可以被拉取并运行在那些 Docker 主机上。</p>    <p>在组织中，签名的镜像向其他人传递一个信号：发布者（构建者）声明镜像是没问题的。</p>    <h2><strong>安全扫描和风控</strong></h2>    <p>CI系统和开发者都需要确认一件事情：构建工具与依赖一起工作，操作你的应用程序时，无论在成功还是失败，都有预期的行为。</p>    <p>但他们审查过依赖的漏洞吗？审查过子依赖或捆绑系统库的依赖吗？他们知道依赖的许可证吗？这种审查很难通过常规的方式来完成，因为提供错误修正和功能上是一个巨大的开销。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/bd80e8ff9157cab6567051276660e1a1.jpg"></p>    <p>Docker 安全扫描有助于镜像的自动化扫描。因为这是发生在镜像被推送到registry之前，在容器被部署进生产环境之前的最后一次检查。</p>    <p>该功能目前在Docker Cloud 中可用，并且很快延伸到Docker Datacenter。安全扫描创建了一个清单，清单中包括镜像每一层的打包信息和版本信息。</p>    <p>这份材料清单被用于连续监测各种 CVE 数据库。确保该扫描不止一次地发生，并在爆出新漏洞时，及时通知使用镜像的系统管理员或应用程序开发者。</p>    <h2><strong>多重签名-- 把签名绑在一起</strong></h2>    <p>安全保证最强大的一点来自Docker Content Trust 签名，它允许多个签名者参与容器的签名过程。要了解这一点，想象一个简单的 CI 过程，通过以下步骤移动容器镜像：</p>    <p>1.  自动化CI</p>    <p>2.  Docker 安全扫描</p>    <p>3.  推送到 staging环境</p>    <p>4.  推送到 production 环境</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/eb18ff630880ba371751f5f17fd7948b.jpg"></p>    <p>这里有四个阶段，每个阶段完成后，都可以添加一个签名，从而CI/CD 过程的每一个阶段都有验证。</p>    <p>1、镜像通过CI 吗？添加签名！</p>    <p>2、Docker Security Scanning 确定镜像没有漏洞？添加签名！</p>    <p>3、staging阶段中构建成功？添加签名！</p>    <p>4、验证所有3个签名的镜像并将其部署到生产中</p>    <p>现在构建被部署到生产集群之前，它可以加密验证，CI / CD过程各阶段已经签订了一个镜像。</p>    <h2><strong>结论</strong></h2>    <p>在软件生命周期的每个环节，Docker 平台都允许企业将安全纳入其中。从与用户建立信任，到基础设施和代码，docker模型给了开发者以及 IT团队足够的自由和控制力。</p>    <p>从构建安全的基础镜像，到扫描每一个镜像验证签名，每个特性都允许IT人员将信任植入到应用中。</p>    <p>当应用沿着正常的生命周期不断前行，安全信息也能够动态维护和更新，并在部署到生产环境之前通过风控检查。</p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s?__biz=MzIwNzA1MTA5OA==&mid=2888434923&idx=1&sn=210c7d1fabdd7ba89ad316f62dabe7c1&chksm=bec6e4de89b16dc89cc365a70a30da16fba391f23e71267c69d52b29098d0653a3e3ae644cb0&scene=4</p>    <p> </p>