【GoogleCloud】組織の作成および既存プロジェクトの組織への移動方法

こんにちは。SCSKの松渕です。

検証環境の Google Cloud に組織ポリシー適用しようとしたら、がそもそも組織に所属していなかった。
じゃぁ組織に所属させようと思ったら、以外と面倒くさかった　ってこと、皆さんもありますよね？

ということで、Google Cloud の組織作成方法と、プロジェクトの移動方法を紹介します。

組織とフォルダとプロジェクトとは？
作業
まとめ

組織とフォルダとプロジェクトとは？

GoogleCloud公式ドキュメント　リソース階層
上記に記載の通り、
組織 – フォルダ – プロジェクト　という関係です。
今回は、組織に所属していないプロジェクトから、組織を新規作成してプロジェクトから移動させます。

現状

プロジェクトA
※主にドメインAのユーザにて利用

移行後イメージ

組織B(ドメインB) – プロジェクトA

作業

Step1：ドメイン取得（ドメインB）

Google Cloud の組織リソースは、Google Workspace (旧 G Suite) または Cloud Identity のお客様に自動的にプロビジョニングされます。これらのサービスは、独自ドメインに紐付けられます。今回は、ドメインを取得するところから実施します。

Cloud Domains でのドメイン取得

今回は Google CloudのサービスであるCloud Domains を利用してドメイン取得いたします。
既存のプロジェクト（プロジェクトA）にログインして操作します。
Cloud Domains 画面に遷移して、「ドメインの登録」を押下すると以下の画面になります。

任意のドメイン名を入力すると、利用可能なドメインが複数表示されます。
トップレベルドメイン（.com, .org など）も複数選択肢あるようです。
年間12$かかります。GoogleCloudの利用料金とまとめて請求されます。

Cloud Domains を使用しているため、Cloud DNS で管理します。
もちろん、お名前.com等でドメインを発行し、ネームサーバーもそちらで管理するといった対応も可能です。
その場合の今後の手順も大きくは変わりません。

WHOIS情報のプライバシー保護については、Google推奨の通り制限いたします。
これにより、不要な個人情報公開を防ぎます。

各種連絡先を記載して登録します。
記載したメールアドレスにSquarespaceからメールアドレスの検証が届きます。
メールアドレスの検証完了したら、ドメインがアクティブになります。

ドメインとDNS確認

Cloud Domains 画面で取得したドメインがアクティブであることを確認します。

Cloud DNS 画面にも表示されます。

Step2：組織の作成（組織B）

ドメインの準備が終わったので、組織の作成をします。

Cloud Identityの作成

IAMと管理 – IDと組織の画面へ遷移します。

上記の画面が出るため、「チェックリストに移動」を押下します。

ワークロードを選択します。今回は概念実証を選択しました。

上記の画面に遷移しますので、「設定を開始する」を選択します。

「初めて利用する」を選んで、「CLOUD IDENTITYに申し込む」を選択します。

おそらく別ウィンドウで、各種情報入力が出てくるかと思います。
私は検証用でしたので適当な会社名と人数で次に進みます。

連絡先入力画面も入力して次に進みます。

ドメイン名についてはSTEP1で作成したドメイン名を入力します。

確認画面が出てきます。ドメイン名が間違っていないことを確認して次へ進みます。

Google Workspace のユーザー（管理者ユーザー）を作成する画面になります。
適切に入力し「同意して続行」を押下します。

ドメインの所有権の証明

以下のような画面になるかと思います。
入力したドメインの所有権を証明する必要があるという画面ですね。

「始める」を押下します。

ドメインのホスト（DNSサーバの所有者）を選択できます。が、GoogleCloudやCloudDomainsは存在しません。
ドメインで別のホストを使用しているを選択して続行します。

