特殊なケースを処理する

このトピックでは、プロジェクトの移行に関連する特殊なケースの処理について説明します。

組織リソースのないプロジェクトの移行

組織リソースに関連付けられていないプロジェクトは、他の組織リソースに移行できます。ただし、このプロセスを使用して [組織なし] に戻すことはできません。組織リソースに関連付けられたプロジェクトがあり、[組織なし] に戻す場合は、サポート担当者にお問い合わせください。

プロジェクトの親組織リソースに対する resourcemanager.organizations.get 権限がない場合、プロジェクトが想定された実際の組織のもとで反映されていない可能性があります。詳細については、ユーザーのプロジェクト公開設定の制限をご覧ください。

組織リソースに関連付けられていないプロジェクトを移行するプロセスは、組織リソース間でプロジェクトを移行するプロセスと類似していますが、移行計画にかかわるすべての手順が必要になるわけではありません。プロジェクトを組織リソースに移行するには、次の手順に沿って操作する必要があります。

継承されるポリシーがこのプロジェクトに与える影響を確認してください。
必要に応じて、移行先の組織リソースに専用のインポートフォルダを作成します。
権限を割り当てるで詳しく説明しているように、プロジェクトと宛先の親に 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
    }

ソースプロジェクトで OS Login が有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てる必要があります。

共有 VPC

共有 VPC プロジェクトは、次の特定の条件に従って移行できます。まず、ソース組織の roles/orgpolicy.policyAdmin ロールを持つユーザーは、エクスポート対象プロジェクトの親に対する constraints/resourcemanager.allowEnabledServicesForExport 制約を含む組織のポリシーを設定する必要があります。この制約により、SHARED_VPC は allowed_value として表示されるはずです。

移行前に共有 VPC を無効にする必要はありません。ただし、共有 VPC ホストプロジェクトを最初に移行してから、そのサービスプロジェクトのすべてを移行する必要があります。ソースとターゲットの場所にある組織リソース間でファイアウォールルールを一致させることをお勧めします。これにより、潜在的な問題を最小限に抑え、移行中のプロジェクトとネットワークのダウンタイムを回避できます。一部のサービスプロジェクトをソース組織に無期限に残し、他のプロジェクトを移行した場合、ネットワークの健全性は保証されません。

ホストプロジェクトを移行する場合は、移行元の組織リソースに戻すことができます。ホストプロジェクトとサービスプロジェクトが異なる組織に存在できる期限は厳密に決まっていません。ただし、サービスプロジェクトの移行を開始する場合は、ホストプロジェクトが再び移行できるようになる前に、すべてのプロジェクトを移行する必要があります。

Identity and Access Management のカスタムロール

Identity and Access Management のカスタムロールを組織レベルで作成して、リソースへのアクセス権をきめ細かく管理できますが、これはそのロールを作成した組織リソース内でのみ有効です。ユーザーの IAM ポリシーバインディングを含むプロジェクトを組織レベルのカスタム IAM ロールに移行しようとすると、移行に失敗します。失敗は、前提条件でのエラーによるもので、移行先の組織リソースに対象のロールが存在しないことが説明されます。

組織リソースレベルですべてのカスタム IAM ロールを一覧表示するには、次の Google Cloud CLI のコマンドを実行します。

gcloud iam roles list --organization ORGANIZATION_ID

ORGANIZATION_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 ロールバインディングを削除します。

プロジェクトの移行後、IAM ポリシーを更新して、移行先組織リソースで組織レベルのカスタムロールを使用できます。

カスタムロールの詳細については、カスタムロールの作成と管理をご覧ください。

バケットロック

Cloud Storage のバケットロックを使用すると、Cloud Storage バケットのデータ保持ポリシーを構成して、バケット内のオブジェクトを保持する期間を管理できます。バケットロックは、リーエンを使用して保護され、プロジェクトが誤って削除されるのを防止します。

保持ポリシーとリーエンは移行中もプロジェクトに保持されますが、バケットロックが適用されているプロジェクトを移行する場合は、誤って移行しないように注意してください。

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

VPC Service Controls を使用すると、Google Cloud サービスにプロジェクトベースのセキュリティ境界を設定して、データの引き出しのリスクを軽減できます。VPC Service Controls のセキュリティ境界で保護されているプロジェクトは移行できません。

セキュリティ境界からプロジェクトを削除するには、サービス境界の管理をご覧ください。VPC Service Controls の境界内のプロジェクトは、組織リソース間での移行がブロックされないようにする必要があります。このガイドラインは、境界の作成または更新後、最長で 1 日間適用されます。サービス境界から削除されてからプロジェクトが移行されるまでに数時間かかることがあります。

Dedicated Interconnect

Dedicated Interconnect オブジェクトを使用するプロジェクトと VLAN アタッチメントを使用するプロジェクトを一緒に移行することをおすすめします。Dedicated Interconnect オブジェクトを使用する、またはプロジェクトに接続されている VLAN アタッチメントを持つプロジェクトは、組織リソース間の移行後も引き続き機能します。唯一の制限事項は、組織リソース分割間で新しい VLAN アタッチメントを作成できないことです。

Dedicated Interconnect オブジェクトに接続されている、またはこのオブジェクトへの VLAN アタッチメントがある、特定の組織リソースのプロジェクトに加えられた構成変更は、他の組織リソースに伝播されない可能性があります。そのようなプロジェクトは、できる限り組織リソース間で分割しないことをおすすめします。

Partner Interconnect

Partner Interconnect を使用してプロジェクトを移行する場合、特別な考慮事項はありません。

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

