[ GCP ] メガネと学ぶ GCP (11) IAMについて

[ GCP ] メガネと学ぶ GCP (11) IAMについて

こんばんは。七色メガネです。

今回の記事では、GCPにおける権限関係を統御する IAM という概念について学んでいきます。

IAM ってなに?

IAM とは Identity and Access Management の略称であり、GCPにおいて [ 誰がそれを ・ 何に対して・何ができるか] という権限を管理するためのサービスです。
このような定義の集合を、 IAMポリシー と呼称します。

IAM を理解する上で、いくつかの重要な内容があります。
それは、リソース階層、ロール、メンバーです。ここではそれらを、順に解説します。

リソース階層について

GCP におけるリソースは、上記の図のような階層構造を持っています。
上から順に、「組織」「フォルダ」「プロジェクト」「リソース」と並んでいます。

この階層におけるルートは組織ノードであり、末端ノードがリソースです。

IAM ポリシーはこれらのそれぞれのレベルに対して付与することができます。そしてポリシーには、その権限を持つことになるユーザが含まれます。
例えば、Cloud Storage に対する Read 権限をプロジェクトに付与すると、そのプロジェクトに所属するユーザーは、そのプロジェクト以下に存在する Storage を Read することができるようになります。

ここで重要なのは、自分の祖先ノードに対して付与された権限は、自分も継承するということです。
例えば先ほどの例ではプロジェクトに対して Storage に Read 権限が付与されましたが、この時、そのプロジェクトに属するリソースも Strage に対する Read 権限を獲得します。

もう一つ大事なことは、子ノードは親ノードから継承された権限を制限できないということです。
再度先ほどの例を用いると、リソースレベルでポリシーを適用する時、親から継承された Storage の Read 権限を取り消すようなポリシーは設定できません(無視されます)。子ノードでのポリシー付与は、親ノードから継承されたポリシーの拡充としてのみ、許容されます。

組織

組織ノードは、全てのフォルダとプロジェクトの祖先ノードです。ポリシー継承の原則により、組織ノードに設定された権限は、全てのリソースに対して適用されます。
組織ノードはオプションであり、必ずしも全てのGCPユーザが使用可能なものではありません。
しかし組織ノードが存在すると、プロジェクトを統合的に管理できるため、可能であるならば使用するべきです。

組織ノードは G Suite および Cloud Identity のユーザーのみ作成することができます。

フォルダ

フォルダノードを使用すると、プロジェクトをグループ化することができます。
これを使用すると、例えば、組織内の部署や部門、事業所などのドメインを表現することができます。

フォルダには、複数のプロジェクトを紐づけることができます。また、フォルダの中にフォルダを入れることもできます。

注意しなければいけないのは、フォルダノードは組織ノードを持つ G Suite および Cloud Identity のユーザーのみ使用することができる、ということです。

プロジェクト

プロジェクトは、GCP全体における基本エンティティです。あらゆるGCPのサービス、リソースはプロジェクトに紐づくように作成、管理されます。

ロールについて

ロールとは、どのリソースで何ができるかを表現するオブジェクトです。

IAM では、ユーザに権限を直接付与しません。その代わりに、権限の集合体であるロールをユーザに付与します。

ここには大別して、3種類のロール種別が存在します。

Primitive Role

基本的なロール・タイプです。これは標準的なロールであり、[ オーナー ] [ 編集者 ] [ 閲覧者 ] [課金管理者] という4つのロールが定義されています。

オーナーはプロジェクトの作成や削除、メンバーの追加などを行うことができ、編集者はリソースの変更や構成を行うことができ、閲覧者はリソースの閲覧を行うことができます。
これらの3つのロールは包含的であり、オーナーは編集者の権限を持ち合わせており、また編集者は閲覧者の権限を持ち合わせています。末端の閲覧者は、自らの権限のみを持っています。

また最後の課金管理者はその名の通り、課金に関する権限を保持します。このロールは他のロールとの関連があまりありません。
運用上も、他の3つとは切り離す形でロールを付与することが一般的です。

PreDefined Role

基本ロールよりももっと細かい制御を行いたい時は、この事前定義ロールを使用します。

事前定義ロールには、例えば [appengine.codeViewer] や [appengine.deployer] などがあります。
基本ロールが個々のリソースの違いに対応していなかったのに対して、この事前定義ロールでは個々のリソースに対する閲覧権限、編集権限などが取りまとめられています。

