背景

上篇Grafeas项目调研讲到了如何把制品(Artifacts)的一系列相关的元数据信息，比如CVE这些通过一套标准的Metadata API记录下来。既然Grafeas充当了一个信息生产者(Producer)的角色，那么自然还需要有这些信息的消费者(Consumer)，Kritis就是作为Grafeas的孪生项目，起了这样的作用。

Kritis(希腊语Judge)，logo是一只抓着法槌的猫头鹰，这个项目根据存在Grafeas的制品信息，对制品的准入进行限制，比如说

• 镜像只有在没有严重CVE的时候，才能上线
• 只有通过了QA的测试才能上线

详细说明

上图是整套体系在GKE的展示，Kritis包括了Binary authorization + Policy的部分。而左边CI/CD pipeline则是产生了制品的元数据，保存在Image metadata(Grafeas)中。在制品上线时，Binary authorization结合Policy和Image metadata来决定是否允许部署镜像到线上。这个Check是利用了kubernetes Dynamic Admissioin Control的机制，通过webhook集成的。同时Kritis会跑一个定时Cron，来检查目前在线上运行的镜像是否符合Policy，如果不符合的话，则会添加kritis.grafeas.io/invalidImageSecPolicy的标签，代码片段

除了准入时所用的webhook外，Kritis目前核心的有3个CRD(Custom Resource Definition)

• GenericAttestationPolicy
• ImageSecurityPolicy
• AttestationAuthority

其中GenericAttestationPolicy和AttestationAuthority对应的是Grafeas里的Attestation模型，用于CI Pipeline场景，比如说某个制品通过了Pipeline里的集成测试阶段，就会生成一个integration-test-passed的Attestation。Kritis的GenericAttestationPolicy可以定义说制品必须满足integration-test-passed条件，才能部署上线。还比如说通过签名验证的方式确保镜像没有被篡改，也是通过GenericAttestationPolicy来实现。

ImageSecurityPolicy对应的是Grafeas里的Vulnerability模型，用于CVE场景，比如说某个镜像必须没有高于中等严重程度的CVE，才能部署上线。

除了webhook以及CRD, Kritis本身是不保存任何状态的。

未来展望

和Grafeas类似，Kritis项目也处在比较早的阶段，而且和Google的绑定更加明显，目前应该只是在Google自己的GKE上落地了。接下来的一些可能工作包括

• 目前的准入判定是在Pod创建时，这个是兜底的卡点。但是许多Pod创建是异步操作，目前的方案会带来体验的问题，比如用户进行Pod创建，即使不符合Policy，无法立马获得反馈。这个就需要在异步创建时也引入判定能力，类似于提供dry-run机制。
• 类似于Grafeas一样，需要集成到主流的CI/CD工具中去。
• Kritis虽然是Grafeas的孪生项目，目前也只集成了Grafeas的API，但其实也可以扩展集成其它的Metadata API，当然这个可能违背了整体项目的初衷。

结语

+ 

可信云原生软件供应链Grafeas, Kritis的两篇小文到此收尾。回到介绍Grafeas里提到的，可信软件供应链会是一块越来受到关注的领域:

• 随着持续集成以及微服务成为主流，我们发布软件的频率极速上升。
• 随着应用越来越复杂，以及开源的趋势，一个应用依赖了越来越多的三方依赖。
• 随着应用基本功能的日趋完善同质化，诸如安全/合规类的特性会成为竞争关键点。

Google发起的这两个项目定义了一套云原生时代标准的可信软件供应链接口，这里面其实也还包含了一个核心，就是Immutable，我们目前最常用的使用tag来引用镜像的方式很难保证这点，所以很有可能需要使用digest方式来引用镜像，这个对于整个镜像的使用习惯会产生不小的影响。