總覽

本頁面提供 Google Distributed Cloud (GDC) 實體隔離方案的專案網路政策總覽。

專案網路政策會定義輸入或輸出規則。與 Kubernetes 網路政策不同，您只能為政策指定一種政策類型。政策中的每項規則都可以設定為「允許」(預設) 或「拒絕」動作。

對於專案內的流量，GDC 會為每項專案套用預先定義的專案網路政策，即預設專案內政策。

根據預設，專案中的服務和工作負載會與外部服務和工作負載隔離。不過，只要套用跨專案流量網路政策，不同專案命名空間和相同組織內的服務和工作負載，就能互相通訊。

同樣地，如要將服務和工作負載連至其他組織中專案以外的目的地，必須取得明確核准。您必須停用資料竊取防護功能，才能允許組織外部流量。

輸入和輸出防火牆規則是專案網路政策的主要元件，可決定允許或拒絕哪些類型的流量進出網路。如要在 GDC 中為專案命名空間設定防火牆規則，請使用 GDC 控制台。

安全性與連線能力

根據預設，專案中的服務和工作負載會與該專案隔離。除非設定網路政策，否則無法與外部服務和工作負載通訊。

如要在 GDC 中為專案命名空間設定網路政策，請使用 ProjectNetworkPolicy 資源。這項資源可讓您定義政策，允許專案內部、專案之間、連至外部 IP 位址，以及來自外部 IP 位址的通訊。此外，您必須停用專案的資料竊取防護功能，才能將工作負載移出專案。

GDC 專案網路政策屬於外加規則，工作負載的最終強制執行結果，是流量與套用至該工作負載的所有政策聯集之間的「任何」比對結果。如果有多項政策，系統會將各政策的規則相加組合，只要流量符合至少一項規則，就會允許。

明確的 Deny 規則絕對優先於 Allow 規則。如果流量符合 Deny 規則，即使其他規則或預設平台政策允許，該流量也會遭到捨棄。

此外，套用選取工作負載的單一政策後，系統會拒絕所有未指定的流量 (預設拒絕模式)。因此，當您套用一或多項政策，並選取工作負載做為主體時，系統只會允許明確允許 (且未明確拒絕) 的流量。

當您使用為專案分配的知名 IP 位址時，系統會對來自組織的傳出流量執行來源網路位址轉譯 (NAT)。

預設專案內政策

建立專案時，GDC 會自動在專案命名空間中，建立名為 base-policy-allow-intra-project-traffic 的全域專案網路政策。這項預設政策會執行下列作業：

  • 選取專案中的所有使用者工作負載做為主體。
  • 允許相同專案中所有工作負載的傳入流量，透過所有通訊埠傳送至這些工作負載。
  • 不允許來自其他專案或組織外部的傳入流量。

GDC 只會在建立專案時建立預設政策。如果您變更或刪除政策，GDC 不會還原政策。GDC 會將政策傳播至專案中的每個叢集，並命名為 g-base-policy-allow-intra-project-traffic。政策的 status.zones[].replicaStatus.propagatedName 欄位會顯示這個名稱。

執行下列指令，查看預設政策：

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

更改下列內容：

如果指令傳回 NotFound 錯誤，表示預設政策已刪除。如要重新新增，請參閱「建立 ingress 專案內政策」。

預設政策會與您建立的政策合併，如下所示：

  • 輸入：無論是否存在預設政策，工作負載預設都會與其他專案和組織外部隔離。您建立的輸入政策會新增允許的來源，例如其他專案或外部 CIDR 區塊。預設政策存在時，您不必在自己的輸入政策中重複設定專案內規則。
  • 工作負載層級的專案內輸入：預設政策存在時，專案中的所有工作負載都能透過所有通訊埠互相連線。除非您刪除或變更預設政策，否則使用 Allow 動作的工作負載層級專案內輸入政策不會限制這類流量。為避免服務中斷，請先套用工作負載層級政策，並確認政策已準備就緒，再刪除預設政策。如要在保留預設政策的同時，封鎖特定專案內流量，可以使用明確拒絕規則 (預先發布版功能)。詳情請參閱「建立輸入工作負載層級專案內政策」。
  • 輸出：專案預設沒有輸出政策。組織內部的傳出流量不受限制，但資料竊取防護功能 (預設為啟用) 會封鎖離開組織的流量。停用專案的資料竊取防護功能後，輸出政策才會生效。啟用資料竊取防護功能後，可用區 API 伺服器會拒絕輸出政策，且全域輸出政策不會準備就緒。

