K8S Summit 2022心得分享
今年的Ithome 主辦的Kubernetes Summit 跟往年不一樣，是一天變兩天嗎？是有超實穿的Hoodie了嗎？還是參加的團隊變多了嗎？誒 都不算是。我個人覺得最大的不同，是多了三個強者我朋友，跟我一起參加了這場每年的K8S盛會～ 在眾多很棒的稿件下，我們有幸報上了一個工作坊跟一個BreakOut Session，才有了這次跟大家的分享。
在Google這個K8S的發源地，內部對於K8S的討論跟創新，從未間斷過，也吸引了非常多對容器有熱情的人們，這次我們推出的Workshop，由Owen（歐文垃圾話）領軍，加上兩位K8S大拿Perl and Danny 當助教，帶給與會的嘉賓體驗純手作的Serverless 上線工作坊。
Serverless on Kubernetes — Knative
這個工作坊的內容，絕對可以讓大家感受到手作的溫度。連整個Lab內容都是由Owen為了符合90分鐘Workshop而專程打造的一個Tutorial，10/19號當天早上開放報名，10分鐘30人就額滿了，最後超收到34名學員，客戶的評價，在這兩天所有的Workshop中，我們的Workshop拿到了知識性的冠軍：
這個Workshop分為五個部分：
- 在K8S裏快速安裝Knative Serving & Eventing
- 通過Prometheus做Knative平台的Day 2的監控
- 部署一支服務，通過Knative Serving進行NoOps的自動擴容，並使用Knative通過藍綠部署機制，進行不同比重的更版作業。
- 設定Knative Eventing，用以接受Cloud Storage檔案上傳事件的Cloud Event。
- 以該Event驅動Cloud Run的服務，將上傳的影像進行縮圖作業。
Owen也將詳細的內容，整理在他的Blog上，也一併附上他的GitLab專案。歡迎大家也一起入Knative的坑～
這次的Lab，我們只花了10分鐘就可以上線，感謝Google的Qwiklabs。想到之前需要Reserve Lab 資源，還需要國外團隊一起進來協助安裝Lab，同樣是客製化Lab，準備時間大幅縮短由1天，縮短為10分鐘，而且只要一個人就可以完成。
Peek into Kubernetes Security（軟體開發供應鏈資安搶先看）
這個分享的緣起，是這半年來，看到Cloud Native 社群對白宮EO14028 命令的具體施行回應的一個實作整理。
EO14028，是2021年拜登政府所發布的一個行政命令，也是近年來第一個針對軟體開發鏈攻擊的一個政府級別的宣示，廣泛獲得社群的支持。NIST在2022/02推出了SSDF 1.1版，IETF也在2022/10月推出SCITT第二版草案，其中NIST SSDF 1.1 也在10/20號，IThome也發了一篇專文，引起了廣泛的討論。
相較於SSDF 以四大構面 (Prepare for Organization(PO), Protect the Software(PS), Produce Well-Secured Software(PW),和 Respond to Vulnerability(RV))，與20項實踐原則的大框架，這次筆者選擇介紹的是一個相較於SSDF ，比較可以具體實行的SLSA規範。
這個規範是由The Linux Foundation + CNCF + Google+Intel等社群/企業一起推動，相較於SSDF是以20項實踐原則，回應白宮EO 14028，SLSA是以近年來所發生的幾個軟體供應鏈資安事件，也提供必要的20項作為(Requirements)，
並將實行進程切分成Level 1~4，提供企業一個循序漸進的導入流程，可以視為是對於SSDF的四大構面的PO, PS, PW與RV的部分具體實現，有興趣的讀者可以看一下Linux Foundation的影片，了解SLSA跟SSDF的差異
這次的分享，除了SLSA的規範外，另外還延伸了執行面的部分，結合K8S平台上特有的Admission Webhook，通過以Policy檢查 的方式，拒絕沒有SLSA compliance的鏡像檔，在該叢集部署。SLSA + Admission Webhook 整合的Framework，也是Google內部開發的標準架構，內部稱為BAB (Binary Authorization for Borg)，目前大家耳熟能詳的Google Search, Youtube, GCP 各類Service都遵循這個架構進行開發、Review與部署工作。
為了幫助大家的了解，這次的展示部分，分為三個部分：
分段開發流程與手動驗證:
通過In-toto-attestation Demo Github專案，幫助大家了解，開發供應鏈，如果每個步驟都是人工實行，在Task 傳遞的過程中，該如何以Hash Code與執行者的公私鑰，來確認每個步驟的完整性（Integrity）。
通過自動化工具簽章驗證：
第二個展示是通過 Sigstore CoSign + ClusterImagePolicy對鏡像進行簽章與部署驗證，通過自動化的CI/CD流程，我們可以避免當流程因分段時，所需要額外的檢查。 在展示中，我分享了兩套不同的工具，(1) SigStore Cosign + ClusterImagePolicy 配合Github Action，
以及 (2) Binary Authorization + CloudBuild。Github Action與CloudBuild這兩套CI/CD工具，都符合了SLSA Level 3所規範的Ephemeral 的特性，
流程中搭配的檢查
最後我們以一個完整流程，作為開發測試供應鏈的建議架構，作爲企業實際在制定內部流程用以回覆SSDF時的一個參考，相關的工具有提供於連結中。包含了:
開發者的Inner Loop:
- 使用一個安全的開發機器，分離資料，與使用工具+OS。讓開發機不會有潛伏的病毒威脅。
- 以Shift Left的原則，在IDE上通過MarketPlace安裝IDE插件。主要將源碼掃描(SAST), 源碼分析(SCA), 開源授權馬檢查 (OSS License Validator), Key/Secret檢查等，在開發時期就引入，甚至加上pre-commit hook，讓key/secret等無法被commit到Source Repo中。
Ephemeral的CI Flow:
- 通過Ephemeral的Build Runner/Agent進行SAST, SCA, OSS, Key/Secret,檢查。
- 鏡像製作完成後，除應先進行CVE檢查與鏡像的Unittest後，經過簽章機制後再推入Docker Registry。
Hardened Kubernetes Cluster:
在預定部署的Hardened K8S叢集內(至少通過CIS Benchmark Level1)，加上對應的部署限制策略 (e.g. Binary Authorization or ClusterImagePolicy)，防範未取得SLSA 對應Level的鏡像檔被部署在叢集內。
延伸閱讀
在軟體取得管道眾多的狀況下，SLSA社群也建議企業三種信任模型：
- Trust in Attestations: 企業相信開發者的CI流程與工具，是符合SLSA Level規範的 ，該認證由CI工具(e.g. Github Action or CloudBuild) 的私鑰簽署，供企業驗證其合規/完整性。(5
- Delegated Trust: 該軟體套件，有得到其他關係企業或是資安機構(e.g. OpenSSF)的SLSA Level確認。該企業應可在下載的發佈套件中，通過該資安機構所發佈的公鑰，驗證其合規/完整性。
- Delegate Trust to Package Distributor: 企業通過信任某個Package Distributor (e.g. APT or Pypl等），由Package Distributor來驗證其發布的軟體套件，均符合Package Distributor 所要求的SLSA合規。
這次的分享所使用投影片與Github專案提供在此，其中Github裡面有對應的Github Action yml與使用的CloudBuild.yaml供大家參考，最後也非常感謝大家的支持，第一次在K8S Summit有機會拿到人氣王Session。
最後廣告一下，Google NEXT Recap台灣場（中文）會在11/16舉辦唷～ 報名連結在這。其中下午1:30PM 由Owen Wu帶來的『如何確保軟體供應鏈的安全性：從相依性至部署』，是我這篇Blog在GCP上的實作與延伸喔～ 歡迎大家踴躍參加。
