資源階層

本頁面說明 Google Cloud 資源階層，以及可透過 Resource Manager 管理的資源。

Google Cloud 資源階層有兩個目的：

  • 提供擁有權階層，將資源的生命週期繫結到階層中的直接父項。
  • 為存取權控管及機構政策提供附加點與沿用設定。

用比喻的方式來說， Google Cloud 資源階層類似傳統作業系統中的檔案系統，是階層化組織及管理實體的一種方式。一般來說，每項資源都有一個對應的父項。這種階層式的資源組織方式，讓您只要對父項資源套用特定的存取權控管政策和配置設定，子項資源就會沿用這些政策與 Identity and Access Management (IAM) 設定。

Google Cloud 資源階層的詳細資料

Google Cloud 資源會以階層方式整理。除了階層中的最高資源外，所有資源都只有一個父項。在最低層級，服務資源是構成所有 Google Cloud 服務的基本元件。服務資源的範例包括 Compute Engine 虛擬機器 (VM)、Pub/Sub 主題、Cloud Storage 值區及 App Engine 執行個體。所有層級較低的資源均會從屬於特定專案資源，這些專案則代表 Google Cloud 資源階層的第一個分組機制。

所有使用者 (包括免費試用使用者、免費方案使用者，以及 Google Workspace 和 Cloud Identity 客戶) 都能建立專案資源。Google Cloud 免費計畫使用者只能在專案中建立專案資源和服務資源。專案資源可以位於階層頂端，但前提是必須由免費試用使用者或免費層級使用者建立。Google Workspace 和 Cloud Identity 客戶可以存取 Google Cloud 資源階層的其他功能，例如機構和資料夾資源。詳情請參閱 Cloud Identity 總覽。階層頂端的專案資源沒有父項資源，但網域建立機構資源後，即可將專案資源遷移至該機構資源。如要進一步瞭解如何遷移專案資源，請參閱遷移專案資源。

Google Workspace 和 Cloud Identity 客戶可以建立機構資源。每個 Google Workspace 或 Cloud Identity 帳戶都會與一個機構資源建立關聯。如果機構資源存在，則會位於 Google Cloud 資源階層的最上層，屬於機構的所有資源都會以機構資源分組。如此即可對屬於機構資源的所有資源提供集中式的瀏覽權限和控制。

資料夾資源是機構資源和專案資源之間額外的選用分組機制。擁有機構資源是使用資料夾的先決條件。資料夾資源及其子項專案資源會對應至機構資源。

Google Cloud 資源階層，特別是包含機構資源和資料夾資源的最完整形式，能讓公司將機構資源對應到 Google Cloud ，並為存取權管理政策 (IAM) 和機構政策提供邏輯附加點。允許、拒絕和機構政策都是透過階層沿用，階層中每個資源的有效政策都是直接套用於資源的政策，以及沿用自其祖系的政策。

下圖為完整形式的資源階層範例： Google Cloud

機構資源

機構資源代表組織 (例如公司)，也是Google Cloud 資源階層的根節點 (如有)。機構資源在階層上是資料夾和專案資源的祖系。套用於機構資源的允許和拒絕政策，也會套用於該機構中整個階層的所有資源。

Google Cloud 使用者不需要具備機構資源，但如果沒有機構資源，就無法使用 Resource Manager 的部分功能。機構資源與 Google Workspace 或 Cloud Identity 帳戶密切相關。當擁有 Google Workspace 或 Cloud Identity 帳戶的使用者建立 Google Cloud 專案資源時，系統就會自動為使用者佈建機構資源。

每個 Google Workspace 或 Cloud Identity 帳戶可能只有佈建一個機構資源。為網域建立機構資源之後，根據預設，由該帳戶網域成員建立的所有新 Google Cloud 專案資源皆隸屬於該機構資源。受管理使用者建立專案資源時，必須位於某個機構資源中。如果使用者指定機構資源，且具備適當權限，專案就會指派給該機構。否則，系統會預設為使用者相關聯的機構資源。與機構資源相關聯的帳戶無法建立與機構資源無關的專案資源。

為簡化說明，我們將使用「Google Workspace」一詞，同時指稱 Google Workspace 和 Cloud Identity 使用者。

