CloudIAMの新機能カスタムロールを使った柔軟な権限管理

注意

この記事は2017年10月4日に更新されたもので、内容が古い可能性がありますのでご注意ください。

GCPを利用されている方の中にはCloud IAMを利用されている方も多いことでしょう。
Cloud IAMの登場以前はプロジェクトオーナー、プロジェクト編集者、プロジェクト閲覧者の3種類の役割しかユーザーに付与することが出来ず、不必要なサービスの権限も併せて付与することしか出来ないことも多々ありました。
それがCloud IAMが登場したことにより、サービスごとの役割、例えばGoogle Compute Engine(GCE)の場合、GCE管理者(GCEのリソース全てを管理することができる)やGCEネットワーク管理者(GCEのネットワークリソース全てを管理できる)、GCEイメージユーザー(GCEイメージの読み取り、使用のみ許可)といった最低限の権限付与が可能になりました。
しかしそんなCloudIAMでも満足出来ないあなたの為に、本記事ではより柔軟でセキュアな権限管理をすることができるカスタムロールについてご紹介します。

カスタムロールについて
- カスタムロールとはその名の通り任意のロール作成機能
- カスタムロールの基本概念は3つ
カスタムロールの作成方法
- 作成手順
カスタムロールが有効なユースケース
- 定義されている役割の中にニーズにハマる役割がない場合
- プロジェクトオーナーにグループアドレスを設定したい場合
まとめ

カスタムロールについて

カスタムロールとはその名の通り任意のロール作成機能

Cloud IAMのカスタムロール機能とは1つ以上の権限を持つロールを組織もしくはプロジェクトレベルで作成し、それをユーザーに適用することができる機能です。

　※フォルダレベルでの作成は出来ません

出典: Creating and Managing Folders

また、組織やフォルダ、プロジェクトの関係性は上図のような構造になっており、組織IAMで作成したカスタムロールはその配下のフォルダやプロジェクトで利用することが出来ます。さらに組織IAMで設定した役割も同様にその配下のフォルダとプロジェクトに引き継がれます。
ちなみに組織で設定されているIAMよりも強い役割がその配下のプロジェクトで設定されていた場合、そのプロジェクトではより強い方の役割が適用されます。

　※2017年9月29日現在、カスタムロールはbeta版の機能です

カスタムロールの基本概念は3つ

繰り返しになりますが、カスタムロールは1つ以上のIAM権限を組み合わせることで作成します。Cloud IAMでは権限を以下の形式で表現します。

<service>.<resource>.<verb>

serivce: サービス名
resource: サービス内のリソース
verb: 操作

例えば、compute.instances.list権限を持つユーザはGCEインスタンスの一覧表示することができ、compute.instances.stop権限を持つユーザはGCEインスタンスを停止することが出来ます。

このような権限の組み合わせによりユーザはリソースに対しての特定の操作を実行することが出来ます。

カスタムロールの作成方法

ここまでカスタムロールの概要について説明してきましたが、この章では実際にどのようにカスタムロールを作成するか、説明します。
カスタムロールの作成方法としては以下の2種類があります。

Cloudコンソールの画面上から作成する方法
Cloud IAM APIを利用する方法

本記事ではコンソールからの作成方法についてご紹介いたします。また今回はプロジェクトのIAMで作成します。IAM APIにご興味ある方は以下のドキュメントをご参照ください。

Method: projects.roles.create
https://cloud.google.com/iam/reference/rest/v1/projects.roles/create
Method: organizations.roles.create
https://cloud.google.com/iam/reference/rest/v1/organizations.roles/create

作成手順

https://console.cloud.google.com/iam-admin/roles/project?project={projectname} にアクセスします。(projectnameにはIAMを作成したいプロジェクトに置き換えてください)

画面上部の「役割を作成」ボタンを押下します。

各入力項目について説明します。

項目名	意味
名前	カスタムロール名
説明	ロールの説明。作成日や作成した意図などを記述。
ID	カスタムロールID
リリース段階	役割のリリース段階
権限	付与する権限

このうちロール名は後から変更できますが、ロールIDは変更できません。リリース段階はあくまで備考のようなもので機能にさほど影響のあるものではありませんが、無効化するとそのロールを付与してもそのロールの権限は付与されなくなります。

段階	ステータス
アルファ	まだ本番運用の準備が出来ていない状態
ベータ	まだベータの機能が権限に含まれている状態
GA	本番運用可能な状態
無効	無効化状態

各項目を入力したら追加したい権限を選びます。

方法としては…

フィルタ等を使いながら権限を選んでいくか…

既存の役割をベースに(この場合はプロジェクト編集者)権限を選んでいくか…になりますが、一覧性が低かったり各権限の意味が分かりにくいなと思うところも正直あります。個人的には権限の選択部分をYAMLやJSONファイルで管理できるようになってほしいなぁと思いますが、まぁ今後に期待ですね(まだBetaですし)。

カスタムロールが有効なユースケース

細かな権限をユーザに設定することが出来るというのはお分かり頂けたかと思います。が、これって本当に便利なの？実際にどういうケースで使われるの？という方もいるかもしれません。そんな方々の為に想定されるユースケースを挙げたいと思います。

定義されている役割の中にニーズにハマる役割がない場合

多くの場合こちらのケースに当てはまると思います。
例えば、あるユーザ(グループ)にサービスの編集者権限を適用していたとします。それがある日そのサービスのオーナーのみ許可されている一部の操作をお願いしたい、という事象が出てきました。しかし、オーナーにしてしまうと必要以上の権限を与えることになってしまい、多少のリスクがあります。カスタムロール登場以前だとオーナーにその操作を任せるか、一時的にオーナー権限を与えてその後編集者に戻す、といった対応が必要でした。
しかし、カスタムロールを使えばそのような対応を考える必要がありません。そのサービスの編集者が許可されている役割に加えて、追加で許可したい役割のみを加えたカスタムロールを作成すれば良いのです。

プロジェクトオーナーにグループアドレスを設定したい場合

現在IAMの仕様上、プロジェクトオーナーにはグループアドレスを設定することが出来ません。だからといって1アカウントずつプロジェクトのオーナーとして登録していくのは手間ですしメンバーの管理も大変になります。
そこでこれはちょっとした豆知識ですが、既存の定義済みのプロジェクトオーナーにはグループアドレスを設定することは出来ないのですが、プロジェクトオーナーと同等の権限を持ったカスタムロールであればグループアドレスを設定することが出来ます。これによりオーナーと同等の権限を持った役割をグループアドレスに設定することが出来ます。