微软 Azure 在容器供应链安全的开源实践

点击上方蓝字

关注我们

（本文阅读时间：11分钟)

✦ 什么是容器供应链安全

✦ 容器供应链安全在现代软件开发中的挑战

✦ CNCF 中的容器供应链安全开源项目与生态

✦ 微软 Azure 在容器供应链安全的实践与贡献

    Microsoft/SBOM Tool 如何构建软件透明性

    Notary v2 如何帮助实现镜像安全的一致性

    ORAS 如何扩展 OCI 赋能供应链安全 

    Ratify 如何帮助 Kubernetes 验证应用的部署安全  

✦ 展望

什么是容器供应链安全

近两年，随着软件开发自身安全防御力度不断加大，攻击者把攻击目标由目标软件转移到软件供应链最薄弱的环节，软件供应链安全事件与漏洞频发，软件供应链安全的话题被越来越多的企业广泛关注。

事实上，现代软件开发与部署的流程其实与传统的生产制造行业是非常相似的，软件开发商在开发过程中会引入大量第三方组件以及开源软件，与自身业务开发组成一个完整的应用软件，构建流程会将这些组件最终打包成为可部署的软件包分发到不同的用户环境，然后被用户部署到生产环境中。这套流程就是我们常说的软件供应链，软件供应链安全的目标就是保软件从开发到部署上线的整个生命周期的安全性、一致性和可靠性。

在以 Kubernetes 为底座的容器微服务时代，容器成为了软件开发过程中打包与分发的标准，那么保障容器供应链安全也是企业面临的新的挑战。

容器供应链安全在现代软件开发中的挑战

如果说2020年是传统生产制造供应链安全被广泛关注的一年，那么2021年则是广大企业和开发者对软件供应链安全意识兴起的一年。在2021年发生多起让全行业都密切关注的网络攻击事件，比如美国一些政府机构在内的数以千计的客户下载了受损的 SolarWinds 更新软件而受到影响，以及在全球影响更为广泛的 Log4j 安全漏洞事件，造成了大量的流媒体网站、在线交易平台的日志系统阶段性地被停服。

在2022年初，专家预测2022年将成为开源软件供应链安全元年。我们在当前时间点，不妨来对目前业内的一些流行和新发起的供应链安全开源项目进行简单的回顾，并侧重介绍微软 Azure 在容器供应链安全的开源实践。

CNCF 容器供应链安全开源项目与生态

在开源社区中有大量的用于解决上述提到的容器与软件供应链安全相关问题的开源项目，例如 OpenSSF 基金会是 Linux Foundation 旗下在2020年成立的专为开源软件安全而创立的中立开源组织，专为孵化和托管开源安全领域的项目，以及跨行业连接上下游的厂商和最终用户的合作，建立更广泛的开源安全行业标准，旗下开源项目如 Sigstore 和 Alpha-Omega。

CNCF 云原生计算基金会具有更广泛的职能，其下也有多个开源项目是专为容器环境下的软件供应链安全与生态服务的，比如已经在 CNCF 毕业的The Update Framework (TUF)、Open Policy Agenda (OPA)，还在 Incubating 阶段的项目 in-toto、Notary、Falco、Kyverno，并且 Sandbox 阶段也有11个新兴的开源项目是专注在 Security & Compliance 方向，比如 KubeArmor、Dex 、Confidential Containers、ORAS 等，详情可参考 CNCF Sandbox 项目。此外，在 CNCF 全景图中还列出了更多安全相关的开源项目和解决方案厂商。

• CNCF Sandbox 项目：

  https://www.cncf.io/sandbox-projects/

微软 Azure 在容器供应链安全的开源实践

▍Microsoft/SBOM Tool 如何构建软件透明性

