雲原生時代下，容器安全的「四個挑戰」和「兩個關鍵」

做者 | 匡大虎 來源 | 阿里巴巴雲原生公衆號

雲原生進程中的容器安全挑戰

雲原生的火熱帶來了企業基礎設施和應用架構等技術層面的革新，在雲原生的大勢所趨下，愈來愈多的企業選擇擁抱雲原生，在 CNCF 2020 年度的調研報告中，已經有83% 的組織在生產環境中選擇 Kubernetes，容器已經成爲應用交付的標準，也是雲原生時代計算資源和配套設施的交付單元。顯然，容器已經成爲應用交付的標準，也是雲原生時代計算資源和配套設施的交付單元。

然而，因爲在隔離和安全性方面存在的自然缺陷，安全一直是企業進行容器改造化進程中關注的核心問題之一。來到雲原生時代，企業又將面臨哪些容器安全新挑戰？

• 缺乏體系化的容器安全能力建設：傳統的企業應用安全模型一般基於內部架構不一樣的信任域來劃分對應的安全邊界，在信任域內的東西向服務交互被認爲是安全的。而上雲後企業應用須要在 IDC 和雲上部署和交互，在物理安全邊界消失後，如何在零信任的網絡安全模型下構建企業級容器安全體系是雲服務商須要解決的重要問題。

• 更多的***面：基於容器技術的應用部署依賴 Linux 內核 namespaces 和 cgroups 等特性，從***者的角度出發，能夠利用內核系統漏洞，容器運行時組件和容器應用部署配置等多個維度發起針對性的逃逸和越權***。K8s、Docker、Istio 等開源社區近年來也相繼爆出很多的高危漏洞，這都給***者提供了可乘之機。

• 缺乏應用側全生命週期的安全防禦手段：容器技術在爲企業應用架構提供了彈性、敏捷和動態可擴展等特性的同時，也改變了應用的部署模式。首先應用自身的生命週期被大幅縮短，一個容器應用的生命週期一般是分鐘級；與此同時，隨着存儲網絡和異構資源利用率等基礎設施能力上的提高，容器應用的部署密度也愈來愈高，傳統的面向虛機維度的安全防禦策略和監控告警手段已經沒法適應容器技術的需求。

• 缺乏對雲上安全責任共擔模型的理解：企業應用上雲後的安全須要遵循責任共擔模型，在企業應用架構雲原生話的轉型過程當中，須要企業應用管理者和安全運維人員理解企業自身和雲服務商以前的責任邊界。這個過程當中也須要雲服務商面向企業應用側輸出更全面的容器安全最佳實踐並提高安全能力的易用性，下降使用門檻。

構建容器安全體系的基本原則

爲了應對上述企業應用在容器化進程中的安全挑戰，雲服務商和企業應用安全管理運維人員須要攜手共建容器應用安全體系：

圖 1 - ACK 容器服務安全責任共擔模型

1. 雲服務供給側

對於雲服務商，首先須要依託於雲平臺自身的安全能力，構建安全穩定的容器基礎設施平臺，而且面向容器應用從構建，部署到運行時刻的全生命週期構建對應的安全防禦手段。整個安全體系的構建須要遵循以下基本原則：

1）保證容器管控平臺基礎設施層的默認安全

容器平臺基礎設施層承載了企業應用的管控服務，是保障業務應用正常運行的關鍵，容器平臺的安全性是雲服務商應該格外關注的。

• 完備的平臺安全能力：首先雲服務商自身基礎設施的安全性是容器平臺是否安全的基礎，好比 VPC 的安全配置能力，SLB 的訪問控制，DDoS 能力和帳號系統對雲資源的訪問控制能力等都是平臺側面向企業應用須要提供的基礎安全能力。

• 版本更新和漏洞應急響應機制：虛機 OS 的版本更新和漏洞補丁的安裝能力也是保證基礎設施安全的基本防禦措施，除此以外如 K8s 等容器相關開源社區的風險漏洞，均可能成爲惡意***者首選的***路徑，須要廠商提供漏洞的分級響應機制並提供必要的版本升級能力。

• 平臺的安全合規性：這也是不少金融企業和政府部門應用上雲的硬性前提條件。雲服務商須要基於業界通用的安全合規標準，保證服務組件配置的默認安全性，同時面向平臺用戶和安全審計人員，提供完備的審計機制。

2）面向容器應用側提供縱深防護能力

