Lookerのユーザー管理体制（グループ構成）を考える上でのアイデア

はじめに

Lookerのユーザー管理体制（グループ構成）を更新した際に、こうしたらメンテナンスしやすいグループ構成が作れそうというアイデアがあったのでメモのため記事にしました。

想定読者

• Lookerを導入して、これからグループの構成を考える方
• すでにLookerを使っているが、既存のグループ構成がうまくいないため、更新したい方
  で、すでにLookerのグループ、ロール、パーミッションセット、モデルセット、モデルがなにか分かっている方向け。

グループ構成のアイデア

まず、なぜグループ構成を見直したのか？

なぜグループ構成を見直したかというと、既存のグループ構成の思想が固まっておらず、場当たり的に様々なグループが作成されてしまい管理が大変になっていたためです。　
そのため、ユーザーを新規追加する際に、この人はどのグループに所属させる？どの権限を付与する？のか簡単に把握できないケースが多々ありました。

グループ構成でやったほうが良いと思う制約

いろいろ調べたところ以下の制約の上でグループ構成を考えるのが良いと思いました。

• ユーザーアカウントには権限は直接付与せず、グループに権限を付与する。ユーザーをグループに所属させることで権限を行使できるようにする。

• グループは極力細分化しない。ユーザーはできる限り制限なくモデルにアクセスできるのが理想。（セキュリティの関係でそうもいかないことがあるのであくまで理想です）

• グループは極力変わらない属性に対応させる。おすすめはドメイン（サービス）に対応させる。１企業でも複数のドメイン（サービス）を運営していることはよくありますよね。例えばドメインがA、Bの２つあるなら、それぞれに対応したグループを作成するイメージです。

• グループの数はドメイン x ３つのデフォルトのパーミッションセット（viewer, user, developer）とする。つまり、１ドメイン３つのグループが作成される。

• 上記に関連して、モデルもドメインに対応させる。

• １つのモデル内でデータを出し分ける（一部のユーザーのみ特定のカラムは開示する）ことは極力やめたほうが良い。Lookerではこの管理がとてもしづらいため。

  • もし出し分けをやりたいなら、ユーザー属性を付与する、またはフォルダへのアクセスを設定する必要があるが、モデルと異なりコードで管理しづらいため覚悟が必要。

• グループに対応したロールを作成し、グループとロールは１対１の関係にする。

• パーミッションセットはデフォルトの４つviewer, user, developer, adminしか使わない。

作成するべきグループとモデルセットを洗い出す

グループの構成を考える上で、上記の制約をふまえて、以下のような作るべきグループ一覧表を作ると作業がスムーズです。（表はあくまでサンプルです。）

No	グループ名	グループ概要（加入条件）	ロール名	付与するpermission_set名	付与するmodel_set名	model_setに含まれるモデル
1	admin	Looker管理者	＊グループ名と同名にする	admin	all	all
2	data_team_developer	分析部門所属のLooker開発者（開発権限）	同上	developer	all	all
3	domain_A_viewer	ドメインA関係者（閲覧権限）	同上	viewer	domain_A	domain_Aのモデル
4	domain_A_user	ドメインA関係者（探索権限）	同上	user	domain_A	domain_Aのモデル
5	domain_A_developer	ドメインA関係者（開発権限）	同上	developer	domain_A	domain_Aのモデル
3	domain_B_viewer	ドメインB関係者（閲覧権限）	同上	viewer	domain_B	domain_Bのモデル
4	domain_B_user	ドメインB関係者（探索権限）	同上	user	domain_B	domain_Bのモデル
5	domain_B_developer	ドメインB関係者（開発権限）	同上	developer	domain_B	domain_Bのモデル
6	corporate_viewer	バックオフィス（閲覧権限）	同上	viewer	corporate	corporate
7	corporate_user	バックオフィス（探索権限）	同上	user	corporate	corporate
8	corporate_developer	バックオフィス（開発権限）	同上	developer	corporate	corporate