迁移项目

本指南介绍如何在资源层次结构内的组织或地点之间移动项目。

项目资源是 Google Cloud 组织中的基本级层组织实体。项目在组织下创建,并且可以置于文件夹或组织资源本身之下,形成资源层次结构。由于收购、监管要求以及业务部门之间分离等等事项,您可能需要在组织之间迁移项目。

您可以使用 Resource Manager API 跨组织移动项目,或将项目移动到其当前组织的资源层次结构中的其他位置。通过 Resource Manager API,您还可以回滚迁移操作,以将项目移回资源层次结构中的原始位置。

创建迁移计划

在项目移动期间要考虑的最重要的事项就是迁移对项目内运行的服务有何影响。Resource Manager API 将项目资源及其下运行的所有服务视为一个单元,这意味着在项目内不会应用任何配置更改。

虽然迁移不会直接对项目配置进行更改,但资源层次结构的更改可能会影响项目及其运行服务的功能。继承的政策(如 Identity and Access Management 或组织政策)在迁移过程中不会随项目一起移动,而只是直接附加到资源的政策和服务帐号。迁移完成后,这可能会导致意外行为。

在移动项目之前,您应该考虑制定迁移计划,以确定您的组织和您要移动的项目是否已准备就绪。在此迁移方案中,清点项目正在运行的每个服务以及可能受到移动影响或受到您的项目所在目标位置中的资源层次结构影响的其他所有服务。

广告资源概览

使用 Cloud Asset Inventory 创建正在使用的资源概览,包括 Identity and Access Management 政策。此概览可帮助您概述迁移计划。

您还可以使用 Cloud Asset Inventory 将这些数据转移到 BigQuery 中。这样您就可以使用 SQL 查询数据,这比解读 JSON 格式的数据更易于读取。如需了解如何导出此数据,请参阅导出到 BigQuery

政策验证

迁移项目时,它不再从资源层次结构中的当前位置继承政策,并且将受到目标位置的有效政策评估的约束。我们建议确保项目目标位置的有效政策尽可能匹配项目在其源位置中拥有的政策。

任何直接应用于项目的政策仍然会在迁移完成后附加。将政策直接应用于项目是验证移动完成后是否应用了正确政策的一个好方法。

Identity and Access Management 政策和组织政策通过资源层次结构继承,如果设置不当,它们可能会阻止服务正常运行。在资源层次结构中的项目目标位置确定有效政策,以确保该政策与您的治理目标保持一致。

管理加密密钥

您应验证项目是否启用了客户管理的加密密钥或其他 Cloud Key Management Service。加密密钥归项目所有,对该项目具有 owner 访问权限的用户可以在 Cloud KMS 中对该项目中的密钥管理和执行加密操作。

如需了解详情,请参阅职责分离

预览功能

您可以对组织、文件夹或项目启用预览功能。如果您为要迁移的项目启用了 Alpha 版或 Beta 版功能,则该功能应在迁移后继续正常运行。如果预览功能是不公开的且未针对目标组织列入许可名单,则在转移完成后,您将无法进行任何配置更改。

回滚方案

如果发现任何已迁移项目无法正常工作,则可以将其移回其原始位置。为此,您需要具备必要的 IAM 权限并设置所需的组织政策,以便可以反向运行项目迁移。

如需查看所需权限的列表,请参阅分配权限。对于需要配置为允许迁移项目的组织政策,请参阅配置组织政策

专用导入和导出文件夹

在源组织和目标组织中迁移项目时,政策继承机制可能会导致非预期的结果。要降低此风险,您可以创建特定文件夹以仅储存要导出和导入的项目,并确保两个组织中的文件夹继承相同的政策。您还可以设置对这些文件夹的权限,在资料夹内移动的项目将继承这些权限,从而帮助加快项目迁移过程。

在规划迁移时,请考虑先设置一个专用源文件夹。为此,请为您打算将项目导出到的每个组织创建一个文件夹。然后,为这些文件夹设置组织政策,其中每个 constraints/resourcemanager.allowedExportDestinations 限制条件均设置为您要导出项目的单个组织。

例如,您可以设置 Export to Marketing OrgExport to Sales Org 文件夹,每个文件夹都设置了适当的组织政策限制条件。

同样,在目标组织中设置专用导入文件夹,您要从中导入项目的每个组织都有一个文件夹。为此,请为您希望计划从中导入项目的每个组织创建一个文件夹。然后,为这些文件夹设置组织政策,其中每个政策都包含 constraints/resourcemanager.allowedImportSources 限制条件,其设置为您要从中导入项目的单个组织。

