服務範圍支援資料夾

VPC Service Controls 的資料夾成員資格功能，可讓您定義以 Google Cloud 資料夾為成員的 service perimeter。這項功能可讓您透過單一 perimeter 設定保護整個資料夾階層，減少大規模管理 perimeter 的管理負擔。

本文說明 perimeter 支援資料夾的運作方式，並涵蓋下列主題：

  • 在 perimeter 中使用資料夾的核心概念、行為和優點。

  • 資料夾型成員資格、巢狀資源和資源階層規則 (例如繼承和評估優先順序) 之間的互動。

  • 如何查詢專案和資料夾設定的 perimeter。

  • 使用這項功能的最佳做法和已知限制。

關於 perimeter 中的資料夾成員

Google Cloud 資料夾可包含多個專案、其他資料夾，或兩者兼具。雖然您可以將資料夾中的個別專案新增至 service perimeter，但建議您改為新增上層資料夾。建立 perimeter 時，如果將資料夾指定為受保護資源，VPC Service Controls 會納入該資料夾中的所有資源，例如專案和巢狀資料夾。

當您將專案新增至已在 perimeter 中設定的資料夾時，VPC Service Controls 會自動將這些專案新增至相同的 perimeter。您不必更新 perimeter 設定來納入這些專案。同樣地，當您從資料夾中移除專案時，VPC Service Controls 會自動從 perimeter 移除這些專案。

巢狀資料夾和沿用機制

VPC Service Controls 會限制您在 perimeter 中設定的資料夾內所有資源，例如巢狀資料夾及其資源。將資料夾新增至 perimeter 時，VPC Service Controls 會自動限制該資料夾及其子資料夾中的所有專案。

資源成員資格評估優先順序

Google Cloud 資源只能由一個強制執行模式的一般 service perimeter，以及一個模擬測試模式的一般 service perimeter 保護。如果資源或其上層資料夾與多個 perimeter 相關聯，則資源階層中最低層級的關聯會決定有效 perimeter。

VPC Service Controls 會獨立評估強制執行模式和模擬測試模式的優先順序：

  • 強制執行模式優先順序：有效的強制執行 perimeter 取決於階層中最低的資源 (專案本身或其最接近的上層資料夾)，該資源會明確指派給強制執行 perimeter。
  • 模擬測試模式優先順序：有效的模擬測試 perimeter 取決於階層中最低的資源，該資源明確指派給模擬測試 perimeter，或隱含繼承自明確指派的強制執行資源。

為專案或子資料夾設定 dry run perimeter，不會停用或覆寫上層資料夾設定的 enforced perimeter。

優先順序範例

  • 範例 1 (在強制執行模式下直接覆寫專案)：如果您在強制執行的 perimeter (sp1) 中設定上層資料夾 (folders/1)，並在另一個強制執行的 perimeter (sp2) 中明確設定該資料夾中的專案 (projects/1)，則 projects/1 會受到 sp2 的保護。直接指派專案的優先順序高於資料夾繼承。folders/1 中的所有其他專案 (例如 projects/2) 仍透過資料夾繼承受 sp1 保護。

  • 範例 2 (模擬測試模式中的資料夾繼承)：在模擬測試模式中，當您在 service perimeter 設定資料夾 (folders/1) 時，該資料夾中的所有專案 (projects/1 和 projects/2) 都會沿用模擬測試 perimeter 設定 (sp1)，除非明確停用。除非巢狀資源明確設定了不同的模擬測試 perimeter，否則模擬測試繼承行為與強制執行模式繼承行為相同。

  • 範例 3 (獨立評估強制執行和模擬測試 perimeter)：VPC Service Controls 會獨立評估強制執行和模擬測試關聯。如果您在 enforced perimeter (sp1) 中設定上層資料夾 (folders/1)，並明確將該資料夾中的專案 (projects/1) 指派給 dry run perimeter (sp2)，則 projects/1 會繼續受到 sp1 的保護 (強制執行模式)，同時由 sp2 進行評估 (模擬測試模式)。將專案指派給 dry run perimeter，不會覆寫或停用上層資料夾的 enforced perimeter。

  • 範例 4 (多層級資料夾階層和子資料夾優先順序)：在多層級資料夾階層中，VPC Service Controls 會評估階層中每個層級的優先順序。如果祖系資料夾 (folders/2) 是在強制執行的 perimeter (sp1) 中設定，則所有包含的專案 (projects/1 和 projects/2) 都會繼承 sp1 強制執行。如果在不同層級指派 dry run perimeter，例如將祖系 folders/2 指派給 dry run perimeter sp2，並將專案 projects/2 (位於子資料夾 folders/1) 指派給 dry run perimeter sp1，則每個專案都會沿用最接近祖系的模擬測試設定。因此，系統會根據 sp2 模擬測試評估 projects/1，但會根據 sp1 模擬測試評估 projects/2。

