プロジェクトの移行

このガイドでは、リソース階層内の組織または場所間でプロジェクトを移行する方法について説明します。

プロジェクト リソースは、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 の鍵に対して暗号オペレーションの管理と実行ができます。

詳細については、職掌分散をご覧ください。

プレビューの機能

組織、フォルダ、プロジェクトでプレビュー機能を有効にできます。移行するプロジェクトでアルファ版またはベータ版の機能を有効にすると、移行後でもこの機能は引き続き機能します。プレビュー機能が非公開組織のみで、移行先の組織で許可されていない場合、移動完了後に構成の変更はできません。

ロールバック プラン

移行したどのプロジェクトでも機能していない何かがあることがわかった場合は、元の場所に戻すことができます。実行するには、必要な IAM 権限を持ち、必要な組織のポリシーを設定する必要があります。そうすることで、プロジェクトの逆への移行を実行できます。

必要な権限の一覧については、権限の割り当てをご覧ください。プロジェクトの移行を許可するよう構成する必要がある組織のポリシーについては、組織のポリシーの構成をご覧ください。

専用のインポート フォルダとエクスポート フォルダ

ポリシーの継承により、移行元と移行先の組織の両方でプロジェクトを移行すると、意図しない結果が生じることがあります。このリスクを軽減するには、エクスポートとインポートのためのプロジェクトだけを保持する特定のフォルダを作成し、両方の組織のフォルダに同じポリシーが継承されるようにします。これらのフォルダに権限を設定して、そのフォルダ内に移動するプロジェクトに継承することもできます。これにより、プロジェクトの移行プロセスを高速化できます。

移行を計画する場合は、最初に専用のソースフォルダを設定するようにしてください。これを行うために、プロジェクトをエクスポートする予定の組織ごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのエクスポート先の単一の組織に constraints/resourcemanager.allowedExportDestinations 制約が設定されています。

たとえば、Export to Marketing OrgExport to Sales Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。

同様に、宛先組織に専用のインポートフォルダを設定し、プロジェクトのインポート元組織にも 1 つ設定します。これを行うために、プロジェクトをインポートする予定の組織ごとにフォルダを作成します。次に、これらのフォルダに組織ポリシーを設定します。各フォルダーには、プロジェクトのインポート元の単一の組織に constraints/resourcemanager.allowedImportSources 制約が設定されています。

たとえば、Import from Marketing OrgImport from App Development Org のフォルダを設定し、それぞれに適切な組織ポリシー制約を設定できます。

それぞれのインポート フォルダとエクスポート フォルダで、プロジェクトを移行するユーザーに roles/resourcemanager.projectMover ロールを割り当てます。このロールは、これらのフォルダ内に含まれるすべてのプロジェクトに継承され、ユーザーはこれらのフォルダに移行されたプロジェクトに対して移行オペレーションを実行できます。

プロジェクトの移行が完了したら、これらの専用フォルダを削除する必要があります。

組織のポリシーの設定については、組織のポリシーの構成をご覧ください。

権限の割り当て

組織間でプロジェクトを移動するには、次の権限が必要です。

これらの権限を取得するには、リソース階層に見合うレベルで示されたロールを付与するように管理者へ依頼してください。

プロジェクト移動の権限

移動するプロジェクト リソースとその親リソースには、プロジェクト移動のロール(roles/resourcemanager.projectMover)、または v1 Resource Manager API に対する次の権限を含む別のロールが必要です。

  • 移動するリソースに対して必要な権限:

    • resourcemanager.projects.update
  • 親リソースに対して必要な権限:

    • resourcemanager.projects.move

移行先のリソースでは、必要となる権限は、プロジェクトを移行するリソースによって異なります。

  • 移行先のリソースがフォルダの場合は、プロジェクト移行のロール(roles/resourcemanager.projectMover)または resourcemanager.projects.move 権限を含む別のロールが必要です。

  • 移行先のリソースが組織である場合は、プロジェクト作成者のロール(roles/resourcemanager.projectCreator)または resourcemanager.projects.create 権限を含む別のロールが必要です。

組織のポリシーの権限

移行元の組織と移行先の組織には roles/orgpolicy.policyAdmin ロールが必要です。このロールには、組織のポリシーを作成し管理する権限が付与されます。

組織のポリシーの構成

プロジェクト リソースを新しい組織に移行するには、まず、プロジェクトの移行先の組織を定義する組織のポリシーを適用します。また、プロジェクトのインポートを許可する組織を定義する組織のポリシーを移行先に設定する必要もあります。

移行するプロジェクトの親リソースで、constraints/resourcemanager.allowedExportDestinations 制約を含む組織のポリシーを設定します。これにより、対象とする移行先が、プロジェクトの移行を受け入れる有効な場所として定義されます。

移行先のリソースで、constraints/resourcemanager.allowedImportSources 制約を含む組織のポリシーを設定します。これにより、移行元は、プロジェクトを移行できる有効な場所として定義されます。

たとえば、プロジェクト my-test-project が ID 12345678901 の組織に存在し、そのプロジェクトをセカンダリ ビジネス ユニットの新しい組織に ID 45678901234 を使用して移行するとします。

その場合、constraints/resourcemanager.allowedExportDestinations 制約を適用して organizations/12345678901 に組織ポリシーを設定し、under:organizations/45678901234allowed_value として設定します。

次に、constraints/resourcemanager.allowedImportSources 制約を適用して organizations/45678901234 に組織ポリシーを設定し、under:organizations/12345678901allowed_value として設定します。

