在最近谷歌云平台（Google Cloud Platform，简称GCP）博客探讨容器安全的系列文章中，GCP团队已经提供了现有和拟议的开源软件供应链项目的更多细节。首先，Grafeas是通用API和语言，用于存储、查询和检索跟软件组件有关的元数据，诸如构建细节、测试状态和已知的安全问题。其次，Kritis是一个拟议的软件供应链管理框架，它允许使用存储于Grafeas中的元数据与Kubernetes构建和实施实时部署策略，这可以避免发布存在已知问题的容器镜像。
扩内需促消费再迎新突破路径，十余省份正竞逐供应链创新高地
扩内需促消费再迎新突破路径，十余省份正竞逐供应链创新高地，一方面密集发布供应链新政，着力打造产业集群和供应链金融等；另一方面紧锣密鼓推进供应链创新与应用试点申报，计划5月底前完成。国家层面则正酝酿出台更多供应链创新配套支持政策，涉及平台建设、制度安排、财税金融支持等方面。探索全球供应链数字化，新经...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以只允许容器镜像由特定私钥签名的教程。