6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【Google Cloud】組織なしプロジェクトを組織へ移行

Last updated at Posted at 2022-06-30

組織なしプロジェクトを組織へ移行

Google Cloud の組織なしのプロジェクトを、組織配下へ移行しました。
その時に確認したことや、実際の手順などをまとめます。

移行前の状態

Google Cloud の技術検証用に使われているプロジェクトが、組織なしとして作成されています。
Google Cloud サポートに契約し、この検証用プロジェクトをサポート対象とするために、検証用プロジェクトを Google Workspace で作られた組織配下へ移行する必要が出てきました。
また、検証用プロジェクトを使っているユーザーは Google Workspace で管理されているユーザーアカウントで検証用プロジェクトにアクセスしています。

移行準備

公式ドキュメントを参考に、移行の準備を行いました。

ポリシーの確認

ポリシーの考え方については、 以下のブログを参考にさせていただきました。
ユーザーとロールを紐づけるバインディングをまとめたものがポリシーとのことです。

組織のポリシー

公式ドキュメントには、下記の記載がありました。

プロジェクトを移行すると、リソース階層内の現在の場所からポリシーが継承されなくなり、移行先の有効なポリシー評価の対象となります。プロジェクトの移行先の有効なポリシーが、そのプロジェクトの元の場所にあるポリシーとできる限り一致するようにすることをおすすめします。

プロジェクトに直接適用されるポリシーは、移行の完了後も引き続きアタッチされます。移動が完了した時点から適切なポリシーが適用されていることを確認するには、プロジェクトに直接ポリシーを適用するのが最適な方法です。

今回は組織なしのプロジェクトの移行なので、基本的には「プロジェクトに直接適用されるポリシー」のみ、と判断しました。
念のため移行するプロジェクトの「組織のポリシー」を確認し、意図的に変更してそうな箇所がないか確認しました。
(各ポリシーがすべて「継承」になっていました。)

IAM

個々のユーザーやサービスアカウントのポリシーは、前述のブログを参考に、gcloud projects get-iam-policy コマンドを使って移行前のバックアップを取得しました。

Cloud Asset API による分析(失敗)

公式ドキュメントより、Cloud Asset API を使えばプロジェクト移動による影響を確認できるとのことだったので、実際にやってみました。

すると、指定するプロジェクトが組織に属していないエラーが発生し、失敗しました。
このAPIは、今回のケースでは使えませんでした。

ERROR: (gcloud.asset.analyze-move) INVALID_ARGUMENT: field [resource] has issue [The input resource projects/<プロジェクトID> does not belong to an Organization.]
- '@type': type.googleapis.com/google.rpc.BadRequest
  fieldViolations:
  - description: The input resource projects/<プロジェクトID> does not belong to
      an Organization.
    field: resource

移行に必要な権限の追加

移行を実施するユーザーに、移行に必要な権限を追加しました。

もともと、移行を実施するユーザーには、

  • 移行するプロジェクトの「オーナー」
  • 移行先の組織の「組織の管理者」

の二つのロールを付与していました。
今回の移行のために四つのロールを追加しました。

  • 移行するプロジェクトの「Project IAM 管理者」
  • 移行するプロジェクトの「プロジェクト移動」
  • 移行先の組織の「組織の管理者」
  • 移行先の組織の「請求先アカウント作成者」

なお、最後の「請求先アカウント作成者」は後述の請求先アカウントの組織変更のために必要なロールなため、プロジェクトの移行のみであれば追加する必要はありません。

移行手順

プロジェクトの移行

移行するプロジェクトの「IAMと管理」→「設定」を開き、画面上部の「移行」ボタンを押します。

IAMの設定.PNG

移行先組織をプルダウンから選択し、右下の「移行」ボタンを押せば移行完了です。

移行ボタン押下後.PNG

移行後、gcloud projects get-iam-policy コマンドでポリシーの状態を確認しましたが、移行前と変わりはありませんでした。

請求先アカウントの組織への紐づけ

移行したプロジェクトで使っていた請求先アカウントも組織へ紐づけました。

「お支払い」を開き、左上の「請求先アカウント」を移行するアカウントに設定し、「アカウント管理」を開きます。
画面上部の「組織を変更」ボタンを押します。

お支払いのアカウント管理.PNG

移行先組織をプルダウンから選択します。
「請求先アカウント作成者」ロールがないと画像のように権限不足のエラーが発生します。

請求書アカウント_組織変更できない.PNG

【余談1】グループの管理

Google Cloud のベストプラクティスの一つに、同じ役割のユーザーをグループにまとめ、グループに対して権限を割り当てる、というものがあります。

このドキュメントだと、グループの作成と管理へのリンクが Google Admin (Google Workspace の管理ページ)になっており、
Google Workspace の管理権限を持っていないと作成できないと思っていましたが、
実は Google Workspace のグループと Google Cloud のグループは同期されており、Google Cloud 側でもグループの作成や管理をすることができました。

注意点としては、IAMの追加時にプリンシパルの候補に出てこない場合があります。
候補に出てこないので追加できないように見えますが、グループのメールアドレスを入力すれば追加できます。

【余談2】組織ドメインのユーザーで組織なしのプロジェクトは作れない

実際の移行の前にテストしようと思い、組織なしのプロジェクトを作ろうとしましたが、組織ドメインに属しているユーザーでは「組織なし」プロジェクトを作れませんでした。
なので、以下のブログを参考に、組織ドメインに属していないユーザーでプロジェクトを作成し、組織ドメインのユーザーを追加する、という方法でテスト用プロジェクトを作成しました。

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?