これらの組織のポリシーが適用されると、my-test-projectorganizations/12345678901 から organizations/45678901234 に移動できるようになり、権限の割り当てで説明された権限を持っていると仮定されます。

プロジェクトの請求先アカウントの変更

Cloud Billing アカウントは組織間で使用できます。プロジェクトをある組織から別の組織に移行しても課金に影響はありません。料金は、古い請求先アカウントに対して継続して課せられます。ただし組織を移行すると、新しい請求先アカウントへの移行が必要になる場合もあります。

既存のプロジェクトの請求先アカウントを変更するには、プロジェクトにおける roles/owner のロールと、変更後の請求先アカウントにおける roles/billing.admin のロールが必要です。請求先アカウントを変更するには:

  1. Cloud Console の [お支払い] ページに移動します。
    [お支払い] ページに移動
  2. 変更する請求先アカウントの名前をクリックします。
  3. [この請求先アカウントにリンクされているプロジェクト] で、移行するプロジェクトの名前を見つけて、右側のメニューボタンをクリックします。
  4. [お支払い情報の変更] をクリックして、新しい請求先アカウントを選択します。
  5. [アカウントを設定] をクリックします。

トランザクション履歴でまだ報告されていない料金がすでに発生している場合は、変更前の請求先アカウントに請求されます。これには、最大でプロジェクトを移行する 2 日前までの料金が含まれます。

請求先アカウントを組織間で移行する

請求先アカウントをある組織から別の組織へ移行できますが、これは必ずしも必要な手順ではありません。ほとんどの既存組織はすでに請求先アカウントを持っているので、それらを代わりに使用することをおすすめします。既存の請求先アカウントを移行する必要がある場合は、次の手順を実施します。

  1. 移行に必要な権限を取得します。
    1. 移行元組織の roles/billing.admin
    2. 移行先組織の roles/billing.creator
  2. Cloud Console の [お支払い] ページに移動します。
    [お支払い] ページに移動
  3. 移行させる請求先アカウントの名前をクリックします。
  4. [概要] ページの最上部で [組織を変更] をクリックします。
  5. 移行先組織を選択して、[OK] をクリックします。

これで、請求先アカウントは指定した組織に関連付けられました。

移行を実行する

適切な 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 です。1 つの組織またはフォルダのどちらか 1 つの対象のみを指定できます。
  • FOLDER_ID は、プロジェクトの移行先フォルダの ID です。1 つのフォルダまたは組織のどちらか 1 つの対象のみを指定できます。

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_VPCallowed_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 境界内にあるプロジェクトは、境界が作成または更新されてから最大 1 日の間、組織間での移動がブロックされない場合があります。サービス境界からプロジェクトを削除した後、プロジェクトを移動できるようになるまでに数時間かかることがあります。

CDN Interconnect

CDN Interconnect オブジェクトを使用するプロジェクトと、これらの CDN Interconnect オブジェクトに接続する VLAN アタッチメントを持つプロジェクトは、一緒に移行することをお勧めします。CDN Interconnect オブジェクトを使用する、またはプロジェクトに接続されている VLAN アタッチメントを持つプロジェクトは移行でき、組織間では機能しますが、組織スプリット後は新しい VLAN アタッチメントを作成することはできません。

CDN Interconnect オブジェクトに接続されている、または CDN Interconnect オブジェクトへの VLAN アタッチメントがある、特定の組織のプロジェクトに加えられた構成変更は、他の組織に反映されない場合があるため、可能であれば、そのようなプロジェクトを組織間で長期にわたり分割したままにしないことをお勧めします。

Assured Workloads

Assured Workloads プロジェクトを組織間で移行することはできません。移行しようにすると、プログラムによってブロックされます。

プロジェクト間のサービス アカウント

プロジェクト間のサービス アカウントが付加されているプロジェクトを移行する場合、そのサービス アカウントは移行先の組織でも引き続き機能します。そのプロジェクトのドメインを制限する組織ポリシーがある場合でも、そのプロジェクトは、不可されたサービス アカウントを使って引き続き動作します。

移行元組織の別のプロジェクトに付加されているプロジェクト間サービス アカウントを持つプロジェクトを移行する場合でも、サービス アカウントは移行先の組織で引き続き機能します。ただし、移行元組織のドメインに制限するドメイン制限の組織ポリシーが適用されているリソースでは、サービス アカウントを使用できません。

たとえば、organizations/12345678901project-A があるとします。このプロジェクトには serviceAccount-1 が関連付けられており、クロス プロジェクト サービス アカウントとして設定されています。project-Bproject-C は、organizations/12345678901 でも serviceAccount-1 を使用します。

ドメイン制限の制約を含む組織のポリシーを project-C に適用したため、organizations/12345678901. のドメインのみにアクセスが許可されます。

project-C の IAM バインディングに serviceAccount-1 を追加し、project-Aorganizations/45678901234 に移行すると、サービス アカウントが機能するようになります。

project-Aorganizations/45678901234 に移行し、serviceAccount-1project-C の IAM バインディングに追加しようとすると、バインディングがドメイン制限制約に違反するため、そのバインディングは失敗します。

サポート記録

未解決のサポート記録があるプロジェクトを移行する場合は、Google サポートに連絡して、移行が発生したことを通知する必要があります。Google で未解決のサポート記録があるプロジェクトでは、Google サポートがケース メタデータを新しい組織を指すように更新するまで、そのサポート記録は表示されません。