雲服務商不只要在自身管控側創建完善的安全武裝，同時也須要面向業務應用負載，提供適合雲原生場景下容器應用的安全防禦手段，幫助終端用戶在應用生命週期各階段都能有對應的安全治理方案。因爲雲原生具備動態彈性的基礎設施，分佈式的應用架構和創新的應用交付運維方式等特色，這就要求雲服務商可以結合自身平臺的基礎安全能力，將雲原生能力特性賦能於傳統的安全模型中，構建面向雲原生的新安全體系架構。

2. 企業安全側

對於企業的安全管理和運維人員來講，首先須要理解雲上安全的責任共擔模型邊界，究竟企業自身須要承擔起哪些安全責任。雲原生微服務架構下企業應用在 IDC 和雲上進行部署和交互，傳統的網絡安全邊界已經不復存在，企業應用側的網絡安全架構須要遵循零信任安全模型，基於認證和受權重構訪問控制的信任基礎。對於企業安全管理人員來講能夠參考關注以下方向加固企業應用生命週期中的生產安全：

• 保證應用製品的供應鏈安全

雲原生的發展使得愈來愈多的大規模容器應用開始在企業生產環境上部署，也大大豐富了雲原生應用製品的多樣性，像容器鏡像和 helm charts 都是常見的製品格式。對於企業來講製品供應鏈環節的安全性是企業應用生產安全的源頭，一方面須要在應用構建階段保證製品的安全性；另外一方面須要在製品入庫，分發和部署時刻創建對應的訪問控制，安全掃描、審計和准入校驗機制，保證製品源頭的安全性。

• 權限配置和憑證下發遵循權限最小化原則

基於統一的身份標識體系進行認證受權是在零信任安全模型下構建訪問控制能力的基礎。對於企業安全管理人員來講，須要利用雲服務商提供的訪問控制能力，結合企業內部的權限帳號體系，嚴格遵循權限最小化原則配置對雲上資源和容器側應用資源的訪問控制策略；另外嚴格控制資源訪問憑證的下發，對於可能形成越權***行爲的已下發憑證要及時吊銷。另外要避免容器應用模板配置如特權容器這樣的過大權限，確保最小化***面。

• 關注應用數據和應用運行時刻安全

應用的成功部署上線並不意味着安全工做的結束。除了配置完備的資源請求審計外，安全管理運維人員還須要利用廠商提供的運行時刻監控告警和事件通知等機制，保持對容器應用運行時安全的關注，及時發現安全***事件和可能的安全隱患。對於企業應用自身依賴的敏感數據（好比數據庫密碼，應用證書私鑰等）須要根據應用數據的安防等級採用對應的密鑰加密機制，利用雲上的密鑰管理方案和落盤加密，機密計算等能力，保證數據在傳輸和落盤鏈路上的數據安全性。

• 及時修復安全漏洞和進行版本更新

不管是虛機系統，容器鏡像或是容器平臺自身的安全漏洞，都有可能被惡意***者利用成爲***應用內部的跳板，企業安全管理運維人員須要根據雲服務商推薦的指導方案進行安全漏洞的修復和版本更新（好比 K8s 集羣版本，應用鏡像版本等）。此外企業要負責內部員工的安全培訓工做，居安思危，提高安全防禦意識也是企業安全生產的基礎要務。

端到端的雲原生容器安全架構

阿里雲 ACK 容器服務面向廣大的企業級客戶，構建了完整的容器安全體系，提供了端到端的應用安全能力。在今年 Forrester IaaS 安全評測中，阿里雲容器安全能力與谷歌並列滿分，領先其餘廠商。下圖爲阿里雲容器服務的安全體系架構圖：

圖 2 - ACK 容器服務安全體系架構圖

首先整個容器安全體系依託於阿里雲強大的平臺安全能力，包括物理/硬件/虛擬化以及雲產品安全能力，構建了夯實的平臺安全底座。

在雲平臺安全層之上是容器基礎設施安全層，容器基礎設施承載了企業容器應用的管控能力，其默認安全性是應用可以穩定運行的重要基礎。首先面向集羣 host 節點 OS 鏡像自己阿里雲操做系統團隊作了不少安全加固相關工做，Alibaba Cloud Linux 2 (原 Aliyun Linux 2) 不只是阿里雲官方操做系統鏡像，也是 ACK 的首選默認系統鏡像。Alibaba Cloud Linux 2 在 2019 年 8 月 16 日正式經過了 CIS 組織的所有認證流程併發布對應的 CIS Aliyun Linux 2 Benchmark version 1.0.0。ACK 正在支持對基於 Alibaba Cloud Linux 操做系統的集羣進行 CIS 安全加固來知足簡單、快捷、穩定、安全的使用需求。除 CIS 合規外，2021 年 1 月，ACK 已經正式支持對基於 Alibaba Cloud Linux 操做系統的集羣進行等保加固。