基本ロールにしても事前定義ロールにしても、それはグルーピングされた権限の集合体です。
というのも、権限自体が表現するものはもっと小さく、例えば [appengine.instances.get] のように、リソースに対する一部の行為を規定するに過ぎないからです。

事前定義ロールでは、想定される用途に適切な権限を集め、ロールとしてグルーピングしたものをユーザに提供しています。
通常の用途から外れるような権限統御を行いたい場合は、次のカスタムロールを使用することになります。

Custome Role

カスタムロールは、ユーザが作成するロールです。
基本ロールでも事前定義ロールでも望ましい権限統御が行えない場合、このカスタムロールを作成・使用します。

ユーザは自ら選択した権限で以ってこのカスタムロールを作成します。
このカスタムロールはGoogleによって管理されません。したがって、例えば基本的な権限の名称などが変更されたとしても、カスタムロールの中身を自動で更新するなどはしません。

メンバーについて

メンバーは、IAM における 「誰が・何を・どのように」 の考え方の「誰が」に相当するオブジェクトです。

メンバーオブジェクトとして選択し得るのは、次の5種です。

Googleアカウント

Googleアカウントは、GCPを利用するための主に個人を表現するアカウントです。一般的な ***@gmail.com というメールアドレスがそのままIDとなります。企業のメールアドレスをGoogleアカウントとして用いることもできます。

Googleグループ

Googleグループは、Googleアカウントあるいはサービスアカウントをグルーピングしたものです。
例えば開発者に対してロールを付与したいときなどに、開発者個々のアカウントにロールを付与するのではなく、開発者グループを作成した上でグループにロールを付与する、などの使われ方をします。

個々のアカウントへのロール付与は煩雑さと誤操作の危険性を孕むため、Googleはこのグループ単位でロールを付与することを推奨しています。

G Suite ドメイン

G Suite ドメインは、一つの組織に所属する全てのメンバーを含む仮想グループです。
組織単位での権限操作を容易にします。

Cloud Identity ドメイン

Cloud Identity ドメインは、G Suite ドメインと同じく、一つの組織に所属する全てのメンバーを含む仮想グループです。
組織単位での権限操作を容易にする、という点もG Suite ドメインと同じです。

何が異なるか言えば、 Cloud Identity ドメイン ユーザは、G Suite に関するアプリケーションを利用できないということです。
つまり、 G Suite は不要だけれども組織単位での権限管理を行いたい、というニーズに対応するメンバーオブジェクトです。

サービスアカウント

サービスアカウントは、利用するアプリケーションに属するメンバーオブジェクトです。上記4つのオブジェクトとは性質が異なります。

このアカウントは、個々のユーザにではなく、GCPのアプリケーションに紐づいています。
これにより、例えばサーバ間のやりとりなどをユーザの認証情報を使用せずに行うことができるようになります。

 

まとめ

・GCPのリソース階層は、ルート側から 組織・フォルダ・プロジェクト・リソース で構成される。

・権限の制御は、リソース階層に沿った形で行われる。リソースの上位に設定された権限は、その子ノード、孫ノードへと引き継がれる。

・リソース階層においてノードは、祖先ノードから継承された権限を制限できない。

・IAM とは、GCP において [ 誰が ] [ どのリソースを ] [ どのように操作するか ] を制御するサービスである。

・[ 誰が ] に相当するのは、メンバーという概念である。メンバーには Googleアカウントのように個人のような主体もあれば、G Suite ドメインのようなグルーピングされた主体もある。またサービスアカウントはそれらと異質であり、ユーザに対してではなくアプリケーションそのものに設定できるメンバーオブジェクトである。

・[ どのリソースを ] [ どのように ] を表現するのが権限である。ただし権限は、それ単体ではユーザに付与されない。権限はロールという形式にまとめられ、ロール単位でユーザに付与される。

・ロールには、基本ロール・事前定義ロール・カスタムロースがある。全体的な権限制御は基本ロールで行い、個々の権限制御は事前定義ロールで行い、それで管理できない部分についてはカスタムロールを作成して使用する。

参考

https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ja

https://cloud.google.com/resource-manager/docs/creating-managing-folders?hl=ja

https://cloud.google.com/iam/docs/understanding-roles?hl=ja

https://cloud.google.com/iam/docs/overview?hl=ja

GoogleCloudPlatformカテゴリの最新記事