はじめに
GCPのIAMって難しいですよね。私には難しかったです。何故難しいのかを考えると、概念とそれらの関係性を理解するのが難しいからだと思います。
このブログではIAMの利用方法は置いておいて、概念の関係性について説明できればと思っています。
このブログで書くこと、書かないこと
このブログでは以下の用語の簡単な説明と、それらの関係性について記述します。
- Principal
- Resource
- Permission
- Role
- Role binding
- Allow policy
また、このブログでは具体的なサービスアカウントの作成方法やサービスアカウントキーの作成方法などは記述しません。このブログはサービスアカウントの作成やサービスアカウントキーの作成を覚える前に、どういうものができるのか覚え、その後の学習に繋げる事を目的としています。
また正確な理解より、ざっくりとどういう関係なのかを具体的な用語で説明していきます。
簡単な用語の説明
Principal、 Resource、Permission
まずはPrincipal、Resource、Permissionの簡単な説明です。これらの3つはそれ単体で存在します。他の要素はこれら3つの関係を表す要素になります。このためまずこの3つを簡単に説明します。
| 用語 | 説明 |
|---|---|
| Principal | アカウントのようなものです。 色々ありますが、とりあえずアカウントだと思ってください。 |
| Resource | Resource はGoogle Cloudのサービス。例えばCompute EngineやCloud Pub/Subなどです。 |
| Permission |
Permissionは各Resourceに対する許可を表すものです。例えば pubsub.subscriptions.consume というPermissionがあります。これは Cloud Pub/Sub の subscription への consume を許可するというものです。 |
Role
RoleはPermissionの集合です。
IAMでは Principal(アカウント) に直接 Permission を付与しません。かわりに Principal に Role を付与します。このような形式を RBAC(ロールベースアクセス制御)といいます。
Permission ではなく Role を付与することで柔軟性と使い易さを実現しています。例えばPub/Subのロール一覧にある roles/pubsub.editor ロールをみていただくと 32 個の Permission が付与されています。Permissionを直接するとこの 32 個を管理しなければなりません。逆に roles/pubsub.editor 自体を権限とすると、特定の権限を抜きたいという時に難しくなります。このバランスをとるのためにRoleが存在します。
Role binding
Principal と付与された Role の対応を Role binding と呼びます。各 Principal には 複数の Role を binding できます。例えば、1つのアカウントで Pub/Sub と Spanner Database を管理したい場合は、そのアカウントに PubSub用の roles/pubsub.editor ロールと Spanner 用の roles/spanner.databaseAdmin ロールを付与できます。
勿論、各Roleは複数の Principal に付与可能です。 Role と Principal の関係は多対多の関係になります。
Allow policy
Allow policy は全ての Role binding の集合です。
各 GCP Resource へのアクセスが発生すると、 IAM のチェック機構が Allow policy を確認します。そのチェックの結果、 Resource へのアクセスの可否を決定します。
Role の付与とチェックの流れ
最後に Role の付与からチェックまでの流れを記載します。
最初に、処理に必要な Permissin を決めます。 この Permission は複数になる可能性があります。
Permission が決ったら、それら Permission をまとめる Role を作成します。ただし実際に Role を作成することはまずありません。 Predefined roles という既に定義された Role があるので、それを使う事が殆どです。ちなみに、自作した Role は Custom roles と呼ばれます。
付与する Role が決まったら、 Principal に付与します。 Service account に付与するのが一般的です。
付与した時点で Role binding が作成されます。また同時にその Role binding は Allow policy に含まれます。実際には Allow policy に含まれるまでに少し時間がかかるみたいです。
最後に Role を付与した Principal から GCP Resource にアクセスすると、 IAM が Allow policy を確認してアクセスの可否を決定します。
最後に
どうでしょう？ざっくりとわかりましたか？なんと無くでもなにか分かってもらえれば幸いです。なにか分かったことがあったら再度オフィシャルドキュメントを読みましょう。正確な知識を得る一助になれば幸いです。