SBOM 就像食品的成分列表一样，是软件中组件和服务的列表，类似于制造和产品开发中的供应链文档。提升软件供应链安全的本质是需要提升软件开发与分发过程的透明性。Gartner 预计软件物料清单（SBOM）的采用率在 2025 年将会达到 60%。并且在 2021 年，美国联邦政府在《关于改善国家网络安全的行政命令》指出，要求政府机构消费和生产的所有软件都使用 SBOM。Kubernetes 社区也在大力推动安全基础建设，从 1.21 版本开始，所有发布的组件将包含相关 SBOM 信息。这些案例都充分说明了 SBOM 在未来软件开发流程中的必要性。

Microsoft/SBOM Tool 是微软近期开源的一个 SBOM 生成工具，使用标准的软件包数据交换 (SPDX) 格式，帮助企业了解帮助企业其软件供应链对第三方软件的依赖情况。SBOM  Tool 可以被轻松集成，并自动检测 NPM、NuGet、PyPI、CocoaPods、Maven、Golang、Rust Crates、RubyGems、Docker 容器内的 Linux 软件包、Gradle、GitHub 代码仓库等，未来会支持更多软件包平台的 Detector。对 SBOM Tool 感兴趣的同学可以参考文末提到的 ORAS 技术博客中的示例来下载和体验完整的流程。

• 《关于改善国家网络安全的行政命令》：

  https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

• Microsoft/SBOM Tool：

  https://github.com/microsoft/sbom-tool

▍Notary v2 如何帮助实现镜像安全的一致性

Notary v2 是微软 Azure、Docker 和 AWS 联合发起的项目，用于对软件制品如容器镜像、SBOM、安全扫描结果等内容进行签名（Sign）和验证（Verify），确保软件开发、打包与部署环节的一致性。

在介绍 Notary v2 之前，我们需要回顾一下它的前身 Notary v1，最初由 Docker 公司于 2015 年发起，基于 TUF 框架，旨在为 Docker 容器提供通用的镜像签名基础设施，Docker 目前支持 Docker 容器签名的“docker trust”命令和验证签名等功能正是依赖于 Notary v1 提供的能力。Notary v1 基于 TUF 框架虽然安全性很高，但它最大的问题在于过于使用复杂并且签名缺乏可移植性，并且不支持在离线和边缘环境使用。此外 Notary v1可用性也不够理想，特别是在 Kubernetes 环境下缺乏用于签名检查的标准接口，对秘钥（Key）管理都会非常困难，Notary v1 所存在的问题以及与业内多家公司联合发起 Notary v2 的原因，Docker 公司的首席技术官JUSTIN CORMACK 曾在 Docker官方博客与 KubeCon 中进行了详细说明。

因此，Notary v2 的出现正是为了找到在安全性和易用性之间的最佳平衡，并解决 Notary v1 存在的诸多技术瓶颈和挑战，通过开源的方式为业内提供通用且易用的软件制品签名与验证方案。

Notary v2 目前完成了其项目原型阶段的设计，并发布了 CLI 和 API 的  Alpha.4 版本，为用户和开发者提供了对 OCI  软件制品的签名与验证等核心功能，支持在线和离线环境使用，同时还提供了灵活的插件机制，支持第三方云厂商通过插件的方式在 Notary v2中扩展和对接其 Key Management System 与生态。对 Notary CLI 感兴趣的同学可以下载最新的 Alpha.4 版本来体验以下命令：

• 微软 Azure、Docker 和 AWS 联合发起的项目：

  https://www.docker.com/blog/community-collaboration-on-notary-v2/

• Docker官方博客：

  https://www.docker.com/blog/community-collaboration-on-notary-v2/

▍ORAS 如何扩展 OCI 赋能供应链安全

OCI（Open Container Initiative）是 Linux 基金会下的轻量级开放容器标准的项目，致力于围绕容器格式和运行时创建开放的行业标准。在上述提到的 Notary v2 和 SBOM Tool 在软件供应链中会产生签名（Signature）和 SBOM 文件，以及像 Helm Chart 和 AI 模型等制品，这类文件都属于非 OCI 标准所支持的类型，而在实际的容器开发场景，要满足软件供应链安全的需求，开发者通常需要将生成的 Signature 和 SBOM 添加到容器镜像或制品中，与容器镜像建立依赖关系并形成一个新的制品，最终将制品推送到镜像注册表（Registry）供部署使用。

