作者
湯志敏  阿里雲容器服務高階技術專家
汪聖平  阿里云云平臺安全高階安全專家

> **導讀**：從 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 下的軟體供應鏈安全，並先熟悉下軟體供應鏈的常見攻擊場景。

# 軟體供應鏈攻擊面和典型攻擊場景

軟體供應鏈通常包括三個階段：

- 軟體研發階段
- 軟體交付階段
- 軟體使用階段

在不同階段的攻擊面如下：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/2f453d1c4c4045a0a1b085e989f845cb.png)

歷史上著名的 APPLE Xcode IDE 工具攻擊就是發生在軟體研發階段的攻擊，攻擊者透過向 Xcode 中注入惡意後門，在非官方網站提供下載，所有使用此 Xcode 的開發者編譯出來的 APP 將被感染後門。同樣著名的還有美國的斯諾登事件，亦是在大量的軟體中植入後門程式，進行資料獲取等惡意操作。

Kubernetes 中的軟體供應鏈攻擊面也包括在以上範圍之中，以軟體使用階段為例，今年 RunC 漏洞 CVE-2019-5736，漏洞本身與 RunC 的執行設計原理相關，Container 之外的動態編譯 Runc 被觸發執行時會引用 Conainer 內部的動態庫，造成 RunC 自身被惡意注入從而執行惡意程式，攻擊者只需要在一個 Container 映象中放入惡意的動態庫和惡意程式，誘發受攻擊者惡意下載執行進行模糊攻擊，一旦受攻擊者的 Container 環境符合攻擊條件，既可完成攻擊。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/237c810c22d7451499d787bcb6070918.png)

同樣的攻擊面還存在於 Kubernetes 自身服務元件之中，前段時間爆出的 HTTP2 CVE-2019-9512、CVE-2019-9514 漏洞就是一個非常好的軟體研發階段脆弱性的例子，漏洞存在於 GO 語言的基礎 LIB 庫中，任何依賴 GO 版本（<1.2.9）所編譯的 KubernetesHTTP2 服務元件都受此漏洞影響，因此當時此漏洞影響了 K8s 全系列版本，攻擊者可以遠端 DOS Kubernetes API Server。同時在 Kubernetes 元件的整個交付過程中也存在著攻擊面，相關元件存在被惡意替換以及植入的可能性。

不同於傳統的軟體供應鏈，映象作為統一交付的標準如在容器場景下被大規模應用，因此關注映象的使用週期可以幫助攻擊者更好的設計攻擊路徑。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/4d7d94bd88ed42c0a6789cd280de2ef5.png)

攻擊者可以在映象生命週期的任何一個階段對映象進行汙染，包括對構建檔案的篡改、對構建平臺的後門植入、對傳輸過程中的劫持替換和修改、對映象倉庫的攻擊以替換映象檔案、對映象執行下載和升級的劫持攻擊等。

整個攻擊過程可以藉助雲化場景中相關的各種依賴，如 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）的應用打包和分發。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/a3efd056559c401a9656d6972efd1f24.png)

## OCI Artifacts
2019 年 9 月，開放容器標準組織（OCI）在 OCI 分發標準之上，為了支援更多的分發格式，推出了 OCI Artifacts 專案來定義**雲原生製品(Cloud Native Artifacts)**的規範。我們可以透過擴充套件 media-type 來定義一種新的 Artifacts 規範，並透過標準的映象倉庫來統一管理。

# Kubernetes 時代的安全軟體供應鏈
在之前章節也提到過，相對於傳統軟體的安全軟體供應鏈管理，容器和 Kubernetes 的引入使得：

- 釋出和迭代更加頻繁，容器的易變性也使得安全風險稍縱即逝；
- 更多的不可控三方依賴，一旦一個底層基礎映象有了安全漏洞，會向病毒一樣傳遞到上層；
- 更大範圍的全球快速分發，在分發過程中的攻擊也會使得在末端執行的時造成大規模安全風險。

在傳統的軟體安全和安全準則之上，我們可以結合一些最佳實踐，沉澱一個新的端到端安全軟體供應鏈：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/81f0ffc9981641c6acfd3e6812757f42.png)

我們來看一些和安全軟體供應鏈相關的社群技術進展：

## Grafeas
2017 年 10 月，Google 聯合 JFrog、IBM 等公司推出了 Grafeas。Grafeas（希臘語中的"scribe"）旨在定義統一的方式來稽核和管理現代軟體供應鏈，提供**雲原生製品的後設資料管理能力**。可以使用 Grafeas API 來儲存，查詢和檢索有關各種軟體元件的綜合後設資料，包括合規和風險狀態。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/3cd134b3af5f428cb1275aa1ef6a9b09.png)

## In-toto
In-toto 提供了一個**框架或策略引擎來保護軟體供應鏈的完整性**。

透過驗證鏈中的每個任務是否按計劃執行（僅由授權人員執行）以及產品在運輸過程中未被篡改來做到這一點。In-toto 要求專案所有者建立佈局 (Layout)。佈局列出了軟體供應鏈的步驟 (Step) 順序，以及授權執行這些步驟的工作人員。當工作人員執行跨步操作時，將收集有關所使用的命令和相關檔案的資訊，並將其儲存在連結 (Link) 後設資料檔案中。透過在完整的供應鏈中定義每個 Step，並對 Step 進行驗證，可以充分完整的完整整個供應鏈的安全。

## Kritis
為強化 Kubernetes 的安全性，Google 引入了二進位制授權 (Binary Authorization)，確保使用者只能將受信任的工作負責部署到 Kubernetes 中。二進位制授權可以基於 Kubernetes 的 Admission Controller 來插入部署准入檢測，讓只有授權後的映象在環境中運作。

下圖為一個策略示例：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/23d4cac5cd9946628ab98532221adcd0.png)

同時對於在安全軟體供應鏈中佔比很大的第三方軟體，需要有完善的基線機制和模糊安全測試機制來保障分發過程中的安全風險，避免帶已知漏洞上線，阿里雲正在與社群積極貢獻幫助演進一些開源的工具鏈。

關於基礎映象最佳化、安全掃描、數字簽名等領域也有非常多的工具和開源產品，在此不一一介紹。

# 雲端的安全軟體供應鏈最佳安全實踐
在阿里雲上，我們可以便捷地基於容器服務 ACK、容器映象服務 ACR、雲安全中心打造一個完整的安全軟體供應鏈。

安全軟體供應鏈全鏈路以雲原生應用託管為始，以雲原生應用分發為終，全鏈路可觀測、可追蹤、可自主設定。可以幫助安全需求高、業務多地域大規模部署的企業級客戶，實現一次應用變更，全球化多場景自動交付，極大提升雲原生應用交付的效率及安全性。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/006886cffe29479e882b83bb942c0791.png)

在雲原生應用的安全託管階段，容器映象服務 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 超大規模落地解決方案

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247488061&idx=1&sn=cf45017a7e561a30bd42b829cc0981ea&chksm=fae519f2cd9290e4d3550d856e4d6adeb35d287acc821d812342077478989d731c59e91c4701&token=338472548&lang=zh_CN#rd)微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”

Kubernetes 時代的安全軟體供應鏈

相關文章