著者: wusamin 公開日: 2022-12-24

Google Cloud の IAM を探る

この記事はユアマイスターアドベントカレンダー 2022の 24 日目の記事です

概略

Google Cloud には IAM（Identity and Access Management）という権限を制御する仕組みがあります。これを利用することで、Google Cloud のリソースに対するユーザーのアクセスを制御できます。

個人のプロジェクトならいざ知らず、会社のそれであれば、誰が、何に、どのようにアクセスできるかを制御することは必要となるでしょう。

この IAM 、自分が最初に目にした時はロール、プリンシパル、サービスアカウント、etc...様々な用語があり、難しく感じました。
本記事では、17 日目の記事で作成した画像を読み取る Web アプリのコンテナイメージを、 Artifact Registry にアップロード〜 Cloud Run にデプロイするまでの手順を題材に、IAM とは何なのか、どのように付与するのかを書いていきたいと思います。

IAM とは

Google Cloud における IAM は、誰がどのリソースに、どのような権限を持つかを定義するものです。

IAM では、権限を付与できるものを「プリンシパル」と呼びます。「誰」はこのプリンシパルが該当します。
プリンシパルには以下の種類があります。

Google アカウント
サービスアカウント
Google グループ
Google Workspace アカウント
Cloud Identity ドメイン
認証済みのすべてのユーザー
すべてのユーザー

権限は一つ、もしくは複数がまとめられて「ロール」として取り扱われます。権限自体が単体で何かに付与される訳ではなく、ロールがプリンシパルに対して割り当てられます。
ロールには以下の種類があります。

基本ロール（オーナー、編集者、閲覧者が該当する）
事前定義ロール（Google Cloud が用意しているプリセット的なもの）
カスタムロール（含まれる権限をユーザー側で指定できるもの）

実践してみる

新しく作成したプロジェクトで、実際に権限の制御をやってみましょう。
以下の手順を通じて、ユーザーに必要な権限のみが割り当てられた状態を目指します。

作業用のユーザーをプロジェクトに追加する
作業用のユーザーで Artifact Registry を操作する
作業用のユーザーで Cloud Run を操作する

※実際のメールアドレスが出ているところは黒塗りにしています

作業用の Google アカウントを追加する

まずは現在の IAM の状態を確認します。 Google Cloud のコンソールより、IAM にアクセスします。

IAMのプリンシパルの一覧です

プロジェクトを作成したオーナーの Google アカウントだけが存在しています。

このユーザーは残しておいて、今回 IAM を試すための Google アカウントにロールを割り当てます。とりあえず「オーナー」のロールにします。

以降、この Google アカウントを「作業用ユーザー」と呼びます。
Google Cloud コンソールの操作はオーナーのロールの Google アカウントで、コマンドでの操作は作業用ユーザーで行います。

「作業用ユーザー」が追加されたIAMのプリンシパルの一覧です

Artifact Registry 編

Cloud Run にデプロイするために、まずは Artifact Registry にコンテナイメージをアップロードします。

Google Cloud コンソールで Artifact Registry のリポジトリを新規に作成します。

新規に作成されたArtifact Registryの権限の状態です

作成したリポジトリの権限を確認します。オーナーが付与されている Google アカウントと、Artifact Registry のサービスアカウントがそれぞれ存在しています。

この時点では作業用ユーザーは Artifact Registry へのアップロード以外の操作を行わないため、ロールを必要なもののみに変更します。「オーナー」を削除し「Artifact Registry 書き込み」を追加します。

作業用ユーザーのロールの状態です

コンテナイメージをアップロードします。

# tagを打つ（コンテナイメージはあらかじめ作成してある）
docker tag wusamin/ocr-server asia-northeast1-docker.pkg.dev/gc-started/iam-test/ocr-server:0.0.1

# pushする
docker push asia-northeast1-docker.pkg.dev/gc-started/iam-test/ocr-server:0.0.1

アップロードできました。

コンテナイメージがArtifact Registryにアップロードされた状態です。

Cloud Run 編

続いて、Artifact Registry にアップロードされたコンテナイメージを Cloud Run へデプロイします。

デプロイするために必要な権限はCloud Run のページより確認できます。今回は「Cloud Run 管理者」と「サービスアカウントユーザー」のロールで実施します。ドキュメントで指定されている「Cloud Run 管理者」と、Artifact Registry のコンテナイメージを読み取るための「Artifact Registry 読み取り」のロールを割り当てます。