例如,您可以设置 Import from Marketing OrgImport from App Development Org 文件夹,每个文件夹都设置了适当的组织政策限制条件。

在每个导入和导出文件夹中,为将要移动项目的人员分配 roles/resourcemanager.projectMover 角色。这些文件夹内包含的任何项目都将继承此角色,从而允许用户能够对移至这些文件夹的任何项目中执行移动操作。

完成项目迁移后,您应移除这些专用文件夹。

如需了解如何设置组织政策,请参阅配置组织政策

分配权限

在组织之间移动项目需要以下权限。

如需获得这些权限,请让您的管理员在资源层次结构的适当级层授予建议的角色。

项目移动权限

对于要移动的项目资源及其父级资源,您需要拥有 Project Mover 角色 (roles/resourcemanager.projectMover),或者拥有包含 v1 Resource Manager API 的以下权限的其他角色:

  • 您要移动的资源所需的权限:

    • resourcemanager.projects.update
  • 父资源所需的权限:

    • resourcemanager.projects.move

在目标资源上,您需要的权限取决于项目将要移动到的资源。

  • 如果目标资源是文件夹,您需要拥有 Project Mover 角色 (roles/resourcemanager.projectMover),或者拥有包含 resourcemanager.projects.move 权限的其他角色。

  • 如果目标资源是组织,您需要拥有 Project Creator 角色 (roles/resourcemanager.projectCreator) 或者拥有包含 resourcemanager.projects.create 权限的其他角色。

组织政策权限

在源组织和目标组织中,您必须拥有 roles/orgpolicy.policyAdmin 角色,该角色可授予创建和管理组织政策的权限。

配置组织政策

如需将项目资源移动到新组织,您必须先应用组织政策,以便定义可向其移动项目的组织。您还必须在目标位置中设置组织政策,用于定义可导入项目的组织。

针对您要移动的项目的父级资源,请设置包含 constraints/resourcemanager.allowedExportDestinations 限制条件的组织政策。这会将目标目的地定义为项目可以迁移到的有效位置。

针对目标资源设置包含 constraints/resourcemanager.allowedImportSources 限制条件的组织政策。这会将来源定义为可从中迁移项目的有效位置。

例如,假设您有一个项目 my-test-project 位于 ID 为 12345678901 的组织下,并且您希望将其移至您的二级业务部门所属的新组织(ID 为 45678901234)。

您需要对 organizations/12345678901 设置组织政策并执行 constraints/resourcemanager.allowedExportDestinations 限制条件,并将 under:organizations/45678901234 设为 allowed_value

然后对 organizations/45678901234 设置组织政策并执行 constraints/resourcemanager.allowedImportSources 限制条件,并将 under:organizations/12345678901 设置为 allowed_value

执行这些组织政策后,您便能够将 my-test-projectorganizations/12345678901 移至 organizations/45678901234(假设您拥有分配权限中所述的权限)。

更改项目的结算帐号

Cloud Billing 帐号可以跨组织使用。将项目从一个组织移动到另一个组织不会影响结算,系统会对旧结算帐号继续收费。不过,项目在组织之间进行移动时,系统通常还会要求改用新的结算帐号。

要更改现有项目的结算帐号,您必须在该项目中拥有 roles/owner 角色,并且对目标结算帐号拥有 roles/billing.admin 角色。要更改结算帐号,请执行以下操作:

  1. 转到 Cloud Console 中的“结算”页面
    转到“结算”页面
  2. 点击要更改的结算帐号的名称。
  3. 与此结算帐号相关联的项目下,找到要移动的项目的名称,然后点击右侧的菜单按钮。
  4. 点击更改结算帐号,然后选择新的结算帐号。
  5. 点击设置帐号

已经产生但尚未在交易历史记录中报告的费用将被计入原来的结算帐号。这可能包括项目迁移之前最多两天的费用。

在组织间迁移结算帐号

结算帐号可以从一个组织迁移到另一个组织,但这通常不是必须执行的步骤。大多数现有组织已经拥有应该改用的结算帐号。如果您需要迁移现有结算帐号,请执行以下操作:

  1. 获取来源组织和目标组织的 roles/billing.admin 角色。
  2. 转到 Cloud Console 中的“结算”页面
    转到“结算”页面
  3. 点击待迁移结算帐号的名称。
  4. 帐号管理页面的顶部,点击更改组织
  5. 选择目标组织,然后点击确定

