クラウド同上

別プロジェクトにIAM権限のコピーをするときに手作業でやっていませんよね?

Author
satou
Lv:3 Exp:850

ガンガン行こうぜGCP!

開発用環境のプロジェクトで開発したぞー、さて次はステージング用のプロジェクトでテストだ!でもその前に、開発環境のIAM権限をコピーしないとね・・・という場面において、GCP Web Console から IAM の画面を開いて、目視で確認しながら手作業で権限内容をコピーしてませんか?

実はIAM権限は丸ごとエクスポート、インポートできてしまうのです!本記事では、この丸ごとエクスポート、インポートの方法をご紹介します。これを読めば面倒で間違いやすい手作業から今日で卒業です!
※IAMってなに?という方はまずこちらをご参照下さい。

1. 手作業で行うのは事故の元!

システム周りの設定において手作業ほど間違いやすくアテにならない作業はありません。どんなに注意していても、設定する項目が多くなると、ズレ・選択間違い・疲労感などの理由によりミスを起こしてしまいます。項目数が多いIAM権限のコピーにおいてミスをしてしまうと、ある環境では正しく動いていたのに別の環境では動かない!という事故の元になりがちです。(システム開発あるあるですね)

2. GCPに用意されていないハズが無い

世界で最もGCPを使用しているであろうGoogleの中の人が、マウスをクリックしながら目視と手作業でIAM権限をコピーしている姿…ちょっと想像できませんよね。当然、GCPにはIAM権限を手作業以外でコピーする方法が用意されています。少しだけ手作業は必要になりますが、目視で確認しながらマウスクリックするより、遥かに安全で簡単にIAM権限をコピーすることができます。せっかく簡単な手段が用意されているのですから、積極的に利用しましょう!

3. プロジェクトIAMのコピー

IAM権限は「組織」「フォルダ」「プロジェクト」のそれぞれのリソースに対して設定が存在します。ここでは利用頻度の高いプロジェクトのIAM権限のコピーを例に説明します。組織、フォルダについては若干コマンドが違うだけですので、プロジェクトの例を参考にして下さい。

3.1. IAMをエクスポート

GCP Web Console から Cloud Shell を起動し、以下のコマンドを入力します。

$ gcloud projects get-iam-policy <プロジェクトID> --format json > IAM.json

※<プロジェクトID>の部分をご自分のプロジェクトIDに置き換えて下さい。
例:$ gcloud projects get-iam-policy satou-copy-from --format json > IAM.json

たったこれだけでプロジェクトのIAM権限の一覧をJSON形式でエクスポートできてしまいます。簡単ですね!

3.2. エクスポートしたファイルを編集

JSON形式でエクスポートしたIAM権限ですが、残念ながらそのままではインポートできません。コピー元のプロジェクトに紐づいた情報も含めてエクスポートされているため、紐づいている情報の編集が必要になります。ここでは説明のため手作業による方法を紹介していますが、定期的な作業であればシェルスクリプトの作成など、できるだけ自動化できるように心がけましょう。

3.2.1. サービスアカウントのプロジェクト番号を変更

エクスポートしたファイルには、コピー元プロジェクトのサービスアカウントが含まれています。このサービスアカウントにはコピー元プロジェクトのプロジェクト番号が入っているので、コピー先プロジェクトのプロジェクト番号に変更します。

まず、プロジェクト番号の確認方法は以下のコマンドで確認できます。

$ gcloud projects describe  | grep projectNumber

コピー元、コピー先、それぞれのプロジェクト番号を確認します。
例:
$ gcloud projects describe satou-copy-from | grep projectNumber
projectNumber: ‘1234567890123’
$ gcloud projects describe satou-copy-to | grep projectNumber
projectNumber: ‘9999999999999’

プロジェクト番号が確認できたらサービスアカウントを編集します。先ほどのJSONファイルを開くと

$ "serviceAccount:service-1234567890123@compute-system.iam.gserviceaccount.com"

のように、service-コピー元プロジェクト番号という形式になっているので、コピー先プロジェクト番号に変更します。

$ "serviceAccount:service-9999999999999@compute-system.iam.gserviceaccount.com"

サービスアカウントは複数設定されているので、コピー元プロジェクト番号をまとめて置換するのがオススメです。

3.2.2. etagの情報削除

エクスポートしたファイルにはetagの情報が付加されていて、この行が存在しているとインポート時に現行リソースとファイル内のetag情報のチェックが行われます。一致していない場合、エラーとなりインポートできません。別のプロジェクトにコピーする場合には不要なので削除してしまいましょう。

$ "etag": "AbCdEfGhIjKlM=",

3.3. IAMをインポート

プロジェクト番号の変更とetagの削除ができたら、コピー先のプロジェクトにインポートします。

gcloud projects set-iam-policy <プロジェクトID> IAM.json

※<プロジェクトID>の部分をご自分のプロジェクトIDに置き換えて下さい。
例:$ gcloud projects set-iam-policy satou-copy-to IAM.json

実行するとetagが無いからポリシーが上書きになるよ、という確認メッセージが表示されます。

The specified policy does not contain an "etag" field identifying a
specific version to replace. Changing a policy without an "etag" can
overwrite concurrent policy changes.
Replace existing policy (Y/n)?

インポート先のプロジェクトに間違いが無いか確認して、Yを押下します。

$ Updated IAM policy for project [satou-copy-to].

のメッセージの後にずらっと内容が表示されたらインポートの終了です。
インポート先のプロジェクトにて、IAM権限がコピーされているのを確認しましょう。

以上でプロジェクトリソースのコピーは完了です。ね、簡単でしょう?

4. 組織・フォルダIAMのコピー

最後に組織・フォルダリソースのIAMコピーのコマンドをご紹介します。基本的な手順はプロジェクトIAMのコピーと同じですので、プロジェクトIAMのコピーを参照して下さい。なお使用するのはプロジェクトIDではなく組織ID、フォルダIDを使用します。
※作業するには組織やフォルダに対する適切な権限が必要です。

4.1. 組織

エクスポート

$ gcloud organizations get-iam-policy <組織ID> --format json > IAM.json

インポート

$ gcloud organizations set-iam-policy <組織ID> IAM.json

組織IDの確認

$ gcloud organizations list

4.2. フォルダ

エクスポート

$ gcloud resource-manager folders get-iam-policy <フォルダID> --format json > IAM.json

インポート

$ gcloud resource-manager folders set-iam-policy <フォルダID> IAM.json

フォルダIDの確認

$ gcloud resource-manager folders list --organization=<組織ID>

5. まとめ

IAM権限のコピー、いかがでしたでしょうか。もし今まで手作業で実施されていたのであれば、あまりの簡単さに目眩を覚えたのではないでしょうか(笑)。これはIAM権限のコピーに限りませんが、目視や手作業というのはどうしてもミスが避けられないものです。
手作業で時間をかけた挙句にミス、などというつまらない結果にならないように、用意されている機能は最大限活用して、安全安心確実にシステムを運用していきましょう!

クラウドエースでは、Google Cloud Platformのご利用について様々な技術支援を行っております。何かお困りのことがございましたらご相談ください!

次の記事を読み込んでいます
次の記事を読み込んでいます
次の記事を読み込んでいます
次の記事を読み込んでいます