處理特殊情況

本文提供遷移專案時處理特殊情況的相關資訊。遷移專案時，請確認您已取得專案、父項資源和目的地資源的必要 IAM 權限。

遷移未與機構資源建立關聯的專案

您可以將未與機構資源建立關聯的專案遷移至機構資源。不過，您無法使用這個程序將專案還原成無機構狀態。如果專案與機構資源建立關聯，且您想將專案還原成無機構狀態，請與支援代表聯絡以尋求協助。

您必須在目的地機構資源中獲派 roles/resourcemanager.projectCreator 角色。

如果您沒有專案父項機構資源的 resourcemanager.organizations.get 權限，專案可能不會在Google Cloud 控制台的實際機構中如預期顯示。這可能會導致專案看起來未與任何機構資源建立關聯。詳情請參閱「限制使用者專案瀏覽權限」。

如要判斷專案是否與機構資源相關聯，請按照下列步驟操作：

gcloud

執行下列指令：

gcloud projects describe PROJECT_ID

將 PROJECT_ID 替換為要遷移的專案 ID。

如果輸出內容中沒有顯示父項資源，表示專案未與機構資源建立關聯。

如果輸出內容中顯示父項資源 (資料夾或機構資源)，表示專案與機構資源相關聯。

遷移未與機構資源建立關聯的專案，與在機構資源之間遷移專案的程序類似，但不需要遷移計畫中的所有步驟。如要將專案遷移至機構資源，請按照下列步驟操作：

  1. 確認專案將沿用的政策對專案的影響。

  2. 視需要，在目標機構資源中建立專屬匯入資料夾。

  3. 如「指派權限」一文所述，為專案和目的地父項資源指派身分與存取權管理權限。

  4. 判斷是否需要變更帳單帳戶。

接著即可執行遷移作業。

控制台

如要將專案遷移至機構資源，請按照下列步驟操作：

  1. 在 Google Cloud 控制台中，依序開啟「IAM & admin」(IAM 與管理員) >「Settings」(設定) 頁面。

    開啟「設定」頁面

  2. 選取頁面頂端的「專案挑選器」。

  3. 從機構選擇器中選取「無機構」。如果您未與任何機構資源建立關聯，系統就不會顯示機構挑選器，您可以略過這個步驟。

  4. 選取要遷移的專案。

    專案選擇工具的螢幕截圖

  5. 按一下頁面頂端的 [Migrate] (遷移)。

  6. 在「Organization」(機構) 下拉式清單中，選取專案要遷往的機構資源。

gcloud

如要將專案遷移至機構資源，請執行下列指令：

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

其中：

  • PROJECT_ID 是您想遷移至機構資源的專案 ID。
  • ORGANIZATION_ID 是您想將專案遷移至的機構資源 ID。

API

透過 Resource Manager API，您就能將專案的 parent 欄位設為機構資源的機構資源 ID，藉此將專案遷移至機構資源中。

如要將專案遷移至機構資源，請按照下列步驟操作：

  • 使用 projects.get() 方法取得 project 物件。
  • 將其 parent 欄位設為機構資源的機構資源 ID。
  • 使用 projects.update() 方法更新 project 物件。

設定 parent 欄位之後，您將無法變更該欄位。

以下用程式碼片段說明上述步驟：

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

如果來源專案已啟用 OS 登入，您必須將 roles/compute.osLoginExternalUser 角色指派給有權存取該專案的所有主體。

Shared VPC

Shared VPC 專案可依特定條件遷移。首先，來源機構資源中具有 roles/orgpolicy.policyAdmin 角色的使用者，必須在要匯出專案的上層資源中，設定包含 constraints/resourcemanager.allowEnabledServicesForExport 限制的機構政策。這項限制應將 SHARED_VPC 列為allowed_value。

遷移前不需要停用 Shared VPC。不過，您必須先遷移 Shared VPC 主專案，再遷移所有服務專案。建議您比對來源和目標位置的機構資源防火牆規則，盡量減少潛在問題，並避免專案和網路在遷移期間發生任何停機情形。如果您在遷移其他服務專案時，將部分服務專案無限期留在來源機構資源中，我們無法保證網路的健康狀態。

如果遷移主專案，可以將其移回來源機構資源。主專案和服務專案分屬不同機構的時間長度沒有確切期限。不過，開始遷移服務專案後，您必須先遷移所有服務專案，才能再次遷移主專案。

自訂 Identity and Access Management 角色

您可以在機構資源層級建立自訂 Identity and Access Management 角色，精細控管資源存取權，但這些角色僅在建立時所屬的機構資源中有效。如果您嘗試遷移專案，而該專案包含使用者與機構層級自訂 IAM 角色的允許政策繫結，遷移作業會因前提條件錯誤而失敗，並說明相關角色不存在於目標機構資源中。

如要列出機構資源層級的所有自訂 IAM 角色，請執行下列 Google Cloud CLI 指令：

gcloud iam roles list --organization ORGANIZATION_ID