作業用ユーザーに「Cloud Run 管理者」と「Artifact Registry 読み取り」のロールが付与されています。

Cloud Run へデプロイするためには、サービスアカウントを利用できるロールが必要になります。
まず、今回利用するためのサービスアカウントを新規に作成します。「IAM と管理」の「サービスアカウント」から「サービスアカウントを作成」を選択し、必要な項目を埋めて作成します。今回は省略可の箇所は省略します。

サービスアカウント名とサービスアカウントIDを設定し、サービスアカウントの説明と2、3の項目は省略します。

「IAM と管理」の「サービスアカウント」から、作成したサービスアカウントの「権限を管理」を選択します。作業用ユーザーに「サービスアカウントユーザー」のロールを割り当てます。
このロールが割り当てられているプリンシパルは、このサービスアカウントがアクセスできるリソースにアクセスできるようになります（例えばサービスアカウントが「Compute OS 管理者ログイン」のロールを持っている場合、プリンシパルはサービスアカウントになりすまして、そのロールでリソースにアクセスできます）。

作業ユーザーに「サービスアカウントユーザー」を割り当てた状態です。

これで作業用ユーザーに「Cloud Run 管理者」と「サービスアカウントユーザー」の両方が割り当てられました。

コンテナイメージをデプロイしてみます。サービスアカウントを--service-accountで指定します。

gcloud run deploy cloud-run-deploy-service \
 --image asia-northeast1-docker.pkg.dev/gc-started/iam-test/ocr-server@sha256:b3acd0f8270449ce29d9df1e9114719abf79c90975093016764936f7a98d5d60 \
 --region asia-northeast1 \
 --project gc-started \
 --service-account cloud-run-iam-test@gc-started.iam.gserviceaccount.com

❯ gcloud run deploy cloud-run-deploy-service \
 --image asia-northeast1-docker.pkg.dev/gc-started/iam-test/ocr-server@sha256:b3acd0f8270449ce29d9df1e9114719abf79c90975093016764936f7a98d5d60 \
 --region asia-northeast1 \
 --project gc-started \
 --service-account cloud-run-iam-test@gc-started.iam.gserviceaccount.com

Deploying container to Cloud Run service [cloud-run-deploy-service] in project [gc-started] region [asia-northeast1]
✓ Deploying new service... Done.
  ✓ Creating Revision... Revision deployment finished. Checking container health.
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [cloud-run-deploy-service] revision [cloud-run-deploy-service-00001-voy] has been deployed and is serving 100 percent of traffic.
Service URL: ****

Cloud Run にデプロイ出来ました。これで「Web アプリのコンテナイメージを、 Artifact Registry にアップロード〜 Cloud Run にデプロイする」の一連の手順が完了しました。

最後に作業用ユーザーの権限を見てみましょう。最初に作成した時は、たくさんの権限を持つ「オーナー」のロールだけでした。しかし、ここまでの作業により Artifact Registry と Cloud Run にのみアクセスできる状態のロールとなりました。

作業用ユーザーのロールは「Artifact Registry 読み取り」「Artifact Registry 書き込み」「Cloud Run 管理者」のみです。

作業用ユーザーの権限を必要な分に制御できました。

検証

権限を必要な分に絞った Google アカウントによるデプロイができました。疎通確認を行ってみましょう。

# 疎通確認用のエンドポイント
❯ curl --dump-header -  https://xxxx~

HTTP/2 200
content-type: application/json
date: Thu, 22 Dec 2022 07:57:54 GMT
server: Google Frontend

正常にレスポンスが返ってきました。きちんとアプリをデプロイできていることが確認できました。

まとめ

Google Cloud の IAM について、実践を交えつつまとめてみました。
当初はプリンシパル？　ロール？　となっていましたが、実際に操作してみることで、IAM への理解が深まりました。とりあえず強そうなロールを付けておけば大丈夫！　という思考停止の状況を脱することができました。

また、権限の管理の複雑さ・煩雑さを知ることで、IaC（Infrastructure as Code）の重要性を理解することもできました。誰に、どのような権限が与えられているかをソースコードで管理したり操作したりできるのは非常に心強いと感じました。

なお、弊社では Terraform によってインフラの構成を管理しています。機会があれば、Terraform についても調べて記事にしてみたいと思います。

以上です。読んでいただきありがとうございました。

記事一覧に戻る