從 PodSecurityPolicy 遷移至 PodSecurity 許可控制器

本頁說明如何從 PodSecurityPolicy 遷移至 PodSecurity 許可控制器，繼續在 Google Kubernetes Engine (GKE) 叢集中強制執行許多 Pod 層級的安全控管措施。

總覽

PodSecurityPolicy 是 Kubernetes 許可控制器，可讓您強制執行 Pod 層級的安全控制項，例如 Kubernetes Pod 安全標準，並精細控管已部署工作負載的安全設定。Kubernetes 專案已淘汰 PodSecurityPolicy，並在 Kubernetes 1.25 版中完全移除這項功能。

如果您目前在 GKE 叢集中使用 PodSecurityPolicy，請先停用這項功能，再升級至 GKE 1.25 版和後續版本。

如要進一步瞭解 PodSecurityPolicy 淘汰和移除事宜，請參閱「PodSecurityPolicy 淘汰事宜」。

PodSecurity 和 PodSecurityPolicy

在執行下列 GKE 版本的叢集上，PodSecurity 准入控制器預設會啟用：

  • 1.25 以上版本：穩定版
  • 1.23 版和 1.24 版：Beta 版

PodSecurity 可讓您在已部署的工作負載上，強制執行Pod 安全標準中定義的政策。PodSecurity 可讓您在從 PodSecurityPolicy 遷移後，繼續在叢集中導入建議的 Pod 層級安全設定。與 PodSecurityPolicy 不同，PodSecurity 不支援自訂設定。

需求條件和限制

  • PodSecurity 在 GKE 1.23 和 1.24 版中為 Beta 版，在 GKE 1.25 以上版本中為穩定版。
  • PodSecurity 不會終止節點上已執行的 Pod，即使這些 Pod 違反套用的政策也一樣。
  • PodSecurity 不會變更欄位。如果您在 PodSecurityPolicy 中使用任何變動欄位，請修改 Pod 規格，確保部署工作負載時存在這些欄位。

事前準備

開始之前，請確認你已完成下列工作：

  • 啟用 Google Kubernetes Engine API。
    • 啟用 Google Kubernetes Engine API
  • 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行 gcloud components update，取得最新版本。
  • 確認您有執行 1.23 以上版本的 GKE Autopilot 或 Standard 叢集。
  • 檢查 PodSecurityPolicy 資源的變動欄位設定。 將這些欄位新增至 Pod 資訊清單，讓節點上已執行的任何工作負載，都符合 Pod 安全性標準中定義的政策。如需操作說明，請參閱「簡化及標準化 Pod 安全性政策」。

在叢集中設定 Pod 安全性許可控制器

PodSecurity 許可控制器會在命名空間層級強制執行 Pod 安全性標準。您必須設定控制器，在每個命名空間中強制執行 Pod 安全性標準定義的其中一項政策。以下為可用的政策：

  • 受限：最嚴格的政策。符合 Pod 強化最佳做法。
  • 基準：限制最少的政策，可防止已知的權限提升。允許 Pod 規格中欄位的所有預設值。
  • 具備特殊權限：不受限制的政策，允許任何項目，包括已知的權限提升。請謹慎套用這項政策。

如要將 PodSecurityPolicy 設定遷移至 PodSecurity 許可控制器，請在叢集的每個命名空間中執行下列操作。後續章節將詳細說明這些步驟。

  1. 在 dry-run 模式中，對命名空間套用「受限」政策，並檢查是否有違規事項。
  2. 如果 Pod 違反受限制政策，請在 dry-run 模式中對命名空間套用限制較寬鬆的基準政策，並檢查是否有違規情形。
  3. 如果 Pod 違反「基準」政策，請修改 Pod 規格，修正違規問題。
  4. 當「Baseline」政策不再傳回違規事項時，請以 enforce 模式將政策套用至命名空間。

為避免 PodSecurity 拒絕新 Pod 而導致可能停機，請在測試環境中執行下列步驟。或者，您也可以在 audit 模式中套用已識別的政策，而非 enforce 模式，並查看稽核記錄，找出可能遭拒的 Pod。

audit 模式不會強制執行政策，GKE 會部署 Pod，並在 GKE 稽核記錄中新增項目。

列出叢集中的所有命名空間

取得叢集中所有命名空間的清單。針對清單中的每個命名空間，重複執行下列章節中的步驟：

kubectl get ns

在下列 GKE 版本中，GKE 會忽略您套用至 kube-system 命名空間的政策：

  • 1.23.6-gke.1900 以上版本
  • 1.24.0-gke.1200 以上版本

在舊版 GKE 中，請避免在 kube-system 中強制執行政策。

在模擬測試模式下套用 Pod 安全性標準的每項政策

在後續步驟中，您將以dry-run 模式套用各項政策，首先是限制最嚴格的「受限」政策。如果輸出內容顯示警告，請修改違規的 Pod 規格，使其符合政策規定，或嘗試限制較少的「基準」政策。如果輸出內容未顯示警告，您就可以在沒有 dry-run 模式的情況下套用「基準」政策。

  1. 在dry-run模式下套用「受限」政策：

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted

    如果命名空間中的 Pod 違反「受限制」政策，輸出內容會類似於下列內容：

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled

    如果「受限」政策顯示警告，請修改 Pods 以修正違規問題，然後再次嘗試執行指令。或者，您也可以在下一個步驟中，嘗試限制較少的「基準」政策。

  2. 在 dry-run 模式下套用「Baseline」政策：

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

    如果命名空間中的 Pod 違反 Baseline 政策，輸出內容會類似於下列內容：

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

如果 Pod 違反 Baseline 政策，請修改 Pod 以修正違規問題，然後重複這個步驟，直到 GKE 不再顯示警告為止。

在命名空間中強制執行政策

找出適用於命名空間的政策後，請在 enforce 模式中將政策套用至命名空間：

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

將 POLICY 替換為政策名稱，可以是 restricted、baseline 或 privileged 其中一個。

請務必針對叢集中的每個命名空間重複上述步驟。

在叢集上停用 PodSecurityPolicy 功能

為叢集中的每個命名空間設定 PodSecurity 許可控制器後，請停用 PodSecurityPolicy 功能：

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

將 CLUSTER_NAME 替換為 GKE 叢集的名稱。

將叢集升級至 GKE 1.25 版時，GKE 會自動移除所有剩餘的 PodSecurityPolicy 物件，包括 GKE、Policy Controller 新增的物件，以及您先前定義的任何 PodSecurityPolicy 物件。

建議

  • 請盡可能遵守「受限制」政策。稽核應用程式，確認是否能進一步強化設定。
  • 您可以將 Pod 安全性模式鎖定為特定 Kubernetes 次要版本，方法是在前述步驟中，將 pod-security.kubernetes.io/MODE-version: VERSION 標籤新增至 kubectl label 指令。請將 VERSION 替換為 Kubernetes 版本號碼，例如 v1.24。
  • 停用 PodSecurityPolicy 功能後，請檢查正在執行的應用程式，確認安全性設定是否中斷或有缺口。
  • 設定 PodSecurity 後，請更新命名空間建立程序，自動將 PodSecurity 標籤套用至所有新命名空間。詳情請參閱「查看命名空間建立程序」

後續步驟