其中 ORGANIZATION_ID 是您要列出角色的機構資源 ID。如要瞭解如何找出機構資源 ID，請參閱「取得機構資源 ID」一文。

如要取得機構資源中自訂 Identity and Access Management 角色的相關資訊，請執行下列 Google Cloud CLI 指令：

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

其中：

  • ORGANIZATION_ID 是角色父項機構資源的機構資源 ID。

  • ROLE_ID 是您要說明的角色名稱。

如要解決先決條件錯誤，請為專案繼承的每個機構層級自訂角色，建立同等的專案層級自訂角色。然後移除參照機構層級自訂角色的 IAM 角色繫結。

專案遷移完成後，您可以更新允許政策，在目的地機構資源中使用機構層級的自訂角色。

如要進一步瞭解自訂角色，請參閱建立及管理自訂角色。

值區鎖定功能

Cloud Storage bucket 鎖定可讓您在 Cloud Storage bucket 中設定資料保留政策，控管 bucket 中的物件必須保留多久。bucket 鎖定功能會使用防刪除鎖定保護，防止專案遭到誤刪。

遷移專案時，資料保留政策和防刪除鎖定會一併遷移，但如果遷移的專案強制執行值區鎖定，請務必留意，以免發生意外移動。

VPC Service Controls 安全範圍

VPC Service Controls 可讓使用者為Google Cloud 服務設定專案層級的安全範圍，以降低資料竊取風險。您無法遷移受 VPC Service Controls 安全範圍保護的專案。

如要從安全防護範圍移除專案，請參閱「管理 service perimeter」。VPC Service Controls 範圍內的專案可能不會遭到封鎖，無法在機構資源之間遷移。建立或更新 perimeter 後，這項規範最多適用一天。從服務範圍移除專案後，可能需要數小時才能遷移專案。

Dedicated Interconnect

建議您一併遷移含有 Dedicated Interconnect 物件的專案，以及含有 VLAN 連結的專案。在機構資源之間遷移後，專案中連線至 Dedicated Interconnect 物件或 VLAN 連結的物件，仍會繼續運作。唯一限制是您無法在機構資源分割之間建立新的 VLAN 連結。

如果某個機構資源中的專案已附加 Dedicated Interconnect 物件，或已連結至該物件的 VLAN 連結，則對該專案所做的設定變更可能不會傳播至其他機構資源。建議您盡可能不要讓這類專案長期分散在機構資源之間。

Partner Interconnect

使用 Partner Interconnect 遷移專案時，不需要特別注意任何事項。

跨專案服務帳戶

在遷移跨專案服務帳戶的背景下，適用下列情況：

  • 如果您遷移的專案已附加跨專案服務帳戶，該服務帳戶會在目標機構資源中繼續運作。即使有限制該專案網域的機構政策，該專案仍會繼續使用附加的服務帳戶。
  • 如果您遷移的專案擁有附加至來源機構資源中其他專案的跨專案服務帳戶，該服務帳戶將繼續在目標機構資源中運作。不過，如果資源套用了網域限制機構政策，且該政策將資源限制在來源機構資源的網域中，您就無法在這些資源上使用該服務帳戶。

舉例來說，假設您有 project-A，位於 organizations/12345678901 中。這個專案已附加 serviceAccount-1，並設為跨專案服務帳戶。project-B 和 project-C，同樣在 organizations/12345678901 中，也請使用 serviceAccount-1。

您已將包含網域限制條件的機構政策套用至 project-C，因此該政策只允許存取 organizations/12345678901. 的網域。

如果您將 serviceAccount-1 新增至 project-C 的 IAM 繫結，然後將 project-A 遷移至 organizations/45678901234，服務帳戶就會正常運作。

如果您從 project-A 遷移至 organizations/45678901234，然後嘗試將 serviceAccount-1 新增至 project-C 的 IAM 繫結，繫結會因違反網域限制條件而失敗。

客服案件

如果遷移的專案有未結案的客服案件，請與 Google 支援聯絡人聯絡，告知對方已完成遷移。如果專案有未結案的 Google 客服案件，在 Google 支援團隊更新案件中繼資料，將案件指向新的機構資源前，專案將無法查看這些案件。

如果專案設定為使用內部 OAuth 同意畫面，且您將專案遷移至其他組織資源，則只有目標組織資源的成員可以授權要求。這項變更最多可能需要 24 小時才會生效。在此之前，來源機構資源的成員可以授權要求。

以下步驟說明如何確保來源機構資源的成員在遷移期間不會失去存取權。建議在目標機構資源中為機構資源成員建立新使用者，這樣就不必變更 OAuth 同意畫面設定。

為避免來源機構資源的成員失去存取權，請按照下列步驟操作：

  1. 將 OAuth 同意畫面更新為外部，而非內部。

  2. 標示為內部測試且使用機密資料的應用程式，不需要申請應用程式驗證。如果應用程式使用私密資料，當同意畫面更新為外部時，來源機構資源的使用者會在授權畫面之前看到未經驗證的應用程式畫面。為避免這種情況，請申請應用程式驗證，以便使用敏感或受限制的範圍。