该结算帐号现在已经与指定的组织相关联。

执行迁移。

如果您具有相应的 IAM 权限并且执行所需的组织政策,则可以使用 Resource Manager API 来移动项目资源。

gcloud

如需在组织下迁移项目,请运行以下命令:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

您还可以使用以下命令将文件夹指定为目标资源:

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

其中:

  • PROJECT_ID 是您要迁移的项目的 ID 或编号。
  • ORGANIZATION_ID 是您要向其中迁移项目的组织的 ID。您只能指定一个目标(即组织或文件夹)。
  • FOLDER_ID 是项目要移动到的文件夹的 ID。您只能指定一个目标(即文件夹或组织)。

API

借助 v1 Resource Manager API,您可以通过将项目的 parent 字段设置为目标资源的 ID 来移动项目。

要迁移项目 =,请执行下列操作:

  • 使用 projects.get() 方法获取 project 对象。
  • 将其 parent 字段设置为组织的 ID,或是该字段要移动到的文件夹的 ID。
  • 使用 projects.update() 方法更新 project 对象。

以下代码段展示了上述步骤:

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

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

回滚迁移

如果您错误地移动了项目,则可以将旧来源用作新目的地,将旧目的地作为新来源,再次执行移动来回滚该操作。为此,您必须拥有必要的 IAM 权限并执行组织政策,就好像这是全新的迁移。

处理特殊情况

迁移无组织的项目

您可以将尚未与组织关联的项目迁移到组织中。但是,您无法使用此过程将其更改回无组织。如果您的某个项目与您的组织关联,并且您希望将其还原为无组织,请联系您的支持代表寻求帮助。

迁移与组织无关的项目的过程与在组织之间迁移项目的过程类似,但并不需要迁移计划中涉及的所有步骤。如需将项目迁移到组织,您应该按以下步骤操作:

  1. 验证项目将继承的政策对此项目的影响。

  2. 必要的话,请在目标组织中创建一个专用导入文件夹

  3. 按照分配权限所述,分配对项目和目标父级的 Identity and Access Management 权限。

  4. 确定是否需要更改结算帐号

然后,您就可以执行迁移。

控制台

要将项目迁移到组织,请执行以下操作:

  1. 打开 Cloud Console 中的 IAM 和管理 > 设置页面。

    打开“设置”页面

  2. 选择页面顶部的项目选择器

  3. 组织选择器中选择无组织。如果您未与任何组织建立关联,则系统不会显示组织选择器,因此您可以跳过此步骤。

  4. 选择您要迁移的项目。

    项目选择器的屏幕截图

  5. 点击页面顶部的迁移

  6. 组织下拉列表中,选择要将项目迁移到其中的组织。

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
    }

共享 VPC

共享 VPC 项目可以根据特定条件进行迁移。首先,源组织中拥有 roles/orgpolicy.policyAdmin 角色的用户必须设置组织政策,其中包含要导出的项目的父级上的 constraints/resourcemanager.allowEnabledServicesForExport 限制条件。此限制条件应将 SHARED_VPC 列为 allowed_value

必须先迁移共享 VPC 宿主项目,然后再迁移其所有服务项目。我们建议您在源位置和目标位置的组织之间匹配防火墙规则,这可以最大限度地减少潜在问题,并避免项目和网络在迁移期间出现任何停机时间。如果您在迁移其他服务项目时无限期地将一些服务项目留在源组织中,我们不能保证您的网络的健康。

如果您迁移宿主项目,则可以将其移回源组织,但在开始移动服务项目后,必须先移动所有项目,然后才能再次迁移宿主项目。

自定义 Identity and Access Management 角色

您可以在组织级层创建自定义 Identity and Access Management 角色,以便精细控制对资源的访问权限,但这些角色仅在创建它们的组织中有效。如果您尝试将包含用户的 IAM 政策绑定的项目移动到组织级层的自定义 IAM 角色,则该移动将会失败并显示失败的前提条件错误,说明相关角色不存在于目标组织中。

如需列出组织级层的所有自定义 IAM 角色,请运行以下 gcloud 命令行工具命令:

gcloud iam roles list --organization ORGANIZATION_ID

其中,ORGANIZATION_ID 是您要列出其角色的组织 ID。如需了解如何查找组织 ID,请参阅创建和管理组织

如需了解您的组织中的自定义 Identity and Access Management 角色,请运行以下 gcloud 命令行工具命令:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