全域專案網路政策

您可以建立全域專案網路政策。全域專案網路政策的範圍涵蓋整個 GDC 宇宙。每個 GDC 宇宙可包含多個 GDC 可用區，這些可用區會組織成相互連結並共用控制層的區域。舉例來說，如果一個宇宙包含兩個區域，每個區域各有三個可用區，則可能如下所示：us-virginia1-a、us-virginia1-b、us-virginia1-c 和 eu-ams1-a、eu-ams1-b、eu-ams1-c。

可用區專案網路政策的範圍，僅限於建立時指定的可用區。每個可用區都是獨立的災難網域。可用區會管理使用本機控制層的基礎架構、服務、API 和工具。

如要進一步瞭解 GDC 宇宙中的全域資源，請參閱「多可用區總覽」。

您可以使用網路 Kubernetes 資源模型 (KRM) API 建立全域專案網路政策。使用 API 版本 networking.global.gdc.goog 建立全域資源。

您可以使用 KRM API 或 GDC 控制台，建立可用區專案網路政策。使用 API 版本 networking.gdc.goog 建立可用區資源。

允許所有網路政策

您可以建立允許所有流量的網路政策，為專案建立廣泛的預設存取規則。

您可以設定下列類型的「全部允許」網路政策：

  • 允許所有網路政策：允許來自任何來源的流量，包括其他專案和外部 IP。
  • 允許所有外部網路政策：允許傳入和傳出組織外部 IP 位址的流量。
  • 允許所有專案的網路政策：允許組織內所有專案的流量。

詳情請參閱「建立允許所有流量的網路政策」。

明確拒絕網路政策

您可以在專案網路政策中設定明確拒絕規則，限制指定專案或 CIDR 區塊之間的連線。

拒絕規則的主要功能和限制：

  • 優先順序：拒絕規則的優先順序絕對高於允許規則 (包括基礎平台政策)。
  • 輸出安全規則：為避免意外封鎖重要基礎架構流量，輸出拒絕規則會自動排除系統和非專案命名空間。
  • 對等互連限制：為確保設定安全，輸入拒絕規則必須在 from 欄位中明確指定來源對等互連，而輸出拒絕規則必須在 to 欄位中明確指定目的地對等互連。您無法將對等互連欄位留空，藉此選取所有來源或目的地。對等互連欄位不得留空，否則政策會遭拒。
  • 啟用 DEP 時無法設定輸出拒絕規則：如果專案已啟用資料竊取防護 (DEP) 功能，就無法設定輸出拒絕規則。

詳情請參閱「建立明確拒絕網路政策」。

工作負載層級網路政策

您可以建立工作負載層級的網路政策，為專案中的個別 VM 和 Pod 定義精細的存取控管機制。這些政策就像是工作負載的防火牆，會根據標籤控管流量，強化安全性並隔離應用程式。這種精細程度可讓您更嚴格地控管哪些工作負載可以在專案內部和跨專案之間互相通訊。

工作負載層級網路政策也提供在單一可用區強制執行 PNP 的功能。

詳情請參閱「建立工作負載層級的專案內政策」和「建立工作負載層級的跨專案政策」。

政策結構和驗證

在 ProjectNetworkPolicy 資源中，工作負載標籤選取器會巢狀排列多個層級。下列輸入政策顯示每個選取器的正確位置：

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

更改下列內容：

  • PROJECT：專案名稱。
  • PEER_PROJECT：包含用戶端工作負載的專案名稱。

這項政策允許 PEER_PROJECT 中標示為 app: frontend 的工作負載，透過 TCP 通訊埠 8080 連線至專案中標示為 app: backend 的工作負載。

