Google Cloud の IAMについてわかりやすく解説
本記事では、Google Cloud のIdentity and Access Management（IAM） と セキュリティについて主要な機能をご紹介します。
アカウントの種類
Google Cloudで利用するアカウントは以下のような種類があります。
(1) ユーザー
(2) Google グループ
(3) サービスアカウント
(1) ユーザー
Googleアカウントの個人アカウントのユーザーです。
Gmailアカウントでも、Goole Workspaceアカウントでも同じ様に利用できます。
Google Workspaceのアカウントでは、「組織 」の機能が利用できるようになります。
(2) Google グループ
Googleグループは、Googleのサービスでメーリングリストなどの機能を持ったサービスです。
この機能では、Google DriveやGoogle Chatなど各種サービスのアクセス権限の付与に利用することも出来ます。
Goole Cloudでも利用することが可能で、Googleグループを使うことで、ユーザーをグループにまとめ、グループ単位で権限を付与することが出来るようになります。
特に、組織が大きくなるとチーム単位や部署単位で権限の付与や変更を行うことが多くなり、個別に権限付与をしていると管理が難しくなります。
そういったときに、利用できるのがGoogleグループのアカウントです。
Googleグループの作成は、Google Cloudのコンソールからも作成・管理をすることが出来ます。
(3) サービスアカウント
個人アカウントのユーザーとは別に、アプリケーションやインスタンスなどに対して権限を付与するために使用されます。
サービスアカウントの用途例
ここでは、サービスアカウントの用途を2つ例として挙げてみます。
Google Compute Engine のインスタンスや Google App Engineなどのサービスに設定して利用します。
各サービスには、サービスアカウントが設定されます。 サービスアカウントはユーザーではなく、アプリケーションやコンピューティングワークロードに使用されるアカウントです。 認証されると、アクセス件が付与されているすべてのリソースにアクセスできるようになります。
例えば、 Google App Engine からclientライブラリを使用してGoogle Cloud Storage にアクセスする場合など、Google App Engine に設定されているサービスアカウントに対して Google Cloud Storage へのアクセス権限を付与する必要があります。
この様にサービスアカウントを利用すると、各サービス間でのアクセス制御を行うことが出来ます。
サービスアカウントキーやtokenなどを利用して、GCPの外部から利用します。
■ サービスアカウントキー
サービスアカウントは、サービスアカウントの管理画面やgcloudコマンドを使って「サービスアカウントキー」 をダウンロードすることが出来ます。
このサービスアカウントキー を使用して、ローカル端末やオンプレサーバーなどからGoogle Cloudのサービスへアクセスすることが可能です。
サービスアカウントキー は、有効期限がありません。 対象の サービスアカウントキー が不要になった際は、管理画面等でサービスアカウントキーを無効化もしくは、サービスアカウント自体を削除するまでどこからでもアクセスできるようになるので、取扱いにはくれぐれも注意して下さい。
なお、サービスアカウントキー を使用せずにアクセスできる方法もいくつか用意されていますので、安易に利用せず、最終手段として利用して下さい。
■ アクセストークン
アクセストークンは、OAuth 2.0 アクセス トークンの形式で、１時間の有効期限を持っており、httpのリクエストヘッダーに追加して利用します。 サービスアカウントキーと比較して短い有効期限が設定されており、リスクが低くなります。
■ その他に利用できる認証情報
上記の他、以下のような形式の認証情報を利用することが出来ます。
- OpenID Connect（OIDC）ID トークン
- 自己署名 JSON ウェブトークン（JWT）
- 自己署名バイナリ blob
公式サイトはこちらです。
サービス アカウントの概要
Google が自動で作成するサービスアカウントについて
Googleが自動でつくるサービスアカウントは、Google Cloudの特定のサービスを動作させるために利用されています。 そのため、不用意に権限を外したりすると不具合の原因になるので、公式ドキュメントに従い注意して利用して下さい。
サービスアカウントの権限の借用について
サービスアカウントの権限を借用する機能があります。
これは、サービスアカウントに権限を付与し、そのサービスアカウントの権限を借用することで、そのサービスアカウントになりすまして利用することが出来る機能です。
これは、個人アカウントに対して、期間限定で特別な権限を付与する場合などに利用できます。
例えば「本番環境での作業が必要になった際に、作業者に30分だけ作業をする権限を付与する」といった使い方が可能になります。
開発時のローカル環境でのサービスアカウントの利用
開発時にローカル環境（個人PC）から Google Cloud CLI (gcloud)、 gsutil、 terraform などを利用する際にサービスアカウントのアクセスキーをダウンロードして利用する記事を見かけることがあります。
アクセスキーは前述した通り、流出した際に非常に危険なため、極力ダウンロードしないようにして下さい。
ローカル環境からGoogle Cloudにアクセスする場合には、 gcloud auth application-default login を実行して下さい。
これにより、個人アカウントの権限を利用してサービスアカウントと同じ様に利用することが出来ます。
開発中のアプリケーションでも、Google Cloud の クライアントライブラリーを使用して構築していれば、サービスアカウントを利用するのと同じ様に動作するはずです。
ロールと権限
Google Cloudの権限は、APIごとに権限（参照、更新、削除など）を細かく用意されています。
アカウントへの権限付与はとても重要で、役割に応じた必要最小限の権限を設定することが推奨されています。
アカウントに対して、権限を付与する場合には、これらの権限を設定したロールを作成し付与していきます。
ロールには以下の種類があります。
- 基本ロール: オーナー、編集者、閲覧者、参照者という権限が用意されています。
- 事前定義ロール: Google Cloudにて用意している特定のサービスへの権限が細かく設定されています。
- カスタムロール: ユーザーが必要に応じて作成できるロールです。
ひとつずつ見ていきましょう。
(1) 基本ロール
基本ロールは、事前定義されているロールで Google Cloud リソースへ幅広い権限を付与することができます。
事前定義されており便利ですが、必要以上の権限を付与してしまうことがあります。
特に編集者権限などは、ほとんどのサービスへの更新権限が付与され、かなり強い権限になります。
開発者向けに付与する権限としては使い勝手が良いものになっていますが、最小限の権限付与からは逸脱するものになり、あまり推奨されません。
オーナー権限以外は、「事前定義ロール」を利用すること検討して下さい。
特に、上で紹介したサービスアカウントに付与する権限としても、基本ロールを付与することが出来ますが、こちらも特に不特定多数が触る可能性もあり、権限付与は注意が必要です。
Googleが作成するサービスアカウントには、 Compute Engine Default Service Account や AppEngine Default Service Account などがありますが、これらも編集者権限が付与されており、個別にサービスアカウントを作成し、そのサービスアカウントに必要最低限の 事前定義ロール を付与することが推奨されています。
基本的な役割
- ビューア(roles/viewer) : 読み取り専用アクションのアクセス許可。リソースやデータの変更はできない。
- 編集者(roles/editor) : すべての閲覧者の権限に加え、状態を変更するアクションに対する許可。リソースやデータの作成、変更、削除が可能。
- オーナー(roles/owner) : すべての編集者の権限に加え、プロジェクトやプロジェクト内のリソースのロールと権限を管理する。
(2) 事前定義ロール
Googleの権限は、各APIごとに細かく権限が設定されています。
これらの権限をサービスごとに必要な権限にまとめられているのが事前定義ロールになります。 Google Cloud が新しい機能やサービスなどを追加した時に、必要に応じて権限が自動的に更新されます。
例えば、Cloud Run に関するロールとしては、以下のようなロールが定義されています。
- Cloud Run デベロッパー
- Cloud Run 閲覧者
- Cloud Run 管理者
- Cloud Run 起動元
この様に、サービスごとに必要な権限が設定されており、必要なロールを個別に付与することで利用することが出来ます。
(3) カスタムロール
カスタムロールでは、事前定義ロールでは足りない場合に、ユーザー自身が権限をまとめたロールを作成することが出来ます。
組織全体または組織内の特定のプロジェクトに対して作成することができ、ロールで使用できる権限はロールを作成する場所によって限定されます。
便利な機能ですが、Google Cloud上で必要な権限が増えた場合、ユーザー側でロールに反映する必要が出てくる点には注意が必要です。
カスタムロールで作成されたロールには権限の自動更新は行われません。
Google Cloudの開発はとても活発に行われており、サービスの追加、サービスの改善が常に行われているので、カスタムロールの多用は避けたほうが良いと思います。
公式サイトはこちらです。
ロールと権限
Identity-Aware Proxy(IAP)
ゼロトラストネットワークを実現しているサービスです。
VPNを使用することなく、信頼できないネットワークからの作業を可能にします。
IAPには、複数の利用方法がありますが、ここでは２つの機能についてご紹介いたします。
- Google Cloud 上で構築したサービスに対して、Googleアカウントでの認証を行う
- Google Compute EngineのインスタンスへのsshアクセスをGoogleアカウントでの認証で行う
(1) Google Cloud 上で構築したサービスに対して、Googleアカウントでの認証を行う
App Engine、Compute Engine、HTTPS ロードバランサでホストされているサービスへのアクセス権を管理できます。
Webアプリケーションでは、認証機能は、特に重要な機能になります。
この認証機能を簡単な設定を行うことで、権限を付与したGoogleアカウントのみに制限することが出来ます。
特に、以下のようなケースでは認証機能を実装することなく提供することができます。
- 社内向けのシステムでGoogle Workspaceのアカウント向けのサービス
- テスト環境で特定のメンバーのみにアクセスを許可するサービス
(2) Google Compute EngineのインスタンスへのsshアクセスをGoogleアカウントでの認証で行う
Google Compute Engineのインスタンスへのアクセスは、sshで接続することが多いと思います。
個人端末などGoogle CloudのVPCネットワークの外からsshでアクセスする場合には、インスタンスに外部IPを付ける必要があり、Firewallで22番ポートを開放する必要があります。
内部のインスタンスは外部に公開しないケースが多く、アクセスする際に、外部IPを設定するのはあまり好ましくないケースが多いと思います。
このようなケースでは、暗号化されたトンネルを確立し、SSH や RDP などのトラフィックを VMインスタンスに転送することが出来ます。
こちらは、以下の設定を行うことで利用が可能になります。
- IAPの設定
- IAP経由でのアクセスを許可するFirewallの追加
公式サイトはこちらです。
Identity-Aware Proxy の概要
まとめ
Google CloudのIAMについて紹介してみました。
いくつか種類があり、特にGoogleグループを利用した権限管理は、Google Cloudの特徴の一つではないでしょうか。
また、IAPなど、Googleのゼロトラストネットワークのノウハウが生かされている機能も提供されており、非常に強力なツールになっています。
Google Cloudの利用の参考にして頂けたら幸いです。