OS 登入

如果來源專案已啟用 OS 登入，您必須將 roles/compute.osLoginExternalUser 角色指派給有權存取該專案的所有主體。確保這些主體在目標機構資源中不會失去存取權。

虛擬機器 (VM) 執行個體的共用預留項目

在共用預留項目中，建立預留項目的專案 (擁有者專案) 或與預留項目共用的任何專案 (消費者專案)，都可以透過建立 VM 執行個體來使用預留項目。您只能與擁有者專案所屬機構內的專案共用預留項目。

將擁有者或消費者專案遷移至其他機構時，會發生下列情況：

  • 如果將擁有者專案遷移至其他機構，Compute Engine 會刪除擁有者專案建立的所有預訂項目。執行中的 VM 執行個體不受影響。
  • 如果將用戶專案遷移至其他機構，該專案就會停止使用先前機構中任何共用預留項目的資源。

詳情請參閱「共用預留項目的運作方式」。

將服務帳戶連結至資源

對於大多數 Google Cloud 服務，使用者必須具備服務帳戶的 iam.serviceAccounts.actAs 權限，才能將該服務帳戶附加至資源。不過，為了簡化新手上路程序，某些服務過去允許使用者將服務帳戶附加至資源，即使使用者沒有模擬服務帳戶的權限也沒關係。詳情請參閱「要求將服務帳戶附加至資源的權限」。

如果客戶的來源機構資源具有舊版行為 (可附加服務帳戶，不必授予一般角色)，但目的地機構資源沒有，請將「服務帳戶使用者」角色 (roles/iam.serviceAccountUser) 授予將這些服務帳戶附加至資源的使用者。如要瞭解將服務帳戶附加至資源時所需的權限，請參閱「服務帳戶驗證的角色」。

如要確認機構資源是否具有舊版行為，請按照下列步驟操作：

  1. 前往 Google Cloud 控制台的「Organization policies」(組織政策) 頁面。

    前往「Organization policies」(組織政策) 頁面

  2. 在頁面頂端的專案選取器中，選擇要檢查舊版狀態的機構資源。

  3. 在組織政策清單頂端的篩選器方塊中，輸入 constraints/appengine.enforceServiceAccountActAsCheck。

  4. 如果清單中顯示 appengine.enforceServiceAccountActAsCheck 機構政策，表示機構資源採用舊版行為。

  5. 針對下列每個機構政策限制重複執行步驟 3 和 4：

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck

  6. 如果出現任何這類機構政策限制，表示貴機構資源使用舊版行為。

如果來源機構資源具有舊版行為，而目的地沒有，請按照上述方式授予角色。如果來源和目的地機構資源都採用舊版行為，則無須採取任何行動，但建議強制執行政策，避免發生非預期的模擬行為。

遷移使用 BigQuery sharing 功能的專案

如果您將使用 BigQuery sharing (舊稱 Analytics Hub) 的專案遷移至其他機構資源，可能會遇到一些錯誤。如要解決錯誤，請與支援團隊聯絡。

如果新機構的「共用管理員」頁面未顯示舊機構的資料交換資源，請使用 Analytics Hub API 更新新機構中資料交換的任何欄位 (例如 description 欄位)，觸發快取重新整理。

請使用 projects.locations.dataExchanges.patch 方法。

PATCH https://analyticshub.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataExchanges/DATA_EXCHANGE_ID?update_mask=UPDATE_DX_FIELD -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }

更改下列內容：

  • PROJECT_ID 是專案的專屬 ID。
  • LOCATION 是資料交換庫的位置。
  • DATA_EXCHANGE_ID 是資料交換的 ID。
  • UPDATE_DX_FIELD 是要更新的欄位。可以是交易所的任何欄位，例如 description。
  • UPDATE_DX_VALUE 是欄位的新值。這可能與該欄位的原始值相同。

使用備份和災難復原服務遷移專案

如要將專案遷移至其他機構資源，請先停用備份和災難復原服務。目前停用這項服務時，您需要將服務中斷風險納入考量。遷移至新機構資源完成後，請重新啟用備份和災難復原服務。

遷移具有繼承 Privileged Access Manager 授權的專案

將專案遷移至其他機構前，建議您先撤銷該專案的所有有效範圍授權。範圍授予項目是指根據從資料夾或機構繼承的授權建立的授予項目，然後範圍限定為子專案。

如果專案有有效的範圍授權，且您將專案遷移至其他機構，修改後的 IAM 政策會移至新機構，但管理該政策的授權仍會保留在原機構。也就是說，授權使用的 Privileged Access Manager 服務代理程式會失去修改新機構中資源 IAM 政策的權限。因此，對該授權執行的任何撤銷或撤回作業都會失敗，且要求者會保留存取權，直到授權到期為止。

後續步驟

如要瞭解如何執行遷移作業，請參閱「執行遷移作業」。