作者
湯志敏 阿里云容器服務高級技術專家
汪圣平 阿里云云平臺安全高級安全專家
導讀：從 Docker image 到 Helm, 從企業內部部署到全球應用分發，作為開發者的我們如何來保障應用的交付安全，本文會從軟體供應鏈的攻擊場景開始，介紹云原生時代的應用交付標準演進和阿里云上的最佳實踐，
“沒有集裝箱，就不會有全球化”，在軟體行業里，Docker 和 Kubernetes 也扮演了類似的角色，加速了軟體行業的社會化分工和交付運維的效率，2013 年, Docker 公司提出了容器應用打包規范 Docker Image，幫助開發者將應用和依賴打包到一個可移植的鏡像里，2015 年，Google 將 Kubernetes 捐獻給 CNCF，進一步普及了大規模容器編排調度的標準，
Kubernetes 以一種宣告式的容器編排與管理體系，屏蔽了底層基礎架構的差異，讓軟體交付變得越來越標準化，隨著 K8s 為代表的云原生技術的大規模運用，越來越多的容器化應用被分發到 IDC、公共云、邊緣等全球各地，
在 2019 年，阿里云容器鏡像服務 ACR 的月鏡像下載量超過了 3 億次，同年 10 月，阿里云云市場的容器鏡像類目發布，越來越多的企業將其軟體以容器的方式進行上架和銷售，11 月，天貓 雙11 的所有核心系統 100% 上云，容器鏡像服務 ACR 除了支持 雙11 的內部鏡像托管以外，也將內部的能力在云上透出，支持更多的 雙11 生態公司，
接下來我們看下如何保證容器和 Kubernetes 下的軟體供應鏈安全，并先熟悉下軟體供應鏈的常見攻擊場景，
軟體供應鏈攻擊面和典型攻擊場景
軟體供應鏈通常包括三個階段：
- 軟體研發階段
- 軟體交付階段
- 軟體使用階段
在不同階段的攻擊面如下：
歷史上著名的 APPLE Xcode IDE 工具攻擊就是發生在軟體研發階段的攻擊，攻擊者通過向 Xcode 中注入惡意后門，在非官方網站提供下載，所有使用此 Xcode 的開發者編譯出來的 APP 將被感染后門，同樣著名的還有美國的棱鏡門事件，亦是在大量的軟體中植入后門程式，進行資料獲取等惡意操作，
Kubernetes 中的軟體供應鏈攻擊面也包括在以上范圍之中，以軟體使用階段為例，今年 RunC 漏洞 CVE-2019-5736，漏洞本身與 RunC 的運行設計原理相關，Container 之外的動態編譯 Runc 被觸發運行時會參考 Conainer 內部的動態庫，造成 RunC 自身被惡意注入從而運行惡意程式，攻擊者只需要在一個 Container 鏡像中放入惡意的動態庫和惡意程式，誘發受攻擊者惡意下載運行進行模糊攻擊，一旦受攻擊者的 Container 環境符合攻擊條件，既可完成攻擊，
同樣的攻擊面還存在于 Kubernetes 自身服務組件之中，前段時間爆出的 HTTP2 CVE-2019-9512、CVE-2019-9514 漏洞就是一個非常好的軟體研發階段脆弱性的例子，漏洞存在于 GO 語言的基礎 LIB 庫中，任何依賴 GO 版本（<1.2.9）所編譯的 KubernetesHTTP2 服務組件都受此漏洞影響，因此當時此漏洞影響了 K8s 全系列版本，攻擊者可以遠程 DOS Kubernetes API Server，同時在 Kubernetes 組件的整個交付程序中也存在著攻擊面，相關組件存在被惡意替換以及植入的可能性，
不同于傳統的軟體供應鏈，鏡像作為統一交付的標準如在容器場景下被大規模應用，因此關注鏡像的使用周期可以幫助攻擊者更好的設計攻擊路徑，
攻擊者可以在鏡像生命周期的任何一個階段對鏡像進行污染，包括對構建檔案的篡改、對構建平臺的后門植入、對傳輸程序中的劫持替換和修改、對鏡像倉庫的攻擊以替換鏡像檔案、對鏡像運行下載和升級的劫持攻擊等，
整個攻擊程序可以借助云化場景中相關的各種依賴，如 Kubernetes 組件漏洞、倉庫的漏洞，甚至基礎設施底層漏洞，對于防御者來說，對于鏡像的整個生命周期的安全保障，是容器場景中攻擊防范的重中之重，
云原生時代的應用交付標準演進（從 Image 到 Artifacts）
在云原生時代之前，應用交付的方式比較多樣化，比如腳本、RPM 等等，而在云原生時代，為了屏蔽異構環境的差異，提供統一的部署抽象，大家對應用交付標準的統一也迫切起來，
Helm
Helm 是 Kubernetes 的包管理工具，它提出了 Chart 這個概念，
- 一個 Chart 描述了一個部署應用的多個 Kubernetes 資源的 YAML 檔案，包括檔案、配置項、版本等資訊；
- 提供 Chart 級別的版本管理、升級和回滾能力，
CNAB
CNAB 是 Docker 和微軟在 2018 年底聯合推出平臺無關的 Cloud Native Application Bundle 規范，相比于 Helm，有額外幾個定義：
- 在 thick 模式時，CNAB 的 bundle 可以包含依賴的鏡像二進制，從而不需要額外去鏡像倉庫下載，作為一個整體打包；
- CNAB 定義了擴展的安全標準，定義了 bundle 的簽名（基于 TUF ）和來源證明（基于 In-Toto）描述；
- CNAB 的部署是平臺無關性，可以部署在 K8s 之上，也可以通過 terraform 等方式來部署，
CNAB 的這些特性，可以在可信軟體分發商與消費者之間進行跨平臺（包括云和本地 PC）的應用打包和分發，
OCI Artifacts
2019 年 9 月，開放容器標準組織（OCI）在 OCI 分發標準之上，為了支持更多的分發格式，推出了 OCI Artifacts 專案來定義云原生制品(Cloud Native Artifacts)的規范，我們可以通過擴展 media-type 來定義一種新的 Artifacts 規范，并通過標準的鏡像倉庫來統一管理，
Kubernetes 時代的安全軟體供應鏈
在之前章節也提到過，相對于傳統軟體的安全軟體供應鏈管理，容器和 Kubernetes 的引入使得：
- 發布和迭代更加頻繁，容器的易變性也使得安全風險稍縱即逝；
- 更多的不可控三方依賴，一旦一個底層基礎鏡像有了安全漏洞，會向病毒一樣傳遞到上層；
- 更大范圍的全球快速分發，在分發程序中的攻擊也會使得在末端執行的時造成大規模安全風險，
在傳統的軟體安全和安全準則之上，我們可以結合一些最佳實踐，沉淀一個新的端到端安全軟體供應鏈：
我們來看一些和安全軟體供應鏈相關的社區技術進展：
Grafeas
2017 年 10 月，Google 聯合 JFrog、IBM 等公司推出了 Grafeas，Grafeas（希臘語中的"scribe"）旨在定義統一的方式來審核和管理現代軟體供應鏈，提供云原生制品的元資料管理能力，可以使用 Grafeas API 來存盤，查詢和檢索有關各種軟體組件的綜合元資料，包括合規和風險狀態，
In-toto
In-toto 提供了一個框架或策略引擎來保護軟體供應鏈的完整性，
通過驗證鏈中的每個任務是否按計劃執行（僅由授權人員執行）以及產品在運輸程序中未被篡改來做到這一點，In-toto 要求專案所有者創建布局 (Layout)，布局列出了軟體供應鏈的步驟 (Step) 順序，以及授權執行這些步驟的作業人員，當作業人員執行跨步操作時，將收集有關所使用的命令和相關檔案的資訊，并將其存盤在鏈接 (Link) 元資料檔案中，通過在完整的供應鏈中定義每個 Step，并對 Step 進行驗證，可以充分完整的完整整個供應鏈的安全，
Kritis
為強化 Kubernetes 的安全性，Google 引入了二進制授權 (Binary Authorization)，確保使用者只能將受信任的作業負責部署到 Kubernetes 中，二進制授權可以基于 Kubernetes 的 Admission Controller 來插入部署準入檢測，讓只有授權后的鏡像在環境中運作，
下圖為一個策略示例：
同時對于在安全軟體供應鏈中占比很大的第三方軟體，需要有完善的基線機制和模糊安全測驗機制來保障分發程序中的安全風險，避免帶已知漏洞上線，阿里云正在與社區積極貢獻幫助演進一些開源的工具鏈，
關于基礎鏡像優化、安全掃描、數字簽名等領域也有非常多的工具和開源產品，在此不一一介紹，
云端的安全軟體供應鏈最佳安全實踐
在阿里云上，我們可以便捷地基于容器服務 ACK、容器鏡像服務 ACR、云安全中心打造一個完整的安全軟體供應鏈，
安全軟體供應鏈全鏈路以云原生應用托管為始，以云原生應用分發為終，全鏈路可觀測、可追蹤、可自主設定，可以幫助安全需求高、業務多地域大規模部署的企業級客戶，實作一次應用變更，全球化多場景自動交付，極大提升云原生應用交付的效率及安全性，
在云原生應用的安全托管階段，容器鏡像服務 ACR 支持容器鏡像、Helm Chart 等云原生資產的直接上傳托管；也支持從源代碼（Github、Bitbucket、阿里云 Code、GitLab 來源）智能構建成容器鏡像，在安全軟體供應用鏈中，支持自動靜態安全掃描并自定義配置安全阻斷策略，一旦識別到靜態應用中存在高危漏洞后，可自動阻斷后續部署鏈路，通知客戶失敗的事件及相關漏洞報告，客戶可基于漏洞報告中的修復建議，一鍵更新優化構建成新的鏡像版本，再次觸發自動安全掃描，
- 在云原生應用的分發階段，當安全漏洞掃描完成且應用無漏洞，應用將被自動同步分發至全球多地域，
由于使用了基于分層的調度、公網鏈路優化以及免公網入口開啟的優化，云原生應用的全球同步效率，相比本地下載后再上傳提升了 7 倍，云原生應用同步到全球多地域后，可以自動觸發多場景的應用重新部署，支持在 ACK、ASK、ACK@Edge 集群中應用自動更新，針對集群內大規模節點分發場景，可以實作基于鏡像快照的秒級分發，支持 3 秒 500 Pod 的鏡像獲取，實作業務在彈性場景下的極速更新，
- 在云原生應用運行階段，可實作基于云安全中心的應用運行時威脅檢測與阻斷，實時保障每個應用 Pod 的安全運行，
云安全中心基于云原生的部署能力，實作威脅的資料自動化采集、識別、分析、回應、處置和統一的安全管控，利用多日志關聯和背景關系分析方案，實時檢測命令執行、代碼執行、SQL 注入、資料泄露等風險，覆寫業務漏洞入侵場景，結合 K8s 日志和云平臺操作日志實時進行行為審計和風險識別，實作容器服務和編排平臺存在的容器逃逸、AK 泄露、未授權訪問風險，
總結
隨著云原生的不斷發展，云原生應用也會在安全、交付、全球分發等領域持續演進，我們可以預見一個新的時代：越來越多的大型軟體以積木的方式由全球開發者獨立開發而最終合并組裝，
本書亮點
- 雙11 超大規模 K8s 集群實踐中，遇到的問題及解決方法詳述
- 云原生化最佳組合：Kubernetes+容器+神龍，實作核心系統 100% 上云的技術細節
- 雙 11 Service Mesh 超大規模落地解決方案
“阿里巴巴云原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/47565.html
標籤：其他