Google Workspace 或 Cloud Identity 帳戶代表公司，而且是存取機構資源的先決條件。在 Google Cloud 的結構定義中，G Suite 或 Cloud Identity 帳戶提供身分管理、復原機制、擁有權及生命週期管理。下圖顯示 Google Workspace 帳戶、Cloud Identity 與Google Cloud 資源階層之間的連結。


Google Workspace 超級管理員負責網域擁有權的驗證，並擔任復原需求的聯絡人。因此，Google Workspace 超級管理員在預設上可以指派 IAM 角色。Google Workspace 超級管理員主要的 Google Cloud 職責是將機構管理員 IAM 角色指派給網域中的適當使用者。以便做到使用者普遍要求的 Google Workspace 和管理職責區分。 Google Cloud

機構資源的優點

有了機構資源，專案資源是屬於您的機構，而不是建立專案的員工。這表示當員工離開公司時，專案資源不會被刪除；相反地，專案資源將遵循機構資源在 Google Cloud上的生命週期。

此外，機構管理員可以集中控制所有資源。 他們可以查看並管理您公司的所有專案資源。這種強制執行表示再也不會有影子專案與問題管理員。

此外，如果您在機構層級授予角色，該機構資源下的所有專案和資料夾資源都會沿用。舉例來說，您可以在機構層級為網路團隊授予網路管理員角色，允許他們管理公司中所有專案資源中的所有網路，而不用為他們授予所有個別專案資源的角色。

Cloud Resource Manager API 公開的機構資源包括以下內容：

  • 機構資源 ID，這是機構的唯一識別碼。
  • 顯示名稱，是從 Google Workspace 或 Cloud Identity 的主網域名稱產生。
  • 機構資源的建立時間。
  • 機構資源的最後修改時間。
  • 機構資源的擁有者。擁有者會在建立機構資源時指定，一旦設定就無法更改。擁有者同時也是在 Directory API 中指定的 Google Workspace 客戶 ID。

以下程式碼片段顯示機構資源的結構：

{
  "creationTime": "2020-01-07T21:59:43.314Z",
  "displayName": "my-organization",
  "lifecycleState": "ACTIVE",
  "name": "organizations/34739118321",
  "owner": {
    "directoryCustomerId": "C012ba234"
  }
}

在新建立的機構資源上，初始允許政策會將專案建立者及帳單帳戶建立者的角色授予整個 Google Workspace 網域。這表示使用者能夠像在機構資源建立之前那樣，繼續建立專案資源及帳單帳戶。建立機構資源時，不會建立其他資源。

資料夾資源

資料夾資源可提供進一步的分組機制，為專案劃定明確的分界。資料夾可視為機構資源內的子機構。資料夾資源可用來為公司內的不同法人、部門和團隊建立模型。舉例來說，第一層級的資料夾資源可用來代表機構資源中的主要部門。由於資料夾資源可包含專案資源和其他資料夾，每個資料夾資源也能包含其他子資料夾，用來代表不同團隊。每個團隊資料夾可以包含其他子資料夾來代表不同的應用程式。如要進一步瞭解如何使用資料夾資源，請參閱「建立及管理資料夾資源」一文。

如果您的機構資源中有資料夾資源，而且您具有適當的檢視權限，就可以從 Google Cloud 主控台檢視這些資源。如需詳細指示，請參閱「查看或列出資料夾和專案資源」。

資料夾資源允許委任管理權，例如：每位部門負責人都會獲得屬於其部門所有資源的完全擁有權。 Google Cloud同樣地，資料夾資源也可以限制存取資源，因此某一部門的使用者只能存取和建立 Google Cloud 其資料夾資源中的資源。

以下程式碼片段顯示資料夾資源的結構：

{
  "createTime": "2030-01-07T21:59:43.314Z",
  "displayName": "Engineering",
  "lifecycleState": "ACTIVE",
  "name": "folders/634792535758",
  "parent": "organizations/34739118321"
}

如同機構和專案資源，資料夾資源也是允許、拒絕和機構政策的政策沿用點。資料夾中的所有專案和資料夾資源，都會自動沿用在這個資料夾資源授予的 IAM 角色。

專案資源

專案資源是基礎層級的機構實體。機構和資料夾資源可包含多個專案。專案資源是使用 Google Cloud的基本要件，並且奠定多項作業的基礎，可用於建立、啟用及使用所有Google Cloud 服務、管理 API、啟用計費功能、新增和移除協作者，以及管理權限。

