Metabaseの権限モデル入門

Metabaseでは、閲覧者と分析者で必要な権限が違う。閲覧者には作成済みの表やグラフだけを見せたい。分析者には元データから新しい分析を作らせたい。Metabaseは、この2つを別の権限として扱う。

用語と権限の2軸

Metabaseの権限は、database、question、dashboard、collectionといった管理対象に紐づく。

Metabaseの権限は次の2種類に分かれる。

dashboardの表示は、保存済みのquestionやdashboardが置かれたcollectionへの権限で決まる。そのため、dashboardを共有するだけなら、元データを自由に調べるdata permissionまで渡す必要はない。

一方、新しいquestionを作る人は、画面で元データに対するqueryを組み立てる。そのため、参照先のdatabaseやtableへのdata permissionも必要になる。

ただし、「見る」と「作る」は権限の種類であり、権限を置く対象そのものではない。Metabaseの管理対象は4つの層に分けられる。元データ、意味付け、保存済み分析、整理と共有である。この層単位で、どこに「見る」権限と「作る」権限を置くかを特定できる。3つに絞ると、modelやmetricのような分析用の入口が、元データか保存済み分析かが曖昧になりやすい。

• 元データ層
• 意味付け層
• 保存済み分析層
• 整理と共有層

これはMetabase公式の分類名ではなく、権限の置き場所を整理するための区分である。

権限設計の対象を4つの層に分ける

4つの層は、dashboardを開いたときにどの管理対象を経由して元データへたどるかを示す構造である。

元データ層のdatabase、table、fieldは、Metabaseが接続先データベースから同期する構造である。権限設計では、まずここで「そもそも見せてよいデータか」を見極める。

意味付け層は、元データを分析に使いやすくする層である。Metabaseのmodelsは、よく使う分析の入口に整えた派生テーブルとして扱える。新しいquestionの出発点にもなる。metricsは、チームで使う重要な数値の公式な計算方法である。

保存済み分析層では、questionとdashboardを区別する。questionはクエリ、結果、可視化を保存した分析単位で、dashboardは複数のquestionを並べる画面である。利用者に見えるのはdashboardでも、権限上はdashboard内のquestionと参照元tableまでたどる必要がある。

整理と共有層のcollectionは、単なるフォルダではない。Metabaseのcollection permissionsは、保存済みquestion、dashboard、modelを誰に見せるかを決める。編集や移動を誰に許すかもcollectionで決める。

権限モデルは2軸で重ねる

Metabaseの権限モデルは、collection権限とdata permissionの2軸で構成される。collection権限は、保存済みdashboardやquestionを開けるかを決める。data permissionは、元データにqueryを作れるかを決める。この対応を分けると、閲覧できない原因とqueryを作れない原因を別々に追える。

この2軸は代替関係ではない。dashboardを見るには、そのdashboardと中のquestionが置かれたcollectionへのaccessが要る。新しいquestionを作るには、参照先databaseやtableへのdata permissionが要る。

group（権限をまとめるユーザー集合）も別に考える。Metabaseの権限はgroup単位で付けるため、ユーザーが複数groupに入ると権限は広い方へ寄る。あるgroupで広いdata permissionを持つユーザーは、別groupで閲覧専用に絞れない。

collection権限は保存済みコンテンツの入口を決める

collection権限にはCurate access、View access、No accessがある。

collection権限は、Metabase内に保存されたdashboard、question、modelへの操作許可である。接続先tableに対して、新しいqueryを作る許可までは含まない。

Metabase公式のdata permissionsドキュメントによると、既存questionのquery変更にはdata permissionsが必要になる。data permissionsは、参照元データ（underlying data）へのアクセス許可を指す。新規question作成にも同じ権限が必要になる。

collectionにreadを持つviewerだけがdashboardを取得できる。grantのないuserは同じdashboardを取得できず、保存済みquestionの実行も403になる。

collection権限は、保存済みコンテンツの入口を制御する。dashboardを共有する場合は、dashboard自体のcollectionを確認する。あわせて、dashboard内のquestionが置かれているcollectionも確認する。

中のquestionが別collectionにあるなら、そのcollectionへのaccessも必要になる。

data permissionは元データの探索範囲を決める

data permissionは、database、schema、tableに対して、どのデータを見られるかを決める。あわせて、どの方法で新しいqueryを作れるかも決める。