由于 OCI 此前尚未支持对 Signature和 SBOM 文件的声明式支持，同时 OCI 在 Distribution-spec 中也未声明支持存储包含 Signature和 SBOM 的软件制品，而这又是容器供应链安全的刚需。为了解决业内普遍存在的痛点和拓展 OCI 标准，ORAS （OCI Registry As Storage）项目应运而生。

ORAS 目前提供了 CLI、API/SDK for Golang & Python，以及新的软件制品标准 Artifact-spec。ORAS CLI 目前已支持对兼容 OCI 标准的镜像注册表和符合 OCI标准的文件内容进行细粒度的管理。最近刚发布的 ORAS CLI 0.15 提供了非常完善而易用的命令，在用户体验上跟大家熟悉的 Docker 类似，几乎没有额外的学习成本。

目前 ORAS 已被 AWS ECR、Azure ACR、VMware、Red Hat、Alibaba Cloud 所采用。对 ORAS 感兴趣的朋友可以参考 ORAS 两篇最新的技术博客快速体验 CLI 以及应用场景。

• 技术博客：

  https://oras.land/blog/oras-0.14-and-future/

▍Ratify 如何帮助 Kubernetes 验证应用的部署安全

在构建一个以 Docker 容器环境和 Kubernetes 平台为底座的软件供应链安全流水线中，从最初的代码开发与构建到最终的应用部署上线，Notary v2 与 SBOM Tool 已经在容器镜像签名和生成 SBOM 文件的环节中起到了核心作用，而 ORAS 则是帮助开发者将这些生成的文件在不同容器注册表与多运行时中进行管理与分发，那么在附加了这些文件的容器镜像制品被部署到 Kubernetes 平台之前，谁将会把关和验证在上述一系列流程中的镜像、镜像签名与 SBOM 未被篡改，确保开发与流程生产部署环境一致性安全呢？

Ratify 作为云原生环境下的准入控制器和通用的验证框架，支持对接任意标准的 Kubernetes 发行版（如 AKS 与 EKS），同时可以与 Open Policy Agent 或 Azure Policy 结合来对已经签名过的内容进行细粒度的验证，如果符合安全与准入策略，那么这些镜像制品资源将会被顺利地部署到 Kubernetes 中从而暴露服务给客户访问。反之，如果验证失败则终止下一步。

展望

随着越来越多的客户生产环境运行在多云与混合云，容器供应链安全在当下和未来都将是全行业共同面临的风险和挑战，而实现真正的端到端的软件供应链安全同样需要整个行业的合作与努力。我们看到近期众多组织和开源社区加大了在基础设施安全的投入和合作，可以预见在容器供应链安全领域的开源项目将会百花齐放。

微软之所以选择发起 SBOM Tool、Notary v2、ORAS、Ratify 等开源项目，并将 Notary v2 和 ORAS 捐给 CNCF，目标是为了与业内更多组织进行合作以打造更加通用的标准与易用的工具，实现端到端的软件供应链安全环境。接下来，我们会针对以上提到的这几个开源项目提供更深度的技术解读与实践教程，期待对容器供应链安全有共同需求或痛点开发者朋友们进行探讨和交流。

参考链接

• Microsoft/SBOM Tool:

  https://github.com/microsoft/sbom-tool

• ORAS 0.14 and Future: Empower Container Secure Supply Chain:

  https://oras.land/blog/oras-0.14-and-future/

• Community Collaboration on Notary v2:

  https://www.docker.com/blog/community-collaboration-on-notary-v2/

• Notary v2 project:

  https://github.com/notaryproject/notation

• Ratify project:

  https://github.com/deislabs/ratify

*未经授权请勿私自转载此文章及图片。

欢迎扫码访问 Azure 上的 Docker

进一步了解如何在云中保护和管理企业容器应用

点击「阅读原文」，了解更多内容~