この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Lookerでは利用の際に「ユーザー」を作成し、利用者はそのユーザーを使ってLookerにログインしてそれぞれの作業を行います。ユーザーには基本的な設定項目の中に、そのユーザーがどのような操作をどういった範囲、リソースに対して行えるのかどうかを定めている「ロール」という概念が備わっています。当エントリではその「ロール」周りについて基本的な部分を見ていきたいと思います。
目次
「ユーザー作成」基本操作実践
まずはざっくりな流れで、ユーザーがどの様に作成されるか、作成したユーザーはどの様にして利用開始されるかについて見てみたいと思います。「ユーザー作成」が可能な権限のユーザー(今回は管理者権限所有者)でLookerにログインし、[Admin]→[Users]から[Users]を選択。
現行存在しているユーザーの一覧が表示されます。上部にある[Add Users]を押下。
ユーザー作成の入力フォームが表示されます。最低限必要となる情報は以下の内容です。ここでは「任意の複数人ユーザー」のメールアドレスを追記し、いずれも管理者権限「Admin」権限を所有し「User」というグループに所属するユーザーを作成してみることにしました。設定出来たら[Add Users]を押下。
- Email Addresses：登録ユーザーのメールアドレス。複数アドレスを一括登録可能(その際はカンマ、セミコロン、改行で並べる)
- Send Setup Emails：サインアップに関するメールを送るか否かを選択。
- Roles：所定の権限を持つ、セットアップ済みのロールを選択。
- Groups：ユーザーの所属グループ。
処理完了。何ともシンプルなものです。[Done]を押下してメニューに戻ります。
作成対象となるユーザーの元には、以下の様なメールが届きます。[Activate Your Account]を押下。
Lookerのユーザー作成画面に遷移します。氏名＆パスワードを設定、使用許諾のチェックも選択して[SUBMIT]を押下。
ユーザーの作成及びLookerへのログインが完了しました。
自身のユーザー情報編集画面は以下のような内容となっています。
Lookerにおけるユーザー周りの概念について見てみる
ユーザー作成から実際に作成されたユーザーを使ってLookerプラットフォームにログインするまでの流れは上記の通りです。非常にシンプルで分かりやすかったですが、その中で幾つかキーワード・ポイントとなりそうなところが出てきていましたのでそれぞれ内容を確認してみたいと思います。
ユーザー(User)
ユーザー個々の要素・状態を表すもの。
グループ(Group)
ユーザーが所属する任意の集団。
まぁ、このユーザーとグループについては特に混乱するものでも無いですね。
ロール(Role)
ユーザーに対して個別に権限を割り当てたい場合、この「ロール(Role)」を選択させる事が出来ます。Lookerには「ロール」と「パーミッション(Permission)」という概念があり、これらの組み合わせで権限を細かく制御出来るようです。
ロールはユーザーにもグループにも適用出来るようですが、Looker的には「グループにロールを適用させ、ユーザーをグループに追加する事でアクセス制御を行う」ことを推奨しています。この辺りは権限周りを取り扱うシステムではお馴染みの方法ですね。
尚この「ロール」についてはセットアップ済みのもの以外にも、カスタムで作成することも可能です。
ロールは更に以下の要素に分類されます。
ロール(Role)
Lookerの特定のモデルセットに対してユーザーまたはグループが持つ権限を定義したもの。1つの権限セットと1つのモデルセットを組み合わせて作成します。モデルについては下記をご参照ください。
組織内の任意の役割の名前(管理者、Looker開発者、財務チームなど)にちなんで名前を付けるのが一般的ですが、独自の命名規則を適用するでも全く問題ありません。その辺りはご自由に...といったところでしょうか。
ユーザーはLooker内で複数のロールを持つことが出来ます。社内で複数の役割を担うユーザーが必要な場合や、モデルへの複雑なアクセスを実現する場合に有効です。
Lookerでは、新しいインスタンスに対して、Lookerでは以下のデフォルトロールを割り当てることが出来ます。
- Admin
- Developer
- User
- Viewer
デフォルトロール毎に出来ることの一覧は下記ページの「Default Permission Sets」をご参照ください。
パーミッションセット(Permission Set)
ユーザーまたはグループが実行出来ることを定義したもの。ユーザーまたはグループに割り当てる権限の組み合わせを選択して作成し、ロールの一部として使用します。
パーミッションは以下いずれかの方法で適用させることが出来ます。
- モデル固有：このタイプの権限は、同じ役割の一部であるモデルセットにのみ適用されます。
- インスタンス全体：このタイプの権限は、Lookerインスタンス全体に適用され、[Admin]メニューの一部を管理者以外のユーザーに公開します。管理者以外のユーザーは、そのコンテンツを使用する特定のモデルへのアクセスが許可されていなくても、Lookerインスタンス全体のコンテンツ及び機能にアクセス出来ます。
デフォルトで用意されているロールは、許可出来る「パーミッション」の「セット」をそれぞれ付与されています。下記はPermission Setsのキャプチャですが、ロールに応じたパーミッションがそれぞれ異なることが確認出来ます。
「パーミッション」の種類、すなわち「どういう操作が許可対象となっているのか」も気になるところです。Permissions Listの項ではその内容が説明されているのでポイントを抜粋してみます。階層構造＝依存関係があることを意味します。
- access_data 【モデル固有:Lookerからデータにアクセス】
- see_lookml_dashboards 【モデル固有:スペースからダッシュボードを作成、LookMLで定義/全てのLookMLダッシュボードを含むLookMLダッシュボードスペースを閲覧可能】
- see_looks 【モデル固有:スペース内に保存されたLookを閲覧】
- see_user_dashboards 【モデル固有:スペースからダッシュボードを作成、LookMLで定義/Spacesでユーザー定義のダッシュボードを表示可能】
- explore 【モデル固有:探索(Explore)の使用、レポートの生成】
- create_table_calculations 《インスタンス全体:テーブル計算およびカスタムフィールドを表示、編集、追加》
- save_content 《インスタンス全体:Lookとダッシュボードの保存及び編集》
- create_public_looks 【モデル固有:インスタンス全体:保存されたLookをパブリックとしてマーク】
- download_with_limit 【モデル固有:クエリをダウンロード(5000行までの制限あり)】
- download_without_limit 【モデル固有:クエリをダウンロード(制限無し)】
- schedule_look_emails 【モデル固有:電子メールでデータ配信を送信またはスケジュール/ホワイトリストに準ずる形】
- schedule_external_look_emails 《インスタンス全体:電子メールでデータ配信を送信またはスケジュール/ホワイトリスト準拠無し》
- send_to_s3 《インスタンス全体:Amazon s3バケットにデータ配信を送信またはスケジュール》
- send_to_sftp 《インスタンス全体:sftpを介してデータ配信を送信またはスケジュール》
- send_outgoing_webhook 《インスタンス全体:Webhookを介してデータ配信を送信またはスケジュール》
- see_sql 【モデル固有:探索でにSQLタブにアクセス、クエリによって発生したSQLエラーを確認】
- see_lookml 【モデル固有:LookMLへの読み取り専用アクセス】
- develop 【モデル固有:LookML開発】
- deploy 《インスタンス全体:自分のローカルのLookMLの変更を本番環境にプッシュ》
- support_access_toggle 《インスタンス全体:Lookerアナリストによる自分のLookerインスタンスへのアクセスを有効または無効に設定》
- use_sql_runner 【モデル固有:SQL Runnerを使用して、許可されている接続に対して生のSQLを実行】
- see_drill_overlay 【モデル固有:ダッシュボードのタイルにドリルした結果を確認】
- manage_spaces 《インスタンス全体:スペースを作成、編集、移動、削除》
- manage_homepage 《インスタンス全体:すべてのLookerユーザーが自分のパーソナライズドホームページで表示するコンテンツを編集してサイドバーに追加》
- manage_models 《インスタンス全体:LookMLモデルと特定のDB接続セットをマッピング》
- create_prefetches 《インスタンス全体:プリフェッチAPIエンドポイントへのAPI呼び出しを許可》
- login_special_email 《インスタンス全体:他のログインメカニズムが有効になっている場合でもユーザーに従来の電子メール/パスワード認証情報ログインを許可》
- embed_browse_spaces 《インスタンス全体:シングルサインオン（SSO）埋め込み用のコンテンツブラウザを有効》
- see_queries 《インスタンス全体:Lookerの[管理]セクションに[クエリ]ページを表示》
- see_logs 《インスタンス全体:Lookerの[管理]セクションに[ログ]ページを表示》
- see_users 《インスタンス全体:ユーザーページを表示》
- sudo 《インスタンス全体:「ユーザー」ページの「Sudo」ボタンをクリックすることで、他のユーザーをsudoすることを許可》
- see_schedules 《インスタンス全体:Lookerの[Admin]セクションに[Scheduler Plans and History]ページを表示》
- see_pdts 《インスタンス全体:Lookerの[管理者]セクションに[PDT]ページを表示》
- see_datagroups 《インスタンス全体:Lookerの[Admin]セクションにある[Datagroups]ページを表示》
- update_datagroups 《インスタンス全体:Lookerの[Admin]セクションの[Datagroups]ページでデータグループを起動やキャッシュをリセット》
- see_system_activity 《インスタンス全体:Lookerインスタンスに関する使用状況、履歴、その他のメタデータを表示》モデルセット(Model Set)
ユーザーまたはグループが表示出来るデータとLookMLフィールドを定義したもの。ユーザーまたはまたはグループがアクセス権を持つべきLookMLモデルの組み合わせを選択して作成し、ロールの一部として使用します。
「モデルセット」は2つの機能を実行するものとして考えることができます。
- 1.モデルセットは、自分のLookML内のどのモデルに権限を適用するかを制御する(それらの権限がモデル固有の場合)
- 2.各モデルは特定のDB接続に接続し、特定のLookMLフィールドを含むため、モデルセットによってユーザーが表示できるデータおよびLookMLフィールドが制限される
ロール・パーミッションセット・モデルセットの関連性について
Building Blocks You’ll Need to Understand(Roles)のページに これらの概念を説明したパートがありましたので見てみましょう。
ロールは、権限セットとモデルセットの組み合わせです。パーミッションセットはロールが何をすることが出来るのかを定義し、モデルセットはロールがどのLookMLモデルを見ることが出来るかを定義します。
ロールを作成すると、そのロールを個々のユーザーまたはグループに割り当てることが出来ます。個々のユーザーに幾つかの役割を追加し、そのユーザーが属するグループにも他のロールを追加していた場合、そのユーザーはまとめられたそれら全てのロールを継承します。幾つかの権限はあなたの全体のLookerインスタンスに関連していますが、他のものは同じロール内のモデルにのみ適用されます。
まとめ
というわけで、Lookerにおける「ロール」の考え方についての紹介でした。状況や用途に応じた権限付与の行い方をバリエーション豊かに行えそうなので、実業務に照らし合わせた形で権限を制御するのに困ることは無さそうですね。実際にロールをカスタマイズして付与・活用する方法についても機会を見て掘り下げていきたいと思います。
24