查詢有效的設定範圍

由於資源可以從上層資料夾繼承 perimeter 保護，因此您可以使用 LookupConfiguredServicePerimeter 方法，找出保護專案或資料夾的 service perimeter。

API 會傳回下列內容：

  • servicePerimeter：有效 enforced perimeter 的完整名稱。
  • servicePerimeterDryRun：有效 dry run perimeter 的完整名稱。
  • restrictedResource：直接附加 enforced perimeter 的特定資源 (專案或資料夾)。
  • restrictedResourceDryRun：直接附加 dry run perimeter 的特定資源。

詳情請參閱「查詢已設定的 perimeter」。

從 perimeter 排除專案

如要將專案從資料夾層級 perimeter 排除，請明確將該專案指派給不限制任何服務，且允許所有輸入和輸出流量的獨立 perimeter。由於明確的專案設定優先於資料夾層級 perimeter，因此專案會從資料夾 perimeter 中排除。

如要瞭解如何更新 perimeter，請參閱「更新 service perimeter」。

範圍政策

範圍政策中的 service perimeter 只會限制該政策範圍內的資源。如要將資料夾納入範圍限定 perimeter 的成員，存取權政策必須限定在該資料夾或該資料夾的上層 (例如上層資料夾或組織)。

最佳做法

管理以資料夾為基礎的 perimeter 時，請參閱下列最佳做法。

安全地將專案遷移至資料夾 perimeter

從明確專案成員資格轉換為資料夾成員資格時，請按照下列步驟操作，避免意外中斷 perimeter 強制執行：

  1. 將目標上層資料夾新增至 service perimeter。
  2. 在資源階層中，將專案移至該上層資料夾。
  3. 請在 perimeter 設定中保留明確的專案項目，直到資源階層傳播在所有系統中完成為止。傳播作業通常會在幾分鐘內完成，但有時可能需要更久。
  4. 從 perimeter 移除明確的專案設定。專案仍會透過資料夾繼承機制受到保護。

階層移動

移動資料夾或專案會變更其有效的 perimeter 保護。為避免意外拒絕存取，請與 Resource Manager 管理員協調所有階層移動作業。

如果您將已在 perimeter 中設定的專案移至其他資料夾，並將該資料夾新增至同一個 perimeter，請在 perimeter 中保留現有的明確專案成員資格設定，直到資源階層傳播完成為止。傳播作業通常會在幾分鐘內完成，但有時可能需要更多時間。這段等待期有助於避免從 perimeter 移除明確專案設定時，發生非預期的 perimeter 強制執行問題。

限制

  • perimeter bridge 不支援以資料夾為基礎的成員資格。Perimeter bridge 僅接受專案資源。

  • VPC Service Controls 不支援資料夾層級的 API 資源。

  • 由於已知問題，在 dry run perimeter 中將虛擬私有雲網路專案設為受保護資源，會覆寫以資料夾為基礎的強制執行。如果將網路專案明確新增至 dry run perimeter，該專案就會失去從祖系資料夾繼承的 enforced perimeter 保護。

  • 非Google Cloud API 和使用allowed_service_patterns設定的 perimeter 不支援資料夾成員資格。如要允許存取這些服務模式，必須明確將來源專案或虛擬私有雲網路新增至 perimeter，而不是透過資料夾繼承。

後續步驟