プロジェクト間のサービスアカウントの移行のコンテキストでは、次の場合が適用されます。

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

たとえば、organizations/12345678901 に project-A があるとします。このプロジェクトには serviceAccount-1 が接続されており、プロジェクト間サービスアカウントとして設定されています。project-B と project-C も organizations/12345678901 にあるため、同様に serviceAccount-1 を使用します。

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

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

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

サポートケース

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

OAuth 同意画面

内部 OAuth 同意画面を使用するようにプロジェクトを構成し、画面を別の組織リソースに移行した場合は、移管先組織リソースのメンバーのみがリクエストを承認できます。この動作が有効になるまでに、最大で 24 時間を要する場合があります。それまでは、移行元の組織リソースのメンバーがリクエストを承認できます。

以下の手順では、移行元組織リソースのメンバーが移行中にアクセス権を失うことがないようにする方法を説明します。OAuth 同意画面の構成を変更する必要がないよう、組織リソースメンバーの移行先の組織リソースに新しいユーザーを作成することを検討してください。

移行元組織リソース内のユーザーがアクセス権を失うことを回避するには:

OAuth 同意画面の設定を内部設定ではなく外部設定に更新します。
内部としてマーク付けされ、機密データを使用しているアプリは、アプリの確認を申請する必要はありません。アプリが機密データを使用している場合、同意画面が外部に更新されると、移行元組織リソースのユーザーには、認証画面の前に未確認アプリ画面が表示されます。これを回避するには、機密性の高いスコープまたは制限されたスコープの使用に対してアプリの確認を申請します。

OS ログイン

ソースプロジェクトで OS Login が有効になっている場合は、そのプロジェクトにアクセスできるプリンシパルに roles/compute.osLoginExternalUser ロールを割り当てる必要があります。これにより、プリンシパルが移行先の組織リソースでアクセス権を失いません。

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

共有予約では、予約を作成したプロジェクト（オーナープロジェクト）または（コンシューマプロジェクト）で予約を共有するプロジェクトで、VM インスタンスを作成して予約を使用できます。予約は、オーナープロジェクトと同じ組織内のプロジェクトとのみ共有できます。

オーナープロジェクトまたはコンシューマプロジェクトを別の組織に移行すると、次のようになります。

オーナープロジェクトを別の組織に移行すると、Compute Engine はオーナープロジェクトによって作成された予約を削除します。実行中の VM インスタンスに影響はありません。
コンシューマプロジェクトを別の組織に移行すると、コンシューマプロジェクトは前の組織の共有予約のリソースの使用を停止します。

詳細については、共有予約の仕組みをご覧ください。

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

ほとんどの Google Cloud サービスでは、サービスアカウントをリソースに関連付けるには、ユーザーにサービスアカウントに対する iam.serviceAccounts.actAs 権限が必要です。ただし、以前には、特定のサービスのオンボーディングを簡易にする目的で、ユーザーがサービスアカウントの権限借用をする権限を持たない場合であっても、ユーザーがサービスアカウントをリソースに関連付けることを許可していました。これについては、サービスアカウントをリソースに関連付ける権限を要求するに記載されています。

お客様の移行元の組織リソースに従来の動作があり（通常のロール付与がなくてもサービスアカウントの関連付けが可能）、移行先の組織リソースにそれらの動作がない場合は、これらのサービスアカウントをリソースに関連付けるユーザーに対して、サービスアカウントユーザーのロール（roles/iam.serviceAccountUser ）を付与します。サービスアカウントをリソースに関連付けるために必要な権限については、サービスアカウントの認証のロールをご覧ください。

組織リソースで従来の挙動があるかどうかを確認するには、次のとおりにします。

Google Cloud コンソールで、[組織のポリシー] ページに移動します。

[組織のポリシー] ページに移動
ページの上部にあるプロジェクトセレクタから、以前の状態であるかを確認する組織リソースを選択します。
組織のポリシーリストの上部にあるフィルタボックスに、「constraints/appengine.enforceServiceAccountActAsCheck」と入力します。
appengine.enforceServiceAccountActAsCheck 組織ポリシーがリストに表示されている場合、組織リソースには以前の動作が存在します。
次の組織のポリシーの制約ごとに、ステップ 3 と 4 を繰り返します。
- appengine.enforceServiceAccountActAsCheck
- dataflow.enforceComputeDefaultServiceAccountCheck
- dataproc.enforceComputeDefaultServiceAccountCheck
- composer.enforceServiceAccountActAsCheck
これらの組織ポリシーの制約のいずれかが表示された場合は、組織リソースでレガシー動作を使用します。

移行元の組織リソースに以前の動作があり、移行先に同じ動作がない場合は、上に記載したロールを付与します。移行元と移行先の組織リソースにすでに従来の動作がある場合は、何も操作する必要はありませんが、意図しないなりすましを回避するため、ポリシーの適用を検討してください。

Analytics Hub を使用したプロジェクトの移行

Analytics Hub を使用しているプロジェクトを別の組織リソースに移行すると、エラーが発生する可能性があります。エラーを解決するには、サポートにお問い合わせください。

バックアップと DR サービスを使用したプロジェクトの移行

プロジェクトを別の組織リソースに移行する前に、バックアップと DR サービスを無効にする必要があります。サービスが無効になると、停止リスクを考慮する必要があります。新しい組織リソースへの移行が完了したら、バックアップと DR サービスを再度有効にする必要があります。

次のステップ

移行方法については、移行を実行するをご覧ください。