撰寫政策時，請遵循下列規則：

  • 請一律將 spec.policyType 明確設為 Ingress 或 Egress。Ingress 政策只能包含具有 from 對等互連的 ingress 規則，而 Egress 政策只能包含具有 to 對等互連的 egress 規則。如果省略 policyType，政策會預設為 Ingress，且 API 伺服器會拒絕僅包含 egress 規則的政策。
  • 如要依標籤選取主體工作負載，請使用 spec.subject.userWorkloadSelector.labelSelector.workloads。如果省略 userWorkloadSelector，政策會套用至專案中的所有使用者工作負載。
  • 請勿將標籤選取器直接放在 spec.subject 下方。根據預設，kubectl 會拒絕 spec.subject.matchLabels 等欄位，並顯示 strict decoding error: unknown field 訊息。
  • 如要依標籤選取對等互連工作負載，請在 from 或 to 項目中使用 projectSelector.workloadSelector.labelSelector.workloads。
  • 如果主體或對等工作負載是 VM，請在標籤鍵前面加上 user-label.gpc.gke.io/。例如，使用 user-label.gpc.gke.io/app: backend。
  • 自動建立的預設專案內政策和部分現有政策會使用已淘汰的 spec.subject.workloadSelector 欄位，該欄位會直接採用標籤選取器。在新政策中使用 userWorkloadSelector。

如要根據全域 API 伺服器驗證政策，而不套用政策，請執行伺服器端模擬測試：

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

模擬測試會回報與實際 kubectl apply 指令相同的結構定義和驗證錯誤，例如 Ingress 政策中的未知欄位或 egress 規則，但不會建立或變更政策。模擬測試所需的權限與套用政策相同。模擬測試成功並不代表政策已強制執行。套用政策後，請確認政策已生效。

如要列出全域 API 伺服器接受的欄位，請執行下列指令：

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

更改下列內容：

  • GLOBAL_API_SERVER：全域 API 伺服器的 kubeconfig 路徑。
  • POLICY_FILE：ProjectNetworkPolicy 資訊清單的路徑。

準備預先定義的角色和存取權

如要設定專案網路政策，您必須具備必要的識別資訊和存取權角色：

  • 專案網路政策管理員：具備全域專案命名空間中所有多可用區 PNP 資源的寫入權限。請要求 IAM 機構組織管理員授予您 global-project-networkpolicy-admin 角色。詳情請參閱「預先定義的角色說明」。

使用 IP 區塊指定叢集節點

您可以使用 ProjectNetworkPolicy 資源中的 ipBlocks 欄位，指定個別節點 IP 位址或節點 CIDR 範圍，並控管 Pod 與特定叢集節點之間的流量 (例如允許從控制層節點輸入至自訂 Webhook Pod，或限制 Pod 輸出至控制層節點)。如需操作說明，請參閱「為標準叢集建立專案內政策」。

規模考量

設定專案網路政策來指定特定節點，或使用廣泛的 CIDR 範圍時，政策設定選項可能會影響擴充性和效能：

  • 0.0.0.0/0 的行為：在 ipBlocks 規則中使用廣泛的 CIDR 範圍 (例如 0.0.0.0/0)，會比對叢集中的所有節點，以及外部 IP 位址。
  • 擴充：叢集中的每個節點都會獲派專屬 CIDR 身分。每個工作負載端點 (VM 或 Pod) 都有一個內部政策表格，用於儲存網路規則。在大型叢集中，0.0.0.0/0 等廣泛的 ipBlocks 規則會增加政策資料表用量，且用量與節點數量成正比，因為系統必須為每個不重複的節點 CIDR 身分建立項目。
  • 警告：如果節點數量過多或政策複雜，請避免在 ipBlocks 規則中使用過於廣泛的 CIDR 範圍，否則可能會達到端點的政策資料表限制。如果端點達到這項限制，就無法套用新的網路政策，這可能會中斷網路連線，或導致該工作負載無法強制執行政策。

後續步驟