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

[[342736]]

以某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 集群有兩個主體需要關注：

• 集群與組件
• 運行的服務或應用

保護 Kubernetes 集群組件與服務或應用：

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

(1) 管理 API 的訪問控制

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

(2) Kubelet 的訪問控制

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

(3) Runtime(運行時)工作負載或用戶功能的訪問控制

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

(4) 集群組件的安全漏洞防護

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

三、容器層

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

四、代碼層

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

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

參考資料：

• https://baike.baidu.com/item/%E7%BA%B5%E6%B7%B1%E9%98%B2%E5%BE%A1/8282191?fr=aladdin
• https://kubernetes.io/docs/concepts/security/overview/
• https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/