背景
上篇
Grafeas項目調研講到了如何把制品(Artifacts)的一系列相關的中繼資料資訊，比如CVE這些通過一套标準的Metadata API記錄下來。既然Grafeas充當了一個資訊生産者(Producer)的角色，那麼自然還需要有這些資訊的消費者(Consumer)，Kritis就是作為Grafeas的孿生項目，起了這樣的作用。
Kritis(希臘語Judge)，logo是一隻抓着法槌的貓頭鷹，這個項目根據存在Grafeas的制品資訊，對制品的準入進行限制，比如說
- 鏡像隻有在沒有嚴重CVE的時候，才能上線
- 隻有通過了QA的測試才能上線
https://developer.alipay.com/article/10895#1 詳細說明
上圖是整套體系在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本身是不儲存任何狀态的。
https://developer.alipay.com/article/10895#2 未來展望
和Grafeas類似，Kritis項目也處在比較早的階段，而且和Google的綁定更加明顯，目前應該隻是在Google自己的GKE上落地了。接下來的一些可能工作包括
- 目前的準入判定是在Pod建立時，這個是兜底的卡點。但是許多Pod建立是異步操作，目前的方案會帶來體驗的問題，比如使用者進行Pod建立，即使不符合Policy，無法立馬獲得回報。這個就需要在異步建立時也引入判定能力，類似于提供dry-run機制。
- 類似于Grafeas一樣，需要內建到主流的CI/CD工具中去。
- Kritis雖然是Grafeas的孿生項目，目前也隻內建了Grafeas的API，但其實也可以擴充內建其它的Metadata API，當然這個可能違背了整體項目的初衷。
https://developer.alipay.com/article/10895#3 結語
+
可信雲原生軟體供應鍊Grafeas, Kritis的兩篇小文到此收尾。回到介紹Grafeas裡提到的，可信軟體供應鍊會是一塊越來受到關注的領域:
- 随着持續內建以及微服務成為主流，我們釋出軟體的頻率極速上升。
- 随着應用越來越複雜，以及開源的趨勢，一個應用依賴了越來越多的三方依賴。
- 随着應用基本功能的日趨完善同質化，諸如安全/合規類的特性會成為競争關鍵點。
Google發起的這兩個項目定義了一套雲原生時代标準的可信軟體供應連結口，這裡面其實也還包含了一個核心，就是Immutable，我們目前最常用的使用tag來引用鏡像的方式很難保證這點，是以很有可能需要使用digest方式來引用鏡像，這個對于整個鏡像的使用習慣會産生不小的影響。