容器計算服務 ACS(Container Compute Service)集群托管架構遵循責任共擔原則,其中ACS負責管理Kubernetes集群控制組件和相關阿里云基礎設施的安全性。本文介紹容器計算服務ACS的安全責任共擔模型。
術語約定
文檔內容將會不可避免地反復用到相同的名稱、代碼等,為了使文檔內容簡短、精要,所以在此對一些常用術語進行約定:
平臺:即容器計算服務ACS。
客戶:使用ACS的阿里云客戶。
安全責任劃分原則
ACS作為典型的Serverless形式的平臺,具備了資源全托管特性,需要明確阿里云和客戶之間的安全責任邊界,各自守好戰場,一般安全責任劃分的原則如下:
1. 阿里云的安全責任
阿里云的責任是維護Serverless平臺的安全性和可靠性,確保平臺的基礎設施安全、提供安全的數據存儲和處理服務以及保護客戶數據的機密性等。阿里云需要確保其基礎架構、管理、安全實踐的合規性,以保護客戶的應用程序不受攻擊,同時保護客戶數據的隱私性和完整性。
2. 客戶的安全責任
客戶負責確保其Serverless應用的安全性,涵蓋應用程序本身的數據安全性和訪問控制、代碼編寫和審計,以及有效的認證和授權措施等,并且只允許授權的個人或者團隊進行訪問,主要的原則有:
自身引入的安全風險需要負責:部署具有安全隱患的Pod或者授權面過大,影響了業務,需要客戶自行負責。
主動申請開放容器特權需要負責:平臺默認禁止開放對于容器穩定性和安全有較大影響的特性(例如Privileged和Capabilities等),但是客戶可以通過主動申請流程進行開放,因此如果由于過大的特權導致穩定性和安全問題,例如橫向攻擊集群內其他Pod,需要客戶自行負責。
3. 共管資源的安全責任
由于平臺某些資源無法做到單方面管理及使用,例如客戶的Pod安全組,理想的狀態由阿里云進行全托管。然而有一些客觀需求,客戶想要參與管理或希望該資源更受控,就需要更明晰的原則界定:
誰引入風險誰兜底原則:例如客戶創建有安全隱患的Pod或使用被投毒的鏡像等,引發故障需要客戶自行負責;阿里云保證,ACS范圍內的管控Pod,不會有安全隱患,不會影響客戶業務。
各方保證最小權限原則:如果客戶側開放公網范圍過大,那么從這個方向進來的攻擊行為及后果,需要客戶自行承擔;阿里云保證,ACS范圍內的Pod安全組,不會擴大訪問范圍,客戶的應用運行不會逃逸出容器。
安全是一個全面的體系,要求阿里云和客戶之間的安全責任層次分明,同時保持密切協作。阿里云承擔基礎設施安全與合規保障的責任,客戶則需要確保其應用和數據安全。對于責任交叉的灰色區域,阿里云將采取主動策略,確保風險無死角,致力于為客戶提供額外安全的Serverless服務支持。
理解責任共擔模型
在設計和部署企業應用系統前,您需要明確企業與阿里云各自的安全責任界限。選擇阿里云ACS集群,除了管理基礎設施,阿里云還會確保Pod的運行環境及相關運行時組件的安全。下圖展示了在Serverless架構中使用ACS集群時,阿里云和客戶之間安全責任的具體劃分。
1. 阿里云負責
在管控面側,阿里云會基于K8s安全基線等業界通用的安全標準,對ACS集群管控面組件進行安全加固,同時面向企業云原生應用生命周期中安全防護的典型場景,提供必要的安全體系概述。在此基礎上,阿里云主要負責以下內容:
安全類型 | 詳細內容 |
基礎設施的安全性 |
|
彈性計算資源池的安全性 |
|
集群管控及托管組件的安全性 | 集群鑒權及證書管理、集群內Secret憑據管理、對外暴露端口、VPC隔離及安全組配置的合理性等。 |
非托管組件和應用市場Chart的安全性 | 提供標準核心配置,保障基本安全問題。 |
2. 客戶負責
在數據面側,客戶的安全運維人員需要負責部署在云上的業務應用安全防護以及云上資源的安全配置和更新。在此基礎上,客戶主要負責以下內容:
安全類型 | 詳細內容 |
應用的安全性 |
|
運維的安全性 | 業務云網絡配置、業務云存儲配置、業務可觀性配置。 |
業務組件的安全性 | 對于Operator、Webhook等的業務邏輯需要嚴格限制,以防止影響其他應用的安全。 |
非托管組件和應用市場Chart的安全性 |
|