在容器管控側，阿里雲容器服務基於 CIS Kubernetes 等業界安全標準基線對容器管控面組件配置進行默認的安全加固，同時遵循權限最小化原則收斂管控面系統組件和集羣節點的默認權限，最小化***面。三月，阿里雲容器服務提交的 CIS Kubernetes benchmark for ACK 正式經過 CIS 社區組織的認證審覈，成爲國內首家發佈 CIS Kubernetes 國際安全標準基線的雲服務商。

統一的身份標識體系和訪問控制策略模型是在零信任安全模型下構建安全架構的核心，ACK 管控側和阿里雲 RAM 帳號系統打通，提供了基於統一身份模型和集羣證書訪問憑證的自動化運維體系，同時面對用戶憑證泄露的風險，創新的提出了用戶憑證吊銷的方案，幫助企業安全管理人員及時吊銷可能泄露的集羣訪問憑證，避免越權訪問***事件。

針對密鑰管理、訪問控制、日誌審計這些企業應用交互訪問鏈路上關鍵的安全要素，ACK 容器服務也提供了對應的平臺側安全能力：

• 訪問控制：ACK 基於 K8s RBAC 策略模型提供集羣內應用資源的訪問控制能力，在保證非主帳號或集羣建立者默認無權限的安全前提下，集羣管理員能夠經過控制檯或 OpenAPI 的方式對指定的子帳號或 RAM 角色進行集羣和帳號維度的批量 RBAC 受權，ACK 面向企業常見受權場景，提供了四種預置的權限模板，進一步下降了用戶對 RBAC 及 K8s 資源模型的學習成本。對於應用容器中一般依賴的集羣訪問憑證 serviceaccount，ACK 集羣支持開啓針對 serviceaccount 的令牌卷投影特性，支持對 sa token 配置綁定 audience 身份，而且支持過時時間的設置，進一步提高了應用對管控面 apiserver 的訪問控制能力。

• 密鑰管理：針對企業客戶對數據安全自主性和合規性的要求，ACK Pro 集羣支持對 K8s Secret 的落盤加密能力，同時支持使用 BYOK 的雲盤加密能力，保證企業核心數據安心上雲；同時 ACK 集羣支持將用戶託管在阿里雲 KMS 憑據管家中的敏感信息實時同步到應用集羣中，用戶在 K8s 應用中直接掛載憑據同步的指定 secret 實例便可，進一步避免了對應用敏感信息的硬編碼問題。

• 日誌審計：ACK 除了支持 K8s 集羣 audit 審計，controlplane 管控面組件日誌等基本的管控面日誌採集外，還支持對 Ingress 流量的日誌審計和基於 NPD 插件的異常事件告警。以上日誌審計能力均對接了阿里雲 SLS 日誌服務，經過 SLS 服務提供的快速檢索、日誌分析和豐富的 dashboard 展現能力，大大下降了對容器應用開發運維和安全審計的難度。

 面向容器應用層在供應鏈和運行時刻的安全挑戰，阿里雲從容器應用的構建、部署到運行全生命週期，提供全方位覆蓋的安全能力：

圖 3 - ACK 容器服務應用全生命週期安全能力

• 應用構建階段

據 Prevasio 對於託管在 Docker Hub 上 400 萬個容器鏡像的調查統計，有 51% 的鏡像存在高危漏洞；另外有 6432 個鏡像被檢測出包含惡意***或挖礦程序，而光這 6432 個惡意鏡像就已經被累計下載了 3 億次。

如何應對這些潛伏於鏡像製品中的安全挑戰，一方面要求企業應用開發者在構建應用鏡像時使用可信的基礎鏡像，規範化鏡像構建流程, 保證鏡像最小化；另外一方面阿里雲 ACR 容器鏡像服務針對鏡像構建流程中的安全風險，提供了倉庫權限的訪問控制，操做審計和鏡像安全掃描等基礎能力。其中鏡像安全掃描是用戶可以主動發現安全漏洞的基礎手段，ACR 容器鏡像服務和阿里云云安全中心提供了不一樣版本的鏡像漏洞庫，在支持鏡像深度掃描的同時具有漏洞庫的實時更新能力，知足企業安全合規需求。在阿里雲容器鏡像服務企業版中還能夠經過建立和管理交付鏈實例，將安全掃描和分發流程自由組合並內置到自動化任務中而且自動攔截包含漏洞的鏡像，確保分發到倉庫中鏡像的安全性。

