はじめに
AWS IAMとGCP IAMは同じ名前のサービスですが微妙にできることが異なるため、整理してみたいと思います。
AWS IAM
AWSにおけるIAMは、基本的にAWSアカウント内閉じたものになります。許可を付与する対象は、IAMユーザ、グループ、ロールとなり、許可設定は、IAMポリシーで行います。IAMポリシー自体は、JSONのドキュメントでTAGやS3バケットなどのリソースをConditionとして細かく設定することができます。
これは、一つのAWSアカウントで複数システムが稼働するような環境において必要となる機能です。
GCP IAM
GCPのIAMは、以下のようなイメージになります。
認可を付与する対象は、Googleアカウント、グループ、サービスアカウントになります。AWSとの違いは、大きく分けて2つあります。
- 認可設定ですが、プロジェクトのリソースに対して任意のAPIを指定して許可する形となり、JSONドキュメントを直接記載することができません。コンディションで任意のTAGが付与されたインスタンスへの操作を許可するいったことができません。これは、サービスや環境ごとにプロジェクトを分けるというアカウント設計が前提となっているからです。
- 設定対象によって、操作する管理コンソールが異なります。Googleアカウントやグループの操作は、Adminコンソールで行います。IAMのPermissionやロール、Orgnization Policyは、GCPコンソールで行います。
GCP管理コンソールでのPermissionの付与の方法は、AWS IAMと違い一度ロールを選択してから必要なPermissionを追加する形で設定します。
IAM & Admin>Roles> Create Roleをクリックします
例としてCompute Adminをクリックします。
Compute AdminのPermissionがリストアップされるので必要なPermissionを使いしてロールを作成します。
GCP IAMのロール
GCPのロールは、以下の3種類が存在します。
- 基本の役割(Primitive roles)
- GCPに最初からある役割
- Owner,Editer,Viewerから選択できる
- at leastな設定ができため非推奨
- 事前定義済みの役割(Predefined roles)
- GCPが事前定義したロール
- 細かい制御が可能
- カスタムの役割(Custom roles)
- 新規に作成するか、事前定義済みの役割を指定してカスタマイズすることが可能
その他、GCP特有の考え方でRoleのStageというものがあります。Stageとして、Alpha,Beta,GA,Disableが設定可能です。Diableに設定されたロールは、アタッチ可能ですが、実際の認可が行われません。ユーザは、Alpha/Beta/GAのStageのロールが付与されているう場合は、Permissonが許可されますが、対象のロールがDiableになるうとこれまで行ってきた操作が拒否されます。
Alpha,Beta,GAは以下の様な使い分けが推奨されていますが、そこまで細かく気にしなくても運用可能です。
- Alpha
- 作成時は、本番運用の準備ができていないためAlphaとする
- Beta
- 使用してしていて、問題なければBetaとする
- GA
- 本番利用で問題ないと判断すればGAとする
GCP Organizationレベルの許可
GCPコンソールの左上のドロップダウンでOrgnizationを選択して、任意のユーザにロールを付与すると、Organization配下のプロジェクト全体で利用可能になります。