強化叢集的安全防護

Kubernetes 的發展速度很快,因此經常有新的安全防護功能可供使用。本頁面引導您落實我們目前提供的指引,強化您的 Google Kubernetes Engine 叢集。如需安全防護主題的一般總覽,請閱讀安全總覽

停用 Kubernetes 網頁版 UI (資訊主頁)

在 GKE 上執行時,應該停用 Kubernetes 網頁版 UI (資訊主頁)。

高權限 Kubernetes 服務帳戶支援 Kubernetes 網頁版 UI (資訊主頁)。Cloud Console 提供許多相同的功能,因此您不需要這些權限。

停用 Kubernetes 網頁版 UI:

gcloud container clusters update [CLUSTER_NAME] \
    --update-addons=KubernetesDashboard=DISABLED

停用 ABAC

您應該停用屬性型存取權控管 (ABAC),改成在 GKE 中使用角色型存取權控管 (RBAC)。

在 Kubernetes 中,RBAC 用於將權限授予叢集層級和命名空間層級的資源。RBAC 可讓您使用含有一組權限的規則來定義角色。RBAC 具有重要的安全防護優勢,目前在 Kubernetes 中也很穩定,因此是時候停用 ABAC 了。

如果您仍然仰賴 ABAC,請先查閱使用 RBAC 的事前準備。如果您已從舊版升級叢集,且目前正在使用 ABAC,則應該更新存取權控管設定:

gcloud container clusters update [CLUSTER_NAME] \
    --no-enable-legacy-authorization

依照上述建議來建立新叢集:

gcloud container clusters create [CLUSTER_NAME] \
    --no-enable-legacy-authorization

使用網路政策來限制 Pod 之間的流量

依預設,同一叢集裡的所有 Pod 都能互相通訊。您應該根據工作負載,視情況控管 Pod 到 Pod 的通訊。

您可以使用 Kubernetes 的網路政策,讓攻擊者在叢集內的橫向移動變得困難許多。您也可以使用 Kubernetes Network Policy API,建立 Pod 層級防火牆規則。這類防火牆規則會決定同一叢集內的哪些 Pod 和服務可以互相存取。

如要在建立新叢集時啟用網路政策強制執行功能,請指定 --enable-network-policy 標記:

gcloud container clusters create [CLUSTER_NAME] \
    --zone=[COMPUTE_ZONE] \
    --enable-network-policy

啟用網路政策後,必須實際定義政策。由於這些政策供您的特定拓撲使用,因此我們不能提供具體建議。然而,Kubernetes 說明文件有極佳的逐步操作說明,可協助進行簡單的 nginx 部署。

如要進一步瞭解 GKE 中的網路政策,請參閱設定叢集網路政策

同時使用 NetworkPolicy 和 PodSecurityPolicy

如果您使用的是 NetworkPolicy,且您有須遵守 PodSecurityPolicy 的 pod,請建立一個有權限使用 PodSecurityPolicy 的 RBAC 角色或 ClusterRole。然後將角色或 ClusterRole 與 pod 的服務帳戶互相繫結。在這種情況下,授予權限給使用者帳戶的條件仍不足夠。詳情請參閱授權政策

為您的節點使用最低權限服務帳戶

每個 GKE 節點都分別有一個相關聯的身分與存取權管理 (IAM) 服務帳戶。依預設,節點會獲得 Compute Engine 預設服務帳戶,只要瀏覽到 Cloud Console 的身分與存取權管理區段就能找到此服務帳戶。依預設,這個帳戶有廣泛存取權,因此適用於各種應用程式,但具備的權限多過於 Kubernetes Engine 叢集執行時所需。您應該建立及使用權限最小的服務帳戶來執行 GKE 叢集,不要使用 Compute Engine 預設服務帳戶。

GKE 需要服務帳戶至少要擁有 monitoring.viewermonitoring.metricWriterlogging.logWriter 三種角色。進一步瞭解 Monitoring 角色Logging 角色

下列指令會建立 IAM 服務帳戶,且建立的服務帳戶會具備操作 GKE 時所需的最低權限:

gcloud iam service-accounts create [SA_NAME] \
    --display-name=[SA_NAME]

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/logging.logWriter

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role roles/monitoring.viewer

如果您使用的是 Google Container Registry 中的私人映像檔,還必須將存取權授予那些私人映像檔:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member "serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
  --role roles/storage.objectViewer

如果您希望其他使用者能夠使用此服務帳戶,來建立新叢集或節點集區,您必須在此服務帳戶上授予這些使用者服務帳戶使用者角色。

gcloud iam service-accounts add-iam-policy-binding \
  [SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com \
  --member=user:[USER] \
  --role=roles/iam.serviceAccountUser

如果叢集已經存在,則現在就可以使用這個新的服務帳戶來建立新的節點集區:

gcloud container node-pools create [NODE_POOL] \
  --service-account=[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
  --cluster=[CLUSTER_NAME]

如需 GKE 叢集存取其他的 Google Cloud 服務,則應該額外建立一個服務帳戶,將服務帳戶的私密金鑰儲存於 Kubernetes 密鑰,藉此將工作負載存取權授予該服務帳戶。詳情請參閱使用服務帳戶通過 Google Cloud Platform 驗證

縮減節點服務帳戶範圍

如果不想使用自訂服務帳戶,則另一個建議是縮減預設節點服務帳戶的權限。

依預設,節點服務帳戶有存取權範圍。存取權範圍是為執行個體指定權限的傳統方法。在我們推出 IAM 角色之前,只能透過存取權範圍這種機制將權限授予服務帳戶。

如果您尚未替節點建立個別的服務帳戶,則應該限制節點服務帳戶的範圍,藉此降低攻擊事件發生時權限提升的可能性。 如此一來,預設服務帳戶的權限就不會超過叢集執行時所需的權限。雖然預設範圍受到限制,但涵蓋的範圍可能超過叢集執行時所需的最小範圍。

在 GKE 中,節點的預設範圍是 devstorage.read_onlylogging.writemonitoringservice.management.readonlyservicecontroltrace.append。設定範圍時,前述項目會指定為 gke-default。如果您存取的是 Google Container Registry 中的私人映像檔,所需的最小範圍只有 logging.writemonitoringdevstorage.read_only

如要建立一個含有自訂範圍的叢集,請使用 --scopes 選項:

gcloud container clusters create [CLUSTER_NAME] \
    --scopes=[CUSTOM_SCOPES]

如果您不指定自訂服務帳戶的範圍,則會使用 gke-default。如果您指定自訂服務帳戶,則會使用 cloud-platformuserinfo.email

如果您的 gcloud 設定包括 container/new_scopes_behavior true,就表示已經為所有 Kubernetes 版本啟用這個行為。為您的環境設定預設:

gcloud config set container/new_scopes_behavior true

如要進一步瞭解所有範圍的權限,請參閱 Google 範圍

限制用戶端驗證方法

Kubernetes API 伺服器有好幾種驗證方法。在 GKE 中,支援的方法有 OpenID 連線憑證、x509 用戶端憑證、靜態密碼。GKE 會透過 gcloud 為您管理驗證作業:使用 OpenID 連線憑證方法、設定 Kubernetes、取得存取憑證並持續更新。

其他驗證方法,即 x509 憑證和靜態密碼,這兩種驗證方法的受攻擊面較大,叢集容易遭駭。如果您使用這兩種驗證方法,則您建立新叢集時,系統會為您產生憑證。除非應用程式使用的是這類驗證方法,否則應該一律予以停用。您應該使用 OpenID 驗證方法,停用叢集的用戶端憑證和靜態密碼這兩種驗證方法。

唯有具備 container.clusters.getCredentials 權限的使用者可以擷取用戶端憑證和靜態密碼。請注意,roles/container.adminroles/ownerroles/editor 這三種角色都具備該權限,因此請謹慎使用這類角色。進一步瞭解 GKE IAM 角色

停用用戶端憑證驗證

如果使用憑證驗證,用戶端會提出憑證,而 API 伺服器會以指定的憑證授權單位對該憑證進行驗證。在 GKE 中,用戶端憑證由叢集根憑證授權單位簽署。

使用 ABAC 時,用戶端憑證依預設可通過 API 伺服器的驗證。然而,啟用 RBAC 後,就必須將權限授予用戶端憑證。在啟用 RBAC 且停用 ABAC 的情況下,叢集還是具備這些憑證,只是這些憑證毫無用處罷了。

如要在不產生用戶端憑證的情況下建立叢集,請使用 --no-issue-client-certificate 標記:

gcloud container clusters create [CLUSTER_NAME] \
    --no-issue-client-certificate

目前沒有方法可從現有叢集移除用戶端憑證。

停用靜態密碼驗證

靜態密碼就是使用者名稱和密碼的組合,API 伺服器會對該組合進行驗證。在 GKE 中,系統會依預設為使用者名稱「admin」產生使用者名稱與密碼的組合。

如要在不產生靜態密碼的情況下建立叢集,請使用 --no-enable-basic-auth 選項:

gcloud container clusters create [CLUSTER_NAME] \
    --no-enable-basic-auth

更新現有叢集並移除靜態密碼:

gcloud container clusters update [CLUSTER_NAME] \
    --no-enable-basic-auth

保護節點中繼資料

有些對 Kubernetes 發動的實際攻擊事件,有賴於存取 VM 中繼資料伺服器來擷取節點的憑證。

為減輕這類攻擊事件,第一步就是如前文建議,使用權限最小的服務帳戶。下一步是防止工作負載冒用節點。您應該停用舊版中繼資料伺服器 API,改為使用中繼資料隱藏功能,這個動作有助於保護可能具有敏感內容的系統中繼資料,防止中繼資料受叢集中執行的工作負載影響。

詳情請參閱保護叢集中繼資料

自動升級節點

如要提高安全防護效能,最簡單的方法之一是讓 Kubernetes 保持在最新版本。Kubernetes 經常推出新的安全防護功能,並提供安全修補程式。

在 Google Kubernetes Engine 中,系統會為您修補及升級主要執行個體,但節點仍由您負責。您應該啟用節點自動升級,以便自動接收節點集區的升級和安全修補程式。

詳情請參閱自動升級節點

如果您不想啟用節點自動升級,請務必仔細查看 Kubernetes Engine 安全性公告,瞭解安全修補程式的相關資訊。

以 Pod 安全性政策限制 Pod 權限 (測試版)

依預設,Kubernetes 中的 Pod 能以超乎必要的功能運作。您應該將 Pod 的功能限制在工作負載需要的範圍內。

Kubernetes 提供的控制項可以將 Pod 限制為只以最低必要功能執行。Pod 安全性政策可讓您為 Pod 設定智慧預設功能,並強制執行您想在整個系列啟用的控制項。您定義的政策應該明確指出應用程式需求。restricted-psp.yaml 範例政策是很好的起點。

如要進一步瞭解 Pod 安全性政策,請參閱使用 PodSecurityPolicies

如果您在叢集中同時使用網路政策和 Pod 安全性政策,請參閱同時使用網路政策和 Pod 安全性政策

限制叢集探索 RBAC 權限

根據預設,Kubernetes 會使用一組探索 ClusterRoleBindings 權限來啟動叢集,這組權限可讓您廣泛存取叢集 API (包含 CustomResourceDefinitions 的 API) 的相關資訊。

使用者應瞭解,在 system:discoverysystem:basic-user ClusterRoleBindings 主題中包含的 system:authenticated 群組,可包含具備有效 Google 憑證 (例如 Gmail 使用者) 的任何人,且不代表與 GKE 上叢集安全性有關的有意義等級。

對於希望加強叢集探索 API 安全性的使用者,應考慮採取以下各項措施:

  • 設定授權網路來限制 IP 範圍設定的存取權
  • 設定私人叢集來限制對 VPC 的存取權
  • 彙整預設 system:discoverysystem:basic-user ClusterRoleBindings 的主題,例如,不允許存取 system:(un)authenticated 的 Kubernetes 預設值,而是考慮僅允許存取 system:serviceaccounts 群組以及其他已知的使用者和群組。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Kubernetes Engine 說明文件