TXTレコードとCNAMEレコードが表示されます。このTXTレコードもしくはCNAMEを設定することで証明になります。
この方式は“ドメインのDNS設定を変更できるのは、そのドメインの正当な所有者だけである”という考え方に基づいています。
GoogleCloudが発行したユニークな識別子をTXTレコードに設定することで証明、という考え方です。
TXTとCNAMEどちらでも問題ないですが、今回は一般的なTXTレコードを設定します。

先ほどの画面は一旦そのままGoogleCloudに戻って、
CloudDNSの画面に移動して、「標準を追加します」を選択します。

TXTタイプを選択して、TXTデータに先ほど表示された値を入力して作成します。

レコード作成後、Google Workspace の画面に戻ります。
画面下部のチェックを入れて「確認」を押下します。

待機画面後、「所有者の確認が完了しました」と表示されます。

ユーザ切り替え

再度、GoogleCloudコンソールに戻ります。

先ほど作成した新ドメインの管理者ユーザでのログインを行います。

私の場合、上記エラーが出ました。ブラウザ一度ログオフして再度GoogleCloudにログインしたら解消しました。

うまく切り替えできたら上記画面が出ます。

ユーザー切り替えができて、組織の画面で上記が表示されたらOKです。
なお、新ドメインのユーザーは「組織B」の権限はあるが、「プロジェクトA」の権限はない状態になっております。

Step3：組織への移動

移動の準備が整ったので、プロジェクトAを組織Bに移動します。

基本的には以下ドキュメントの通りですが、組織ポリシー関連で注意点があります。
GoogleCloud公式ドキュメント　特殊なケースを処理する

一度やってみる

このブログの一番伝えたい部分なので、失敗ケースをお見せします。
ドキュメントでは以下のように記載されています。

移行先の組織リソースに roles/resourcemanager.projectCreator ロールが割り当てられている必要があります。

今回は検証のためと今後やりたいことを見据えて「組織の管理者」ロールを付けています。
状況に応じて最小限の権限で実施をお願いいたします。

黒塗り多くて見にくいですが、プロジェクトAのユーザーに対して、組織Bの管理者権限を付与しようとしています。

エラーが出ましたね。

エラーの原因と検討

エラーの原因もエラー文に明記されていたので、組織ポリシーを確認します。

“iam.allowedPolicyMemberDomains”で検索すると簡単に見つかります。
GoogleCloud公式ドキュメント　ドメイン別の ID の制限

これは、別ドメインからのユーザーログインを許可しないというセキュリティ観点の組織ポリシーです。
デフォルトで有効化されております。
なるほど、この許可ドメインに現在のドメイン（ドメインA）を入れればいい・・・のですが。

[ポリシーの種類] で [許可] を選択します。注: ドメイン制限の制約は　[拒否]　値をサポートしていません。
[カスタム値] に、組織のリソース ID または Google Workspace のお客様 ID を入力します。

ということなので、Google Workspace または Cloud Identity を利用しているドメインからのユーザー（プリンシパル）のみを許可するように設計されているようです。
試しにポリシー編集で無理やりドメイン名入れたりしてみましたが、エラーではじかれました。。
“組織”を作るならしっかりドメイン管理されているべき、という前提の設計ですね。
設計思想は正しいと思うのですが、気軽な検証と相性が悪かった部分です。

解決策として2つ考えられました。

Cloud Identity の IDフェデレーションを使う
弊社ではActiveDirectory使っているので、本質的な対応ではあるのですが、私自身はADの管理者でもなく気軽な検証としては手間が大きいです。
このポリシーを非アクティブ化する
手っ取り早いですが、セキュリティ的な懸念が出てきます。

今回は2のポリシー非アクティブ化の対応を取りました。
セキュリティ観点は気になりましたが、そもそも現在組織配下ではない状態では、こういった制御はない状態なので
セキュリティ的に低下はしないと判断して非アクティブ化させました。
皆さんもポリシーの非アクティブ化を実施する際は、要件をしっかり確認いただいたうえでの判断が必要になる部分かと思います。