使用“Grafeas”元数据 API 和“Kritis”部署授权管理软件供应链

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

在最近谷歌云平台（Google Cloud Platform，简称 GCP）博客探讨容器安全的系列文章中，GCP 团队已经提供了现有和拟议的开源软件供应链项目的更多细节。首先， Grafeas 是通用 API 和语言，用于存储、查询和检索跟软件组件有关的元数据，诸如构建细节、测试状态和已知的安全问题。其次， Kritis 是一个拟议的软件供应链管理框架，它允许使用存储于 Grafeas 中的元数据与 Kubernetes 构建和实施实时部署策略，这可以避免发布存在已知问题的容器镜像。

GCP 的博客文章指出，容器技术已经使快速创建、修改以及共享打包在容器镜像工件中的应用程序变得轻松容易。然而，随着部署速度的这种潜在增长，可能要对安全性进行权衡，比如需要验证容器化的应用程序是否已经通过质量保证，以及应用程序和镜像是否包含任何已知安全漏洞。回答这些问题的一种方式是追踪跟容器有关的元数据，例如，谁在使用它、功能和非功能测试运行的结果，以及它是否有任何已知漏洞。

去年 10 月，谷歌和几个合作伙伴发布了Grafeas ，Grafeas 是一个开源项目，为容器镜像提供结构化的元数据API。 Grafeas 简化了元数据的处理，包括像软件包漏洞扫描结果的安全问题，并保持对这些信息的追踪：

• “构建”元数据能被用于验证容器镜像是根据构造策略使用具有签入源代码、受信任的构建器构建的。
• “程序包漏洞”元数据包含来自漏洞扫描服务的信息，并允许组织创建部署易受攻击的容器的策略。
• “镜像基础”元数据包含有关来自被检索容器的基础镜像的信息，以及用于构建容器镜像的附加层。
• “包管理器”元数据指明在容器镜像中所安装的软件包。
• “部署历史”元数据允许追踪哪些资源在何时被部署。

Grafeas 使用两个 API 概念，分别是备注和事件。该文档指明，该部门允许第三方元数据供应商代表很多客户创建和管理元数据。

• 备注是能够通过分析找到的或在过程中多次使用的项目和条件。例如，CVE 可能是 Linux 软件包漏洞分析的结果。在构建过程中，关于构建器的信息会被存储于备注中。
• 事件可以被认为是备注的实例，并描述了在具体的云资源或项目（如：位置、具体的补救步骤等等）中如何找到该备注，或者具体的备注结果是什么（比如：由构建产生的容器镜像）。例如，事件可能会报告在容器镜像的具体软件包中找到最致命的 OpenSSL 错误（一个可能的备注），并包含如何根据客户的软件包补救最致命错误的有关信息。

为了正确地把存储在 Grafeas 中的元数据聚合起来，存储的每种信息都有严格的模式。这些模式允许规范化来自多个供应商的数据、使用户能够随着时间的推移看到其组件中有意义的见解。当前支持的模式类型如下图所示：

需要支持新的元数据时，能够添加新类型，每种类型都有自己的模式。

追踪Grafeas 的元数据能让团队了解哪些容器存储于他们的环境中，并在哪些容器得到部署上实施限制。在部署前，工程师可以审查Grafeas 元数据，确认其是否符合策略。另一种类型的元数据是“认证（Attestation）”，它是对一个事实的确认或认证，被用于这个目的（在商业上，认证是一个由会计师或审计师实施的过程，是对公诸于众的公司、公共机构或其他组织的财务或其他业务信息提供独立意见）。如果从Grafeas 中提取的元数据与组织策略一致，就可以写一个证明以确认镜像符合部署要求的规定。下图来自 GCP introduction to Grafeas ，总结了该工具如何适用典型的持续交付管道：

在最近发布的白皮书中，GCP 团队已经提出了“ Kritis ”，这是 Kubernets 的一个部署授权框架。Kritis 框架的核心部分是 Kubernetes 准入控制器（Kubernetes Admission Controller），用于检查预期的认证，如果它们不存在时，就会阻止部署。该白皮书指出，除了基本准入控制外，Kritis 还提供对“工作流实施、多机构签署、紧急部署等”的支持。一个叫做二进制授权（Binary Authorization，简写为 BinAuthz）的托管 Kritis alpha 实现，目前可以在谷歌容器引擎（Google Container Engine，简写为 GKE）上使用，不久之后的开源代码版也已列入计划。

BinAuthz 的关键概念是“认证机构（Attestation Authority）”和“策略（Policy）”，这是通过 REST API 管理 REST 资源实现的。认证机构是一个有权创建认证的命名实体。作为 REST 资源，它囊括了其认证的位置（在哪里存储和从哪里检索），以及验证标准（什么可证明有效）。然后，策略将认证机构命名为需要向某个目标部署工件的认证机构。认证机构命名（类型为“ATTESTATION”的）Grafeas Note，用来作为这个机构认证的锚点，并且如果认证必须签字，可以有选择地指定公钥。然后，该机构的认证可以以 Occurrences 为代表附加到该机构的备注上。

Spotify 最近讨论了他们如何把 Grafeas 和 Kritis 作为每天超过 6000 个容器构建的元数据以及在他们主容器注册的 33 万个镜像的真实性的核心来源。这使安全团队能够交付给用户实施适当的审计和生命周期策略。在持续的集成过程中，对容器（包括名为 kubeaudit 的本土安全审计工具的使用）实施了一系列审计，并且利用 PGP 以加密方式生成认证并签名，以确保其构建器和其他认证机构的身份。这些证明构成了在 Kubernetes 上使用 Kritis 实施的策略。

关于 Grafeas 的更多信息可以在该项目的文档和 GitHub repository 上查看。Grafeas 能用于实施多种安全策略，Kelsey Hightower 已经提供了一个关于如何使用 Grafeas 以只允许容器镜像由特定私钥签名的教程。

阅读英文原文： Managing the Software Supply Chain with the “Grafeas” Metadata API and “Kritis” Deploy Authorization

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。