安全性是 Kubernetes 面臨的主要挑戰(zhàn)之一，因?yàn)樗呐渲脧?fù)雜性和漏洞較多。雖然Google Kubernetes Engine（GKE）這樣的托管容器服務(wù)提供了許多保護(hù)功能，但也不會(huì)免除所有相關(guān)責(zé)任。請(qǐng)繼續(xù)閱讀，詳細(xì)了解 GKE 安全性和保護(hù)集群的最佳實(shí)踐。

GKE 安全的基本概述

GKE 在許多層中保護(hù)您的工作負(fù)載，包括容器映像、運(yùn)行時(shí)、集群網(wǎng)絡(luò)以及對(duì)集群 API 服務(wù)器的訪問。

因此，Google 建議采用分層的方法來保護(hù)您的集群和工作負(fù)載。為組織啟用適當(dāng)級(jí)別的靈活性和安全性以部署和維護(hù)工作負(fù)載可能需要一定程度的權(quán)衡，因?yàn)槟承┰O(shè)置可能過于嚴(yán)格。

GKE 安全最關(guān)鍵的方面包括以下內(nèi)容：

身份驗(yàn)證和授權(quán);

控制平面安全性，包括組件和配置;

節(jié)點(diǎn)安全;

網(wǎng)絡(luò)安全。

這些元素也反映在CIS基準(zhǔn)中，這有助于圍繞Kubernetes的安全配置構(gòu)建工作。

為什么CIS基準(zhǔn)對(duì)GKE安全至關(guān)重要？

處理 K8s 安全配置并不像是在公園里散步。

紅帽 2022 年 Kubernetes 和容器安全現(xiàn)狀發(fā)現(xiàn)，幾乎四分之一的嚴(yán)重問題是可以修復(fù)的漏洞。近 70% 的事件是由于配置錯(cuò)誤而發(fā)生的。

自互聯(lián)網(wǎng)安全中心（CIS）發(fā)布以來，基準(zhǔn)已成為全球公認(rèn)的實(shí)施和管理網(wǎng)絡(luò)安全機(jī)制的最佳實(shí)踐。

CIS Kubernetes 基準(zhǔn)測(cè)試涉及支持強(qiáng)大安全態(tài)勢(shì)的 K8s 配置建議。它是為開源的 Kubernetes 發(fā)行版編寫的，并且基本普遍適用。

獨(dú)聯(lián)體GKE基準(zhǔn)測(cè)試實(shí)踐

使用像 GKE 這樣的托管服務(wù)，并非所有 CIS 基準(zhǔn)上的項(xiàng)目都在您的控制之下。

這就是為什么有些建議不能直接自行審核或修改的原因。這些涉及：

控制平面;

Kubernetes 發(fā)行版;

節(jié)點(diǎn)的操作系統(tǒng)。

但是，您仍然需要注意升級(jí)運(yùn)行工作負(fù)載的節(jié)點(diǎn)，當(dāng)然還有工作負(fù)載本身。需要審核和修正對(duì)這些組件的任何建議。

您可以手動(dòng)執(zhí)行此操作，也可以使用處理 CIS 基準(zhǔn)測(cè)試的工具。例如，使用 CAST AI 的容器安全模塊，您可以在連接集群后的幾分鐘內(nèi)大致了解基準(zhǔn)差異。

該平臺(tái)還會(huì)優(yōu)先處理它識(shí)別的問題，以便您知道哪些項(xiàng)目需要優(yōu)先修復(fù)。掃描集群時(shí)，您還可以根據(jù)行業(yè)最佳實(shí)踐進(jìn)行檢查，以便更好地評(píng)估整體安全狀況并計(jì)劃進(jìn)一步的 GKE 強(qiáng)化。

確保 GKE 安全的十大策略

1. 應(yīng)用最小特權(quán)原則

此基本安全原則是指僅授予用戶帳戶執(zhí)行預(yù)期功能所必需的權(quán)限。

它包含在 CIS GKE 基準(zhǔn) 6.2.1 中：不希望使用計(jì)算引擎默認(rèn)服務(wù)帳戶運(yùn)行 GKE 集群。

默認(rèn)情況下，您的節(jié)點(diǎn)可以訪問計(jì)算引擎服務(wù)帳戶。它的廣泛訪問權(quán)限使其對(duì)多個(gè)應(yīng)用程序有用，但它也具有比運(yùn)行 GKE 集群所需的更多權(quán)限。這就是為什么您必須創(chuàng)建和使用最低特權(quán)服務(wù)帳戶而不是默認(rèn)帳戶的原因。

