Google Cloud プロジェクトを組織間で移行する場合、一部のリソースと構成では、サービスの継続性を維持し、構成の競合を防ぐために追加の手順が必要になります。これらの特殊なケースには、組織リソースのないプロジェクト、共有 VPC リソース、カスタムロール、プロジェクト間のサービス アカウントなどがあります。プロジェクトを移行する前に、プロジェクト、その親リソース、宛先リソースに対して必要な Identity and Access Management（IAM）権限があることを確認してください。
組織リソースに関連付けられていないプロジェクトを移行する
関連する組織リソースなしで作成されたプロジェクトを、組織リソースの階層に移行できます。ただし、このプロセスを元に戻すことはできません。プロジェクトを [組織なし] に戻すには、Cloud カスタマーケアにお問い合わせください。
組織リソースに関連付けられていないプロジェクトを移行するには、プロジェクトに対する roles/resourcemanager.projectIamAdmin ロールが必要です。また、移行先の組織リソースに対する roles/resourcemanager.projectCreator ロールも必要です。
親組織リソースに対する resourcemanager.organizations.get 権限がない場合、 Google Cloud コンソールの組織にプロジェクトが想定どおりに表示されないことがあります。これにより、プロジェクトが組織リソースに関連付けられていないように見えることがあります。詳細については、ユーザーのプロジェクト公開設定の制限をご覧ください。
プロジェクトが組織リソースに関連付けられているかどうかを確認するには、次の操作を行います。
gcloud
次のコマンドを実行します。
gcloud projects describe PROJECT_ID
PROJECT_ID は、移行するプロジェクトの ID に置き換えます。
出力に parent リソースが表示されない場合は、プロジェクトが組織リソースに関連付けられていないことを確認します。
出力に親リソース（フォルダまたは組織リソース）が表示されている場合は、プロジェクトが組織リソースに関連付けられていることを確認します。
組織リソースに関連付けられていないプロジェクトを移行するプロセスは、組織リソース間でプロジェクトを移行するプロセスと類似していますが、移行計画にかかわるすべての手順が必要になるわけではありません。プロジェクトを組織リソースに移行するには、次の手順に沿って操作します。
継承されるポリシーがこのプロジェクトに与える影響を確認してください。
必要に応じて、移行先の組織リソースに専用のインポート フォルダを作成します。
権限を割り当てるで詳しく説明しているように、プロジェクトと宛先の親リソースに Identity and Access Management の権限を割り当てます。
請求先アカウントを変更する必要があるかどうかを確認します。
その後、次のいずれかの方法で移行を実行できます。
コンソール
Google Cloud コンソールで [IAM と管理] > [設定] ページを開きます。
プロジェクト選択ツールを使用して、プロジェクト（[組織なし] のプロジェクト）を選択します。
[設定] ページの上部にある [移行] をクリックします。
表示されたダイアログで、プロジェクトの移行先となる組織リソースを選択し、[移行] をクリックします。
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
}
ソース プロジェクトで Cloud OS Login API が有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てます。
共有 VPC
共有 VPC プロジェクトは、特定の条件に従って移行できます。まず、ソース組織の roles/orgpolicy.policyAdmin ロールを持つユーザーは、エクスポート対象プロジェクトの親に対する constraints/resourcemanager.allowEnabledServicesForExport 制約を含む組織のポリシーを設定する必要があります。この制約により、SHARED_VPC は allowed_value として表示されるはずです。
移行前に共有 VPC を無効にする必要はありません。ただし、共有 VPC ホスト プロジェクトを最初に移行してから、そのサービス プロジェクトのすべてを移行する必要があります。潜在的な問題を最小限に抑え、ダウンタイムを回避するために、ソースとターゲットの組織リソース間でファイアウォール ルールを一致させることをおすすめします。一部のサービス プロジェクトを移行元組織リソースに残し、他のプロジェクトを移行した場合、ネットワークの健全性は保証されません。
ホスト プロジェクトを移行すると、移行元の組織リソースに戻すことができます。ホスト プロジェクトとサービス プロジェクトが異なる組織に存在できる期限は厳密に決まっていません。ただし、サービス プロジェクトの移行を開始する場合は、ホスト プロジェクトが再び移行できるようになる前に、すべてのプロジェクトを移行する必要があります。
カスタムの IAM の役割
Identity and Access Management のカスタムロールを使用すると、組織リソースレベルでリソースへのアクセスをきめ細かく制御できますが、これはそのロールを作成した組織リソース内でのみ有効です。組織レベルのカスタム IAM ロールへの許可ポリシー バインディングを含むプロジェクトを移行すると、移行は失敗します。このエラーは、移行先の組織リソースにロールが存在しないことを示しています。
組織リソース内のすべてのカスタム IAM ロールを一覧表示するには、次のコマンドを実行します。
gcloud iam roles list --organization ORGANIZATION_ID
ORGANIZATION_ID は、組織リソースの ID に置き換えます。詳細については、組織リソース ID を取得するをご覧ください。
組織リソース内のカスタムの Identity and Access Management ロールに関する情報を取得するには、次のコマンドを実行します。
gcloud iam roles describe --organization ORGANIZATION_ID \
ROLE_ID
次のように置き換えます。
- ORGANIZATION_ID: 組織リソースの ID
- ROLE_ID: 説明を取得するロールの名前
このエラーを回避するには、継承された組織レベルのカスタムロールごとに、同等のプロジェクト レベルのカスタムロールを作成します。次に、組織レベルのカスタムロールを参照する IAM ロール バインディングを削除します。
プロジェクトの移行後、許可ポリシーを更新して、移行先組織リソースで組織レベルのカスタムロールを使用できます。
詳しくは、カスタムロールの作成と管理をご覧ください。
バケットロック
Cloud Storage バケットロックを使用すると、Cloud Storage バケットにデータ保持ポリシーを構成できます。このポリシーは、オブジェクトを保持する期間を制御します。バケットロックは、リーエンを使用して保護され、プロジェクトが誤って削除されるのを防止します。
保持ポリシーとリーエンは移行中もプロジェクトに保持されます。リーエンによってプロジェクトの移行が妨げられることはありません。
VPC Service Controls のセキュリティ境界
VPC Service Controls は、Google Cloud サービスの周囲にプロジェクト ベースのセキュリティ境界を設定することで、データ漏洩のリスクを軽減します。VPC Service Controls のセキュリティ境界で保護されているプロジェクトは移行できません。
セキュリティ境界からプロジェクトを削除するには、サービス境界の管理をご覧ください。サービス境界からプロジェクトを削除してから移行するまでに、数時間から 1 日かかることがあります。
サービス アカウントのコンテキストアウェア アクセス ポリシー
コンテキストアウェア アクセスを使用すると、ネットワーク、ロケーション、時間などのコンテキスト属性に基づいて、サービス アカウントの Google Cloud リソースにアクセス ポリシーを定義できます。サービス アカウントに少なくとも 1 つのコンテキストアウェア アクセス ポリシーが設定されているプロジェクトは移行できません。
サービス アカウントのコンテキストアウェア アクセス ポリシーを削除するには、アクセス バインディングの管理をご覧ください。
ポリシーを作成または削除する際は、次のタイミングに関する考慮事項に注意してください。
- ポリシーの作成: 新しく作成されたコンテキストアウェア アクセス ポリシーでは、移行がすぐにブロックされない場合があります。この伝播遅延は、ポリシーの作成後最大 24 時間続くことがあります。
- ポリシーの削除: すべてのコンテキストアウェア アクセス ポリシーがプロジェクトから削除された後、プロジェクトを移行できるようになるまでに数時間かかることがあります。
Dedicated Interconnect
Dedicated Interconnect オブジェクトを使用するプロジェクトと VLAN アタッチメントを使用するプロジェクトを一緒に移行することをおすすめします。これらのオブジェクトを持つプロジェクトは、組織リソース間の移行後も引き続き機能します。ただし、組織リソースが分割されている間は、組織リソース間に新しい VLAN アタッチメントを作成することはできません。
分割プロジェクトに加えられた構成変更は、組織リソース全体に反映されない場合があります。プロジェクトを分割したままにしないことをおすすめします。
Partner Interconnect
Partner Interconnect を使用してプロジェクトを移行する際の特別な考慮事項はありません。Partner Interconnect を使用してプロジェクトを移行する場合、特別な考慮事項はありません。
管理プロジェクト
管理プロジェクトは、アプリ対応フォルダ内の Google Cloud プロジェクトで、アプリケーション中心のすべてのメタデータの中央リポジトリとして機能します。各アプリ対応フォルダには、管理プロジェクトが 1 つだけ含まれています。管理プロジェクトは、アプリケーション ライブラリと API のインフラストラクチャを提供します。これには、課金、割り当て、アクセス制御が含まれます。管理プロジェクトを移行することはできません。
プロジェクト間のサービス アカウント
プロジェクト間のサービス アカウントを移行する場合は、次のケースが適用されます。
- プロジェクト間のサービス アカウントが付加されているプロジェクトを移行する場合、そのサービス アカウントは移行先の組織リソースで引き続き機能します。これは、組織のポリシーでドメインが制限されている場合でも適用されます。
- 別のプロジェクトで使用されているプロジェクト間サービス アカウントを所有するプロジェクトを移行する場合、サービス アカウントは引き続き機能します。ただし、移行元組織リソースのドメインに制限するドメイン制限の組織ポリシーが適用されているリソースでは、サービス アカウントを使用できません。
たとえば、organizations/12345678901 の project-A に serviceAccount-1 がアタッチされているとします。同じ組織内の project-B と project-C も serviceAccount-1 を使用します。
project-C には、organizations/12345678901 ドメインのみを許可する組織のポリシーがあります。
project-A を organizations/45678901234 に移行する前に、project-C の IAM バインディングに serviceAccount-1 を追加すると、サービス アカウントが機能します。
project-A を organizations/45678901234 に移行し、serviceAccount-1 を project-C の IAM バインディングに追加しようとすると、バインディングがドメイン制限に違反するため、そのバインディングは失敗します。
サポートケース
未解決のサポートケースがあるプロジェクトを移行する場合は、移行後に Cloud カスタマーケアに通知してください。Cloud カスタマーケアがメタデータを新しい組織リソースに更新するまで、これらのサポートケースは表示できません。
OAuth 同意画面
プロジェクトで内部 OAuth 同意画面を使用している場合、移行後にリクエストを承認できるのは、移行先組織リソースのメンバーのみです。この変更が有効になるまで、24 時間程度かかる場合があります。それまでは、移行元の組織リソースのメンバーがリクエストを承認できます。
移行元のメンバーがアクセス権を失わないようにするには、移行先の組織リソースに新しいユーザーを作成するか、OAuth 同意画面の構成を更新することを検討してください。
OAuth 同意画面の設定を内部設定ではなく外部設定に更新します。
アプリが機密データを使用する場合は、機密性の高いスコープまたは制限付きスコープに対してアプリの確認を申請します。この手続きを行わないと、ユーザーには [未確認のアプリ] 画面が表示されます。
Cloud OS Login API
ソース プロジェクトで Cloud OS Login API が有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てます。これにより、プリンシパルが移行先の組織リソースでアクセス権を失いません。
仮想マシン（VM）インスタンスの共有予約
共有予約では、予約を作成したプロジェクト（オーナー プロジェクト）または予約を共有するプロジェクト（コンシューマ プロジェクト）で、VM インスタンスを作成して予約を使用できます。予約を共有できるのは、オーナー プロジェクトと同じ組織内のプロジェクトのみです。
オーナー プロジェクトまたはコンシューマ プロジェクトを移行すると、次のようになります。
- オーナー プロジェクトを移行すると、そのプロジェクトによって作成された予約は Compute Engine によってすべて削除されます。実行中の VM インスタンスは影響を受けません。
- コンシューマー プロジェクトを移行すると、移行前の組織の共有予約からのリソースを消費しなくなります。
詳細については、共有予約の仕組みをご覧ください。
サービス アカウントとリソースの関連付け
ほとんどの Google Cloud サービスでは、サービス アカウントをリソースに関連付けるには、iam.serviceAccounts.actAs 権限が必要です。ただし、一部のサービスでは、明示的な権限借用の権限がなくても、これまでこの操作が許可されていました。これについては、サービス アカウントをリソースに関連付けるための権限を要求するをご覧ください。
移行元の組織リソースにこの従来の動作があり、移行先にはない場合は、これらのサービス アカウントを関連付けるユーザーに roles/iam.serviceAccountUser ロールを付与します。権限の詳細については、サービス アカウントの認証に必要なロールをご覧ください。
組織リソースで従来の挙動があるかどうかを確認するには:
Google Cloud コンソールで、[組織のポリシー] ページに移動します。
リソース セレクタで、確認する組織リソースを選択します。
フィルタ ボックスに「
constraints/appengine.enforceServiceAccountActAsCheck」と入力します。ポリシーが表示された場合、組織リソースには以前の動作が存在します。
次の制約ごとに、ステップ 3 と 4 を繰り返します。
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
これらの制約のいずれかが表示された場合は、組織リソースでレガシー動作を使用します。両方の組織リソースが従来の動作を使用している場合は、何も操作する必要はありませんが、意図しないなりすましを回避するため、ポリシーの適用を検討してください。
BigQuery Sharing を使用したプロジェクトの移行
BigQuery Sharing を使用するプロジェクトを別の組織リソースに移行すると、エラーが発生することがあります。解決するには、Cloud カスタマーケアにお問い合わせください。
以前の組織のデータ エクスチェンジ リソースが新しい組織の Sharing 管理者ページに表示されない場合は、BigQuery Sharing 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: プロジェクトの固有識別子
- LOCATION: データ エクスチェンジのロケーション
- DATA_EXCHANGE_ID: データ エクスチェンジの ID
- UPDATE_DX_FIELD: 更新するフィールド（
descriptionなど） - UPDATE_DX_VALUE: 更新された値
Backup and DR サービス
プロジェクトを別の組織リソースに移行する前に、Backup and DR を無効にします。サービスが無効になっている場合のサービス停止のリスクを考慮します。移行が完了したら、Backup and DR を再度有効にします。
Workload Identity 連携
Workload Identity 連携を使用すると、オンプレミスまたはマルチクラウドのワークロードに Google Cloud リソースへのアクセス権を付与できます。Workload Identity 連携プールは、プロジェクト スコープのリソースです。
プロジェクトを移行すると、そのプロジェクト内で構成された Workload Identity プールとそのプロバイダがプロジェクトとともに移行されます。これらのプールを使用するワークロードへのアクセスを維持するために、追加の操作は必要ありません。
タグ
タグは、リソースに関連付けられた Key-Value ペアです。組織レベルで作成されたタグは移行されません。
プロジェクトでポリシー バインディングまたは制約に組織レベルのタグを使用している場合は、移行先の組織リソースでタグキーとタグ値を再作成し、移行されたプロジェクトに再アタッチする必要があります。
Privileged Access Manager の権限付与を継承したプロジェクトの移行
プロジェクトを移行する前に、そのプロジェクトで有効なスコープ付き権限を取り消すことをおすすめします。スコープ付き権限付与は、フォルダまたは組織から継承された利用資格に作成され、子プロジェクトにスコープされます。
有効なスコープ付き権限付与を含むプロジェクトを移行すると、IAM ポリシーは新しい組織に移動しますが、それを管理する権限付与は以前の組織に残ります。Privileged Access Manager サービス エージェントは、新しい組織の IAM ポリシーを変更する権限を失います。その結果、その権限付与に対する取り消しオペレーションは失敗し、リクエスト元は権限付与が期限切れになるまでアクセス権を保持します。