雲端計算原生安全模型和實踐

導讀	在傳統的研發中，我們經常關注的「安全」包括程式碼安全、機器(執行環境)安全、網路運維安全，而隨著雲原生時代的到來，如果還按原有的幾個維度切分的話，顯然容易忽略很多雲原生環境引入的新挑戰，我們需要基於網路安全最佳實踐——縱深防禦原則，來逐步剖析「雲原生的安全」，並且對不同層次的防禦手段有所瞭解，從而建立自己的雲原生安全理念，真正搭建一個核心安全的雲原生系統。

注：“縱深防禦”，指在計算機系統中的多個層面使用多種網路安全技術，從而減少攻擊者利用關鍵業務資源或資訊洩露到系統外部的總體可能性。在訊息傳遞和協作環境中，縱深防禦體系可以確保惡意攻擊活動被阻止在基礎結構內的多個檢查點，降低了威脅進入內部網路的可能性。

以某IDaaS系統為例，我們把一個雲原生系統安全模型分為 4 個層面，由外至內分別是：雲/資料中心/網路層、叢集層、容器層、程式碼層，如下圖所示：

對於這裡安全模型的每一層，都是單向依賴於外層的。也就是說，外層的雲、叢集、容器安全如果做得好，程式碼層的安全就可以受益，而反過來，我們是無法透過提高程式碼層的安全性來彌補外層中存在的安全漏洞或問題。基於上述這一點原理，我們的縱深防禦策略是「自外而內」地進行“設防”。

這一層也可以稱之為基礎設施安全，不管從何角度，公有或私有云或企業資料中心以及對應的網路安全，是 K8s 叢集最根本的安全基礎，如果這一層存在安全漏洞或者過於脆弱，則整個系統都不能在此基礎上保證元件的安全。

我們除了需要防禦傳統的攻擊，如 ARP 偽裝、DDOS、網路層各類報文等攻擊，應該針對 Kubernetes 叢集採取以下保護措施：

• 不允許在 Internet 上公開對 Kubernetes 管理平臺(Control Plane)的所有訪問，同時僅開放部分可信 IP 可以訪問 Kubernetes 管理 API。
• 所有節點只暴露指定的埠，包括對管理平臺的內部埠和來自 NodePort 和 LoadBalancer 型別的 Kubernetes 服務的連線，並且不應該直接暴露到 Internet。
• 透過雲提供商或機房的網路層安全組(例如 AWS 的 Security Group)對管理平臺以及節點授予最小許可權控制：
• 對etcd(Kubernetes 的基礎儲存)的訪問進行嚴格控制(僅允許來自叢集管理平臺的訪問)，應強制所有連線都使用TLS，並確保所有資訊都是在持久化層被加密的(Encryption at rest)。

保護 Kubernetes 叢集有兩個主體需要關注：

1. 叢集與元件
2. 執行的服務或應用

保護 Kubernetes 叢集元件與服務或應用：

針對這兩個主體的保護，我們的保護可以分為 4 大塊：管理 API 的訪問控制、Kubelet 的訪問控制、Runtime(執行時)工作負載或使用者功能的訪問控制、叢集元件的安全漏洞防護，如下圖所示。

1. 管理 API 的訪問控制

• 強制 TLS 保護傳輸層
• 強制 API 認證
• 強制 API 授權機制(RBAC)

Kubelet 的訪問控制

• 生產環境啟用身份驗證
• 身份授權(RBAC)
• 強制 TLS 保護傳輸層

Runtime(執行時)工作負載或使用者功能的訪問控制

• 限制使用特權容器
• 合理限制資源負載
• 防止載入非必要核心模組
• 限制 Pod 越權訪問其他節點
• 基礎資料憑證的訪問控制

叢集元件的安全漏洞防護

• 禁止未授權訪問 etcd
• 啟用稽核日誌記錄
• 定期輪換基礎架構憑證
• 定期升級修復漏洞

到了這一層，由於跟 Kubernetes 特性不是強相關，我們能提供一些通用的安全措施和建議：

程式程式碼層是最容易受攻擊，但也是最可控的部分之一。雖然一般負責這塊安全的人員不一定是運維開發(DevOps)，可能是專門的安全工程師(Sec Eng)，但有一些基本共性理念和建議是可以互相借鑑的。

總體來說，雲原生時代的這四層架構：雲/資料中心/網路層、叢集層、容器層、程式碼層，與傳統架構比起來更加細化和更易受攻擊。自外而內地踐行每一層的安全最佳實踐，我們的縱深防禦才能算是成功的，每個在雲原生技術上想長期獲益的團隊需要對此有共識。

原文來自：  https://www.linuxprobe.com/cloud-security-model.html