2. 使用 RBAC 加強(qiáng)身份驗(yàn)證和授權(quán)

GKE 支持多個(gè)選項(xiàng)，用于通過基于角色的訪問控制 （RBAC） 管理對(duì)集群的訪問。

RBAC 支持在群集和命名空間級(jí)別更精細(xì)地訪問 Kubernetes 資源，但它也允許你創(chuàng)建詳細(xì)的權(quán)限策略。

CIS GKE 基準(zhǔn) 6.8.4 強(qiáng)調(diào)需要優(yōu)先使用 RBAC，而不是傳統(tǒng)的基于屬性的訪問控制 （ABAC）。

另一個(gè) CIS GKE 基準(zhǔn) （6.8.3） 建議使用組來管理用戶，因?yàn)樗?jiǎn)化了對(duì)身份和權(quán)限的控制。它還消除了在組中添加或刪除用戶時(shí)更新 RBAC 配置的需要。

3. 增強(qiáng)控制平面的安全性

在責(zé)任共擔(dān)模式下，Google 會(huì)為您管理 GKE 控制平面組件。但是，您仍負(fù)責(zé)保護(hù)節(jié)點(diǎn)、容器和 Pod。

默認(rèn)情況下，Kubernetes API 服務(wù)器使用公共 IP 地址?？梢允褂檬跈?quán)網(wǎng)絡(luò)和專用群集來保護(hù)它，這使您能夠分配專用 IP 地址。

您還可以通過執(zhí)行常規(guī)憑據(jù)輪換來增強(qiáng)控制平面的安全性。啟動(dòng)該過程時(shí)，TLS 證書和群集證書頒發(fā)機(jī)構(gòu)將自動(dòng)輪換。

4. 定期升級(jí)您的 GKE 基礎(chǔ)設(shè)施

Kubernetes 經(jīng)常發(fā)布新的安全功能和補(bǔ)丁，因此讓您的 K8s 保持最新狀態(tài)是改善安全狀況的最簡(jiǎn)單方法之一。

GKE 會(huì)自動(dòng)為您修補(bǔ)和升級(jí)控制平面。節(jié)點(diǎn)自動(dòng)升級(jí)也會(huì)自動(dòng)升級(jí)集群中的節(jié)點(diǎn)。CIS GKE 基準(zhǔn) 6.5.3 建議保持該設(shè)置。

如果出于任何原因，您需要禁用自動(dòng)升級(jí)，Google 建議每月執(zhí)行一次升級(jí)，并按照 GKE 安全公告了解關(guān)鍵補(bǔ)丁。

5. 保護(hù)節(jié)點(diǎn)元數(shù)據(jù)

CIS GKE 基準(zhǔn) 6.4.1 和 6.4.2 提到了影響節(jié)點(diǎn)安全性的兩個(gè)關(guān)鍵因素，這仍然是您的責(zé)任。

v0.1 和 v1beta1 計(jì)算引擎元數(shù)據(jù)服務(wù)器終結(jié)點(diǎn)在 2020 年被棄用并關(guān)閉，因?yàn)樗鼈儧]有強(qiáng)制實(shí)施元數(shù)據(jù)查詢標(biāo)頭。

一些針對(duì) Kubernetes 的攻擊依賴于訪問虛擬機(jī)的元數(shù)據(jù)服務(wù)器來提取憑據(jù)?？梢允褂霉ぷ髫?fù)載標(biāo)識(shí)或元數(shù)據(jù)隱藏來防止這些攻擊。

6. 禁用 Kubernetes 儀表板

幾年前，攻擊者獲得特斯拉云資源并使用它們來挖掘加密貨幣的消息使世界感到震驚。在這種情況下，攻擊媒介是一個(gè) Kubernetes 儀表板，它向公眾公開，沒有身份驗(yàn)證或提升的權(quán)限。

如果您想避免跟隨特斯拉的困境，建議遵守 CIS GKE 基準(zhǔn) 6.10.1。該標(biāo)準(zhǔn)清楚地概述了在 GKE 上運(yùn)行時(shí)應(yīng)禁用 Kubernetes Web UI。

默認(rèn)情況下，GKE 1.10 及更高版本禁用 K8s 儀表板。您還可以使用以下代碼：

