Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

特殊なケースを処理する

プロジェクトを移行する際の特殊なケースの処理方法について説明します。プロジェクトを移行する前に、プロジェクト、その親リソース、移行先リソースに必要な 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 リソースが表示されない場合、プロジェクトが組織リソースに関連付けられていないことが確認できます。

出力に 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 に設定します。
project オブジェクトを projects.update() メソッドを使用して更新します。

設定した 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 に移行し、project-C の IAM バインディングに serviceAccount-1 を追加しようとすると、バインディングがドメイン制限制約に違反するため、そのバインディングは失敗します。

サポートケース

未解決のサポート記録があるプロジェクトを移行する場合は、移行後に 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.enforceServiceAccountActAsCheck
- dataflow.enforceComputeDefaultServiceAccountCheck
- dataproc.enforceComputeDefaultServiceAccountCheck
- composer.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 プールとそのプロバイダがプロジェクトとともに移行されます。これらのプールを使用するワークロードのアクセス権を維持するために追加の操作は必要ありません。

継承された Privileged Access Manager の権限付与を使用してプロジェクトを移行する

プロジェクトを移行する前に、そのプロジェクトに対する有効なスコープ付き権限付与を取り消すことをおすすめします。スコープ付き権限付与は、フォルダまたは組織から継承されたエンタイトルメントで作成され、子プロジェクトにスコープ設定されます。

有効なスコープ付き権限付与を含むプロジェクトを移行すると、IAM ポリシーは新しい組織に移動しますが、それを管理する権限付与は前の組織に残ります。Privileged Access Manager サービスエージェントは、新しい組織で IAM ポリシーを変更する権限を失います。その結果、その権限付与に対する取り消しまたは取り下げオペレーションは失敗し、リクエスタは権限付与の有効期限が切れるまでアクセス権を保持します。

次のステップ

移行を実行する

特殊なケースを処理する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

組織リソースに関連付けられていないプロジェクトを移行する

gcloud

コンソール

gcloud

API

共有 VPC

カスタムの IAM の役割

バケットロック

VPC Service Controls のセキュリティ境界

サービス アカウントのコンテキストアウェア アクセス ポリシー

Dedicated Interconnect

Partner Interconnect

管理プロジェクト

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

サポートケース

OAuth 同意画面

Cloud OS Login API

仮想マシン（VM）インスタンスの共有予約

サービス アカウントとリソースの関連付け

BigQuery Sharing を使用してプロジェクトを移行する

Backup and DR サービス

Workload Identity 連携

タグ

継承された Privileged Access Manager の権限付与を使用してプロジェクトを移行する

次のステップ

特殊なケースを処理する

サービスアカウントのコンテキストアウェアアクセスポリシー

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

サービスアカウントとリソースの関連付け