Kubernetes 時代的安全軟件供應鏈

點擊下載《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》

本文節選自《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點擊上方圖片便可下載！

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

導讀：從 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-95十二、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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」