gcloud container clusters update CLUSTER_NAME \

    --update-addons=KubernetesDashboard=DISABLED

7. 遵循 NSA-CISA 框架

CIS Kubernetes Benchmark 為構(gòu)建安全的運(yùn)營(yíng)環(huán)境提供了堅(jiān)實(shí)的基礎(chǔ)。但是，如果您想走得更遠(yuǎn)，請(qǐng)?jiān)诎踩绦蛑袨?NSA-CISA Kubernetes 強(qiáng)化指南騰出空間。

NSA-CISA 報(bào)告概述了 Kubernetes 生態(tài)系統(tǒng)中的漏洞，并推薦了配置集群安全性的最佳實(shí)踐。

它提供了有關(guān)漏洞掃描、識(shí)別錯(cuò)誤配置、日志審核和身份驗(yàn)證的建議，幫助您確保適當(dāng)解決常見的安全挑戰(zhàn)。

8. 提高您的網(wǎng)絡(luò)安全

在 GKE 中運(yùn)行的大多數(shù)工作負(fù)載都需要與集群內(nèi)外運(yùn)行的其他服務(wù)進(jìn)行通信。但是，您可以控制允許流經(jīng)集群的流量。

首先，您可以使用網(wǎng)絡(luò)策略來限制容器到容器的通信。默認(rèn)情況下，可以通過網(wǎng)絡(luò)訪問所有群集 Pod IP 地址。您可以通過定義流經(jīng) Pod 的流量并為與配置的標(biāo)簽不匹配的流量停止它來鎖定命名空間中的連接。

其次，您可以使用網(wǎng)絡(luò)負(fù)載均衡器來平衡 Kubernetes Pod。為此，您需要?jiǎng)?chuàng)建與容器標(biāo)簽匹配的負(fù)載均衡器服務(wù)。您將擁有一個(gè)面向外部的 IP 映射到 Kubernetes Pod 上的端口，并且您將能夠使用 kube-proxy 在節(jié)點(diǎn)級(jí)別過濾授權(quán)流量。

9. 保護(hù)容器對(duì)谷歌云資源的訪問

您的容器和容器可能需要訪問 Google Cloud 中的其他資源。有三種方法可以執(zhí)行此操作：使用工作負(fù)載標(biāo)識(shí)、節(jié)點(diǎn)服務(wù)帳戶和服務(wù)帳戶 JSON 密鑰。

訪問 Google Cloud 資源的最簡(jiǎn)單、最安全的選項(xiàng)是使用工作負(fù)載標(biāo)識(shí)。此方法允許您在 GKE 上運(yùn)行的 Pod 獲取對(duì) Google Cloud 服務(wù)帳戶的權(quán)限。

您應(yīng)該使用特定于應(yīng)用的 Google Cloud 服務(wù)帳號(hào)來提供憑據(jù)，以便應(yīng)用擁有在發(fā)生泄露時(shí)可以撤銷的最低必要權(quán)限。

10. 獲取 GKE 配置的密鑰管理器

獨(dú)聯(lián)體 GKE 基準(zhǔn) 6.3.1.建議使用云 KMS 中管理的密鑰加密 Kubernetes 密鑰。

Google Kubernetes Engine 為您提供了多種秘密管理選項(xiàng)。您可以在 GKE 中原生使用 Kubernetes 機(jī)密，但您也可以使用您管理的密鑰和應(yīng)用層機(jī)密加密在應(yīng)用程序?qū)颖Ｗo(hù)這些機(jī)密。

還有像Hashicorp Vault這樣的機(jī)密管理器，它們提供了一種一致的、生產(chǎn)就緒的方式來管理GKE中的機(jī)密。確保檢查您的選項(xiàng)并選擇最佳解決方案。

在幾分鐘內(nèi)評(píng)估 GKE 的安全性

Kubernetes 生態(tài)系統(tǒng)不斷增長(zhǎng)，但其安全配置挑戰(zhàn)也在不斷增長(zhǎng)。如果您想掌握 GKE 容器安全性，您需要能夠識(shí)別潛在威脅并有效地跟蹤它們。

借助 Kubernetes 安全報(bào)告，您可以根據(jù) CIS 基準(zhǔn)、NSA-CISA 框架和其他容器安全最佳實(shí)踐掃描 GKE 集群，以識(shí)別漏洞、發(fā)現(xiàn)錯(cuò)誤配置并確定其優(yōu)先級(jí)。只需幾分鐘即可全面了解集群的安全狀況。