Create queriesは新しいquery作成を制御する

API上は、data graphの項目としてview-dataとcreate-queriesが分かれる。create-queriesの値は3段階ある。query-builder-and-nativeは、画面操作（GUI）で組むquery builderと、SQLエディタに直接書くnative queryの両方を許す。query-builderはquery builderだけを許し、native queryによる生SQLは塞ぐ。noは新しいquery自体を作らせず、保存済みquestionの実行だけを残す。

保存済みquestionの閲覧と新しいquery作成は、権限上の対象が違う。Create queriesを外しても保存済みquestionの実行は通る。同じユーザーが同じtableへad-hoc queryを送ると403になる。

つまり、閲覧専用ユーザーにdashboardを見せるために、Create queriesまで渡す必要はない。逆に、分析者が自分で新しいquestionを作るなら、対象data sourceに対するCreate queriesが必要になる。

query-builderは中間の段階である。GUIでの新規探索は許しつつ、native queryによる生SQLは塞ぐ。SQLを直接書かせたくない分析者には、この段階が合う。

View dataのBlockはPro/Enterprise側の機能

View dataは別の論点である。Metabaseのdata permissionsによると、View dataの細かな制御はPro/Enterprise planの機能である。OSSではCan view相当が既定になる。

Metabase OSS版（v0.62.3.2）では、View dataをBlockする要求はplan制限としてHTTP 402で拒否される。

ユースケース1: 社内分析者には探索権限と作業用collectionを渡す

社内分析者は、自分でquestionを作る役割である。必要ならdashboardへ整理する。この場合は、対象databaseにCreate queriesを付ける。

SQLを直接書く必要があるroleだけnative queryを許可する。

collection側では、作業用collectionにCurate accessを付ける。分析者はquestionを保存し、説明を直してdashboardへ配置できる。

このユースケースでは、分析者向けの広いdata permissionを閲覧者groupと共有しない。group権限は足し算になる。あるgroupで広い権限を持つと、別groupで絞っても広い方が勝つ。

ユースケース2: 閲覧専用ユーザーにはView accessと保存済みquestionだけを渡す

閲覧専用ユーザーは、作成済みdashboardを見るだけの役割である。新しい分析を作らないなら、Create queriesを付けず、閲覧用collectionへのView accessを中心に設計する。

この組み合わせでは、保存済みquestionの結果は見られるが、新しいad-hoc queryは作れない。保存済みquestionはcompletedになる。同じtableへのad-hoc queryはmissing-required-permissionsで失敗する。

運用上は、dashboardとそれを構成するquestionを閲覧専用collectionへまとめる。questionだけが別collectionにあると、dashboardを開けても一部のカードで権限エラーになる。Metabaseのdocsも同じ条件を説明している。dashboardが他collectionのquestionを含む場合、そのcollectionへのviewまたはcurate accessが必要になる。

ユースケース3: 外部共有ではcollectionと行と列の分離を分ける

共有用collectionは専用にする

外部共有の相手は、顧客や取引先のように社外からMetabaseを参照する人である。見せる対象は共有用dashboardとquestionだけに絞る。専用collectionをView accessにし、Create queriesは付けない。作業用collectionや内部向けdashboardはNo accessにする。

行と列は別層で分ける

collectionを分けても、同じtable内の行は自動では分かれない。たとえば共有先Aと共有先Bの行が同じtableにある場合、dashboardだけを分けても足りない。questionがtable全体を集計すれば、数字は混ざる。

この場合に検討するのがrow and column securityである。Row and column securityはPro/Enterprise planの機能で、同じtableをユーザー属性に応じて違う見え方にする。たとえば共有先IDのuser attributeで、ログインユーザーに対応する行だけを見せる。

制約もある。SQL questionの結果とpublic linkには、row and column securityを後から重ねられない。制限対象の列を含むSQL questionは、admin-only collectionに置く必要がある。public linkはログインユーザーを前提にしないため、user attributeによる行制御の材料がない。

OSSで同じ要件を扱うなら、Metabaseの外側で分ける。共有先ごとのdatabase、schema、viewを作る。もしくは接続先database側のrow-level securityを使う。Metabaseのcollectionは、その分けた後の保存済みコンテンツを見せる層として使う。