在鏡像構建環節，除了及時發現鏡像漏洞，如何在保證鏡像在分發和部署時刻不被惡意篡改也是重要的安全防禦手段，這就須要鏡像的完整性校驗。在阿里雲容器服務企業版實例中，企業安全管理人員能夠配置加簽規則用指定的 KMS 密鑰自動加簽推送到倉庫中的鏡像。

• 應用部署時刻

K8s 原生的 admission 准入機制爲應用部署時刻提供了自然的校驗機制。

濫用特權容器，敏感目錄掛載，以 root 用戶啓動容器，這些常見的應用模板配置都極可能成爲容器逃逸***的跳板。K8s 原生的 PSP 模型經過策略定義的方式約束應用容器運行時刻的安全行爲。ACK 容器服務提供面向集羣的策略管理功能，幫助企業安全運維人員根據不一樣的安全需求定製化 PSP 策略實例，同時綁定到指定的 ServiceAccount 上，對 PSP 特性的一鍵式開關也面向用戶屏蔽了其複雜的配置門檻。此外，ACK 容器服務還支持 gatekeeper 組件的安裝管理，用戶能夠基於 OPA 策略引擎更爲豐富的場景下定製安全策略。

針對應用鏡像在部署時刻的安全校驗需求，谷歌在 18 年率先提出了 Binary Authorization 的產品化解決方案。ACK 容器服務也在去年初正式落地了應用部署時刻的鏡像簽名和驗籤能力。經過安裝定製化的 kritis 組件，企業安全運維人員能夠經過定製化的驗籤策略保證應用部署鏡像的安全性，防止被篡改的惡意鏡像部署到企業生產環境中。

圖 4 -  一致性安全策略管理

• 應用運行時刻

企業應用的穩定運行離不開運行時刻的安全防禦手段。ACK 容器服務和雲安全中心團隊合做，面向容器內部***，容器逃逸，病毒和惡意程序，異常網絡鏈接等常見的運行時刻***行爲進行實時監控和告警，同時雲安全中心還提供了針對告警事件的溯源和***分析能力。與此同時，ACK 容器服務基於業界安全基線和最佳實踐，面向集羣內運行應用提供了一鍵化的免費安全巡檢能力，經過巡檢任務及時暴露運行中容器應用在健康檢查/資源限制/網絡安全參數/安全參數等配置上不符合基線要求的危險配置，並提示用戶修復建議，避免可能發生的***。

對於安全隔離程度要求較高的企業客戶能夠選擇使用安全沙箱容器集羣，安全沙箱容器基於輕量虛擬化技術實現，應用運行在獨立的內核中，具有更好的安全隔離能力，適用於不可信應用隔離、故障隔離、性能隔離、多用戶間負載隔離等多種場景。

對於金融支付，區塊鏈等對數據計算過程當中的徹底性，完整性和機密性有強安全訴求的場景，能夠選擇部署使用 ACK-TEE 機密計算託管集羣，其中機密計算基於 Intel SGX 技術，支持將重要的數據和代碼防止在一個特殊的可信執行加密環境（Trusted Execution Environment，TEE）中，而不會暴露給系統其餘部分。其餘應用、BIOS、OS、Kernel、管理員、運維人員、雲服務商、甚至除了 CPU 之外的其餘硬件均沒法訪問機密計算平臺數據，極大減小敏感數據的泄露風險。

圖 5 - 容器應用安全配置巡檢

圖 6 - 容器應用運行時刻安全監控

安全是企業上雲的首要關切

安全是企業上雲的首要關切。隨着雲原生對計算基礎設施和企業應用架構的重定義，容器做爲雲的新界面，也將緊跟雲原生的發展大潮，向更加安全、可信的方向發展。將來，阿里雲容器服務將始終以「讓企業放心上雲，安心用雲」爲目標，在容器安全領域保持世界級的競爭力，在不斷夯實自身基礎設施安全的基礎上，爲客戶的應用安全保駕護航。

參考資料

• 《RED KANGAROO》

• 《Binary Authorization》