所有專案資源都包含以下項目：

  • 兩個 ID：
    1. 專案資源 ID，這是專案資源的唯一識別碼。
    2. 專案資源編號，在您建立專案時自動指派。它是唯讀的。
  • 一個可變動的顯示名稱。
  • 專案資源的生命週期狀態，例如 ACTIVE 或 DELETE_REQUESTED。
  • 可用來篩選專案的標籤集合。
  • 專案資源的建立時間。

以下程式碼片段顯示專案資源的結構：

{
  "createTime": "2020-01-07T21:59:43.314Z",
  "lifecycleState": "ACTIVE",
  "name": "my-project",
  "parent": {
    "id": "634792535758",
    "type": "folder"
  },
  "projectId": "my-project",
  "labels": {
     "my-label": "prod"
  },
  "projectNumber": "464036093014"
}

如要與多數 Google Cloud 資源互動，每個要求都需附上專案資源的識別資訊。您可以使用以下兩種方式其中之一來識別專案資源：專案資源 ID 或專案資源編號 (程式碼片段中的 projectId 和 projectNumber)。

專案資源 ID 是您在建立專案資源時選擇的自訂名稱。如果您啟用了需要專案資源的 API，系統會引導您建立專案資源，或使用專案資源 ID 選取專案資源。(請注意，UI 中顯示的 name 字串與專案資源 ID 不同)。

專案資源編號是由 Google Cloud自動產生。專案資源 ID 和專案資源編號均可在 Google Cloud 控制台中的專案資源資訊主頁上找到。如要瞭解如何取得專案 ID 及其他專案資源管理工作，請參閱「建立及管理專案資源」。

在新建立的專案資源上，初始 IAM 政策會將擁有者角色授予專案的建立者。

允許和拒絕政策沿用

Google Cloud 提供 IAM，可讓您以精細的方式授予使用者特定 Google Cloud 資源的存取權限，避免其他資源遭到未經授權者擅自存取。對資源設定允許和拒絕政策之後，您就能控管哪些人 (使用者) 具有何種存取權限 (角色)，可以存取哪些資源。

您可以在機構資源、資料夾資源和專案資源上設定允許和拒絕政策。您也可以對部分服務資源設定允許政策。

資源會繼承母項資源的政策。如果您在機構層級設定允許或拒絕政策，所有子項資源都會沿用這項政策。如果您在專案層級設定允許政策，該層級的所有子項資源都會沿用這項政策。

對資源來說有效的允許或拒絕政策，是由對資源本身設定的允許或拒絕政策，以及從祖先沿用的允許或拒絕政策共同構成。這種沿用是可遞移的。詳情請參閱「政策評估」。

舉例來說，在上述資源階層圖中，如果您在「Department Y」資料夾中設定允許政策，將 Compute Engine 執行個體管理員 (roles/compute.instanceAdmin) 角色授予 bob@example.com，則 Bob 將在「Development project」、「Test project」和「Production project」中擁有該角色。如果您在「測試專案」中將 Compute Engine 執行個體管理員角色指派給 alice@example.com，她就只能管理該專案中的 Compute Engine 執行個體。

角色一律會沿用至下層物件。如果您從「測試專案」中移除 Bob 的 Compute Engine 執行個體管理員 (roles/compute.instanceAdmin) 角色，他會從「Y 部門」資料夾繼承該角色。您可以使用拒絕政策，禁止主體使用繼承的權限。

允許和拒絕政策是透過 Google Cloud 資源階層繼承。如果您變更資源階層，允許和拒絕政策階層也會一併變更。舉例來說，將專案移至機構資源，專案的允許和拒絕政策就會更新，改為沿用機構資源的允許和拒絕政策。同樣地，將專案資源從一個資料夾資源移至另一個資料夾資源，將會變更沿用的權限。專案資源移動到新的資料夾資源時，將會失去原本從父項資源沿用的權限。專案資源移動後，會沿用目的地資料夾資源中設定的權限。

歡迎試用

如果您未曾使用過 Google Cloud，歡迎建立帳戶來評估我們的產品在實際工作環境中的成效。新客戶還能獲得價值 $300 美元的免費抵免額，可用於執行、測試及部署工作負載。

免費試用