作者
湯志敏 阿里雲容器服務高級技術專家
汪聖平 阿里雲雲平台安全高級安全專家
導讀：從 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”