其中:

  • ORGANIZATION_ID 是角色父级组织的组织 ID。

  • ROLE_ID 是您要描述的角色的名称。

如要解决失败的前提条件错误,您应该为项目继承的每个组织级层自定义角色创建等效的项目级层自定义角色。然后,移除引用组织级层自定义角色的 IAM 角色绑定。

项目迁移后,您便可以更新 IAM 政策以使用目标组织中的组织层级自定义角色。

如需进一步了解自定义角色,请参阅创建和管理自定义角色

存储分区锁定

借助 Cloud Storage 存储分区锁定,您可以在 Cloud Storage 存储分区中配置数据保留政策,来管理存储分区中对象必须保留多长时间。存储分区锁定是使用安全锁进行保护,防止意外删除项目。

在迁移过程中,保留政策和安全锁将保留在项目中,但您应该清楚是否移动强制执行存储分区锁定的项目,并防止意外移动。

VPC Service Controls 安全边界

借助 VPC Service Controls,用户可以围绕其 Google Cloud 服务设置基于项目的安全边界,从而降低数据渗漏风险。您无法迁移 VPC Service Controls 安全边界保护的项目。

如需从安全边界中移除项目,请参阅管理服务边界。创建或更新边界后,位于 VPC Service Controls 边界内的项目可能无法跨组织移动长达一天。从服务边界中移除项目后,可能需要几个小时的时间才能移动项目。

专用互连

我们建议将包含专用互连对象的项目以及带有 VLAN 连接的项目一起迁移到这些专用互连对象。虽然可以迁移具有专有互连对象或关联了 VLAN 连接的项目,并且这些项目可在组织之间正常迁移,但您将无法跨组织拆分创建新的 VLAN 连接。

对一个组织中附加了专用互连对象或关联了该专用互连对象的 VLAN 连接进行的更改可能不会传播到另一个项目,因此我们建议您尽可能不要跨组织拆分此类项目太长时间。

合作伙伴互连

使用合作伙伴互连迁移项目时,无需特别注意。

Assured Workloads

您无法在组织之间移动 Assured Workloads 项目。任何向尝试这样做的操作都会以编程形式被禁止。

跨项目服务帐号

如果您要移动的项目附加了跨项目服务帐号,那么该服务帐号在目标组织中仍将有效。即使存在组织政策对附加了服务帐号的项目限制网域,该项目也会继续工作。

如果您要移动的项目拥有连接到源组织中其他项目的跨项目服务帐号,则该服务帐号在目标组织中仍然有效。但是,对于已应用网域限制组织政策的任何资源(限制资源属于源组织所在的网域),您将无法对其使用该服务帐号。

例如,假设您在 organizations/12345678901 中拥有 project-A。此项目附加了 serviceAccount-1,用于将其设置为跨项目服务帐号。project-Bproject-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 Login

如果在源项目中启用 OS Login,请在目标组织中将 roles/compute.osLoginExternalUser IAM 角色分配给源项目成员,以免这些成员失去访问权限。

将服务帐号附加到资源

对于大多数 Google Cloud 服务,用户需要具有服务帐号的 iam.serviceAccounts.actAs 权限才能将该服务帐号关联到资源。但是,在过去,为了方便某些服务的使用,即使用户不具备模拟服务帐号的权限,某些服务也允许用户将服务帐号关联到资源。详情请参阅此处

如果客户的源组织具有旧版行为(可以在没有正常角色授予的情况下附加服务帐号),而目标组织则没有,则将 roles/iam.serviceAccountUser 授予将这些服务帐号附加到资源的用户。如需了解如何模拟服务帐号,请参阅模拟服务帐号

如要查看您的组织是否有旧版行为,请执行以下操作:

  1. 在 Cloud Console 中,转到组织政策页面。

    转到“组织政策”页面

  2. 从页面顶部的项目选择器中,选择要检查旧版状态的组织。

  3. 在组织政策列表顶部的过滤条件框中,输入 constraints/appengine.enforceServiceAccountActAsCheck

  4. 如果 appengine.enforceServiceAccountActAsCheck 组织政策出现在列表中,则该组织将具有旧版行为。

  5. 对以下组织政策 c 限制条件重复步骤 3 和 4:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. 如果出现任何组织政策限制条件,则您的组织将使用旧版行为。

如果源组织具有旧版行为,而目标组织没有,则授予上述角色。如果源组织和目标组织都具有旧版行为,则无需执行任何操作,但建议强制执行政策以防止意外模拟。