CIS 基準

本頁面說明 Google Kubernetes Engine (GKE) 採用的方法，以提升 Kubernetes 和 GKE 對於 Center for Internet Security (CIS) 基準的遵循程度。這個頁面包含下列資訊：

  • 我們如何設定代管 GKE 控制層，以符合 CIS Kubernetes 基準
  • 如何設定 GKE 節點和工作負載，以符合 CIS Google Kubernetes Engine (GKE) 基準

關於 CIS 基準

CIS 發布下列基準，其中包含 Kubernetes 的安全設定指南：

  • CIS Kubernetes 基準：適用於開放原始碼 Kubernetes 專案。旨在為各種自管和代管 Kubernetes 實作提供指引。
  • CIS GKE 基準：為您在 GKE 叢集中可控制的元件建立安全設定的指南。包括 Google Cloud上 GKE 專屬的建議。

建議您優先採用 CIS GKE Benchmark，因為這是 GKE on Google Cloud專用的基準。CIS Kubernetes 基準包含許多控制項建議，但您無法在 GKE 中查看或修改這些控制項。我們的叢集安全防護方法包含的緩解措施，超出開放原始碼 Kubernetes 基準的範圍，因此可能與這些建議發生衝突。

適用於 GKE 的其他基準

除了 CIS GKE 基準和 CIS Kubernetes 基準外，下列基準也適用於 GKE 提供的作業系統。即使特定 OS 基準未明確提及 Kubernetes 用途，您仍應參考該基準，取得額外的安全性指引。

預設容器執行階段 containerd 沒有基準。

共同責任模式

根據 GKE 共同責任模式，我們會為您管理下列元件：

  • 控制層，包括控制層 VM、API 伺服器，以及叢集狀態資料庫 (以 etcd 或 Spanner 為基礎)、kube-controller-manager 和 kube-scheduler 等元件。
  • 節點作業系統。

這些元件位於 GKE 擁有的專案中，因此您無法修改或評估任何這些元件是否符合對應的 CIS 基準控制項。不過，您可以評估並修正適用於工作站節點和工作負載的任何 CIS 基準控制項。根據 GKE 共同責任模式，這些元件由您負責。

我們如何根據 CIS 基準保護 GKE

GKE 是開放原始碼 Kubernetes 的代管實作。我們會全面管理控制層，並負責保護控制層元件的設定。下表說明我們可能做出的決定，這些決定可能會影響 CIS 基準的評分：

GKE 安全策略
驗證
  • 部分 GKE 監控元件會使用匿名驗證來取得指標。
  • 部分控制層元件會使用靜態權杖啟動，然後用來向 API 伺服器驗證。每次啟動或重新啟動 VM 時，系統都會產生這些權杖。
許可控制器

GKE 會停用下列許可控制器：

  • EventRateLimit：這是 Kubernetes 的 Alpha 版功能
  • AlwaysPullImages：這個控制器可為非合作式多租戶叢集中的私人登錄檔映像檔提供部分保護，但代價是映像檔登錄檔會成為在叢集中建立新 Pod 的單一故障點。
  • SecurityContextDeny：建議使用 Pod 安全性許可控制器，所有 GKE 版本都提供這項功能。如果您使用 GKE Enterprise，也可以透過 Policy Controller 啟用 Pod 安全性標準的強制執行功能。
  • ImagePolicyWebhook：GKE 預設會停用 ImagePolicyWebhook，因為 GKE 有自己的映像檔管理和安全機制。這可讓 GKE 對環境維持更嚴格的控管，並確保安全措施能持續套用。不過，您可以使用二進位授權或 Policy Controller 管理政策。
稽核記錄 GKE 會使用 GKE 稽核政策擷取稽核記錄。因此，我們不需要設定任何 Kubernetes API 伺服器稽核記錄標記。
偵錯 GKE 會使用剖析功能進行偵錯。
加密
etcd

在開放原始碼的 Kubernetes 中，叢集狀態資料庫會使用 etcd。在 GKE 中，儲存叢集狀態的後端資料庫是下列其中一種技術：

  • etcd：叢集會在控制層上執行 etcd 執行個體。
  • Spanner：GKE 會將叢集狀態儲存在以 Spanner 為基礎的資料庫中，與控制層 VM 分開。

所有 GKE 叢集都會在控制層 VM 中提供 etcd API。所有與 Kubernetes API 的用戶端互動，都與開放原始碼 Kubernetes 相同。視叢集中 etcd API 的後端資料庫技術而定，您可能會發現開放原始碼 CIS Kubernetes 基準中，任何與 etcd 相關的評分都有差異。
kubelet
  • GKE 會啟用未經驗證的 kubelet 唯讀通訊埠。如要停用通訊埠，請設定 --no-autoprovisioning-enable-insecure-kubelet-readonly-port。我們會在日後的新版本中預設停用唯讀通訊埠，但會先給您一段時間進行遷移。
  • GKE Standard 模式可讓工作負載視需要修改核心預設值。
  • GKE 會限制 kubelet 中的 Kubernetes 事件數量，以降低阻斷服務攻擊的風險。
  • GKE 會使用 mTLS 保護 kubelet 和 API 伺服器之間的流量。
  • GKE 預設會輪替伺服器憑證，並在啟用受防護的 GKE 節點時輪替用戶端憑證。
  • GKE 使用 golang 預設允許的密碼組合，這也是 Kubernetes 的預設值。

根據 CIS 基準評估 GKE

您可以透過下列任一方法，自動評估叢集是否符合基準：

  • CIS GKE 基準：

    • 所有 GKE 版本：
      • 執行 kube-bench，根據基準測試評估工作站節點。詳情請參閱 kube-bench GitHub 存放區。
      • 使用 Twistlock Defender 等第三方工具，根據基準評估節點。
    • GKE Enterprise 版本：使用「法規遵循」資訊主頁評估所有叢集，確保符合 CIS GKE 基準。詳情請參閱「關於 GKE 法規遵循資訊主頁」。

  • CIS Kubernetes 基準：執行 kube-bench，根據基準評估工作節點。您無法根據基準中的建議評估受管理控制層。

後續步驟