GCPのプロジェクトを別の組織に移行するときの注意点
はじめに
組織移行の影響を受けるサービスは、公式ドキュメントに載っています。
しかし、影響を受ける理由が分かりづらい & 影響を受けるサービスで載っていないものもあるため、補足できればと思います。
IAM 関係
組織移行において、最も注意するべきところがIAM関係です。プロジェクトを別の組織に移しても、IAM権限が正常に動作し続けるのか確認する必要があります。
具体的には、以下の観点で確認するといいと思います。
組織・フォルダレイヤーで設定したIAM権限
組織・フォルダレイヤーで設定したIAM権限を継承するプロジェクトを移行する場合、移行先組織では当然IAM権限が設定されていないために、権限エラーになります。
プロジェクトレイヤーで、IAM権限を付与してから移行するなどの工夫が必要です。
組織レイヤーで作成したカスタムロール
組織レイヤーで作成したカスタムロールは、その組織配下のプロジェクトのみで有効です。
移行先組織には、そのカスタムロールは当然存在しないため、エラーになります。
別プロジェクトのサービスアカウント
別プロジェクトで作成したサービスアカウントを使用していたとしても基本的に影響はありません。ただし、移行先組織にドメイン制限の組織ポリシーがある場合は、以降元組織で作成したサービスアカウントが使用できない可能性があります。
BigQueryのスケジュールドクエリ
ユーザーアカウントの権限で作成したBigQueryのスケジュールドクエリも注意が必要です。
組織移行に伴い、移行先組織からスケジュールドクエリを作成したユーザーアカウントが削除された場合、スケジュールドクエリは動かなくなります。
サービスアカウントで作り直すなどの対策が必要です。
LookerStudio
LookerStudioも、スケジュールドクエリと同様の理由で注意が必要です。
LookerStudioが、BigQueryなどのデータを参照するときは、LookerStudioのダッシュボードを作成したユーザーアカウントの権限を使用して参照します。
組織移行に伴い、移行先組織からダッシュボードを作成したユーザーアカウントが削除された場合、ダッシュボードにデータを表示できなくなるでしょう。
組織リソース 関係
組織レイヤーでのみ設定可能なサービスも、組織移行の影響を大きく受けます。特に、「組織ポリシー」「共有VPC」「VPC SC」の３つは、注意が必要です。
組織ポリシー
移行元・移行先組織で組織ポリシーが異なる場合、その影響を受けて、動かなくなるサービスが出てくる可能性があります。
共有VPC
共有VPCは、１つのVPCネットワークを、同じ組織内の複数プロジェクトで共有する機能です。
同じ組織という条件付きなので、プロジェクトが別組織に移行した場合、共有VPCは、当然機能しなくなります。
VPC SC
VPC SCは、組織レイヤーで設定するサービスです。そのためプロジェクトを移行した場合、移行先組織で同様のVPC SCを設定する必要があります。
Security Command Center
Security Command Centerは、組織レイヤーでのみ有効化可能なサービスです。セキュリティを重視して、移行元組織で有効にしている場合、移行先組織でも有効にすると良いでしょう。
ただ、移行先で有効にしなかったとしても、そこまで大きな影響は出ないでしょう。
その他
上記２項目ほどの影響度ではありませんが、組織移行の影響を受けるサービスです。
Dedicated Interconnect
Dedicated interconnect用プロジェクトとVLANアタッチメント用のプロジェクトは、別々の組織にあっても問題なく機能するようです。しかし、組織が別な場合は、新たにVLANアタッチメントを作成することができないようです。
「内部」のOauth画面
IAPなどで使用するOauth画面が「内部」になっている場合、組織内部のユーザーのみがリクエストを承認できます。
組織移行時に、「組織が変わったよー」と反映されるまで最大２４時間かかるため、移行時は「外部」にするといいでしょう。
透明性ログ
透明性ログは、組織レイヤーでのみ設定可能です。
移行先組織でも、引き続き透明性ログを確認するためには、有効化する必要があります。
最後に
プロジェクトの組織移行自体は、コマンド１つで完了できますが、影響度に関しては、意外と考慮することが多い印象です。
Discussion