今回は、Google CloudサービスのIdentity and Access Management(IAM)について説明します。
現在、私が参画しているプロジェクトでは、顧客のGoogle Cloudサービスを利用する際の利用ガイドを作成しています。その中で、IAMについて再学習を行ったので、それをアウトプットします！
IAMは、Google Cloudサービスを使う上で最も基本的なサービスの一つなので、これからGoogle Cloudサービスを使う人は是非ご覧頂ければと思います！
プリンシパル
プリンシパルは、Goolge Compute Engineなどのリソースへ、アクセスが制御されているアカウントになります。
プリンシパルの種類
プリンシパルには、下記のようなものがあり、通常はメールアドレスがそれにあたります。
- Googleアカウント
Googleアカウントに紐付けられている一意のメールアドレスをIDとして使用します。 - サービスアカウント
アプリケーションやGoogle Cloudのリソースをアカウントとして使用します。例えば、Pub/SubからCloud Functionに通知を送る際、Pub/Subのリソースに対して、Cloud Functionのロールを割当ます。 - Googleグループ
Googleアカウントやサービスアカウントの集合体です。部署のメンバー全員にロールを割当する際は、一つずつのGoogleアカウントではなく、グループを作成し、そのグループにアカウントを包含します。そして、そのグループにロールを割り当てます。 - Google Workspaceアカウント
Google Workspace アカウントに含まれるすべての Google アカウントの仮想グループです。 - Cloud Identity ドメイン
Cloud Identity ドメインも、1つの組織内のすべての Google アカウントの仮想グループです。 - 認証済みのすべてのユーザー
すべてのサービスアカウント、および Googleアカウントで認証されたユーザー全員を表します。このIDには、個人用 Gmail アカウントも含まれます。このプリンシパルタイプは、一部のリソースタイプでサポートされていません。 - すべてのユーザー
インターネット上のユーザーを表します。このプリンシパルタイプも、一部のリソースタイプでサポートされていません。
権限
権限とは、各リソースに対して許可されている操作になります。権限は、「service.resource.verb」の形式で表します。ユーザーに直接権限を付与することはできず、代わりに権限の集合体であるロールを付与します。
権限の参照は下記Gooleのドキュメントより確認することができます。
・IAM permissions reference
https://cloud.google.com/iam/docs/permissions-reference?hl=ja
権限形式のバージョン
権限の形式には２つのバージョンがあります。バージョンによって、権限の記述方法が変わります。
- IAM
v1権限形式
v1形式は、上記のように「service.resource.verb」の形式で表します。許可ポリシーで使用します。
例）pubsub.subscriptions.consume - IAM
v2権限形式
v2形式は、「service_fqdn/resource.action」の形式で表します。拒否ポリシーで使用します。
例）compute.googleapis.com/publicAdvertisedPrefixes.create
ロール
ロールは権限のコレクションです。IAMには、3つのロールがあります。
- 基本ロール
- 事前定義ロール
- カスタムロール
基本ロール
基本ロールは、従来から使用されている3つのロールがあります。
- 閲覧者
既存のリソースやデータの表示など、状態に影響しない読み取り専用アクションに必要な権限です。リソースの変更はできません。 - 編集者
すべての閲覧者権限に加えて、状態を変更するアクションに必要な権限です。リソースの変更が可能です。 - オーナー
すべての編集者権限と下記2つのアクションを実行するために必要な権限があります。- プロジェクトおよびプロジェクト内のすべてのリソースの権限とロールを管理
- プロジェクトの課金情報を設定
Google Cloudサービスでは、基本ロールを使用することは推奨されていません。
理由は、多くの権限が含まれるからです。Google Cloud サービスのベストプラクティスの１つとして「最小権限の原則」があります。これは、名前の通り、基本、プリンシパルに割り当てるロールは、最小権限である必要があります。よって、Google Cloudサービスでは、通常、事前定義ロール又はカスタムロールが使用されます。
事前定義ロール
事前定義ロールは、基本ロールよりも詳細なアクセス制御が可能なロールになります。例えば、Google Cloud Storageにおける「Storageオブジェクト作成者」が事前定義ロールになります。「Storageオブジェクト作成者」には、下記権限が与えられています。
- orgpolicy.policy.get
リソースのポリシーを取得します。 - resourcemanager.projects.get
プロジェクトを取得します。 - resourcemanager.projects.list
指定されたフィルターを満たすプロジェクトを一覧表示します。 - storage.multipartUploads.abort
マルチパート アップロード セッションを中止します。 - storage.multipartUploads.create
複数のパートでオブジェクトをアップロードします。 - storage.multipartUploads.listParts
マルチパート アップロード セッションで、アップロードされたオブジェクト パーツを一覧表示します。 - storage.objects.create
新しいオブジェクトをバケットに追加する。
カスタムロール
カスタムロールは、事前定義ロールが要件を満たしていない場合に作成するロールです。
リソース
リソースとは、Google Cloud StorageやGoogle Compute Engineなどの、Google Cloudの各サービスのことをいいます。ユーザーが特定のリソースにアクセスするためには、そのリソースのロールをプリンシパルに割り当てます。
通常は、プロジェクトレベルでIAM権限を付与しますが、リソースでは、より細かくIAM権限を付与できます。
たとえば、特定の Cloud Storage バケットのユーザーにストレージ管理者ロールを付与できます。また、特定の Compute Engine インスタンスのユーザーに Compute インスタンス管理者ロールを付与することもできます。
ポリシー
ポリシーとは、Google Cloud リソースへのアクセスを許可／拒否するポリシーになります。
ポリシーの構造
ポリシーは、下記３つで構成されています。
- プリンシパル
- ロール
- 条件
プリンシパルとロールの説明は、上記をご参照ください。
条件
リクエストの内容に応じて、ロールの集合体をさらに制限する論理式です。例えば、指定された日時まで使用できる条件は、下記のように記載します。
request.time < timestamp("2023-01-31T00:00:00Z")
※2023年1月31日0時までリクエスト可能（実際は、どこの国の時間帯か指定します。）ポリシーの継承
ポリシーは、リソース階層のどの階層にも設定できます。リソースは、親階層のポリシーを継承します。例えば、第一階層のフォルダに許可ポリシーが割当られている場合、第二階層のフォルダ、その配下のプロジェクトにも同じ許可ポリシーが割当されます。
拒否ポリシー
拒否ポリシーを使用すると、許可ポリシーに関係なく、特定のプリンシパルが特定の権限を利用できないポリシーを作成することができます。拒否ポリシーは、許可ポリシーより強いポリシーになります。
拒否ポリシーは、プロジェクト、フォルダ、組織に適用できます。1つのプロジェクト、フォルダ、組織には最大5つの拒否ポリシーを適用することができます。
拒否ポリシーも許可ポリシー同様に継承があります。上位のノードで拒否ポリシーが適用された場合、下位のノードでも拒否ポリシーが適用されます。
IAMの構成
IAMは、Googleアカウント等のプリンシパルに編集者等のロールを割り当て、リソースの制御を行います。
ポリシーは、組織やフォルダといったノードに割当を行い、ノード間で一定したルールを適用します。ポリシーは、下のノードで変更することができます。これをオーバーライド（上書き）と呼びます。
まとめ
今回は、下記6点について説明を行いました。
- プリンシパル
- 権限
- ロール
- リソース
- ポリシー
- IAMの構成
Cloud IAMは、Google Cloudサービスの基本となるサービスなので、是非しっかり習得しましょう。IAMを理解することで、後に設計をする際、とても役に立ちます。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
