Help us understand the problem. What is going on with this article?

redash運用上の悩みと、それをどう付き合っていくかを考える(考えた)。

More than 1 year has passed since last update.

はじめに

redashはとても便利。
なくてはならないツールの一つになりつつある。

しかし、いざ運用を考えるとロールまわりでいろいろ課題が生まれた。
いかに工夫して課題を回避していったかまとめる。

redashを導入する上で運用上の要件

  • 「クエリを書けるグループ」/「書けないが作られたクエリを全て見るグループ」/「その中の一部のクエリを見れるグループ」に分けたい。
  • クエリを書けるグループの中で、誰が何のクエリを投げたか、後で確認できるようにしたい。

databaseの中には個人情報が入っているものもあるため、
誰がどのクエリを投げ、どのような結果を知ったのか、要はAuditに相当する機能を入れたい。

調査してわかったこと

redash単体では、我々の要件を満たす機能は"普通には"持っていなかった。

しかし、工夫すれば我々の要件を実現できるのではないか、
という仮説が生まれ、少々泥臭い作業だが運用で回避できるかも。という調査結果が出た。

見せる/見せないの制御のためにやったこと

データソースとグループを分ける

ざっくり3種類に分けた。

・SQLを書けるグループ
・SQLを見るグループ(の中で作成された全クエリ見えるグループ)
・SQLを見るグループ(の中で作成された中でごく限られたクエリ見えるグループ)

その後、以下のようにユーザをグルーピングした。
ユーザー種別.png

データソースについて

接続先のDatabaseは同じだが、
redashの管理上の名前を変えただけで同じような設定を作成した。

  • MasterDB
  • MasterDB-public

architecture.png

あくまでもredashで管理するデータソースの名前を変えただけなので、
接続するdatabaseのID/PWは同じにした。

architecture2.png

グループについて

  • Default
  • Important
  • Writer

上記3種類を作成し、それぞれ使用するデータソースと、権限を変えた

  • Defaultグループ

Before
groups-setting.png

After
groupsDefault.png
MasterDB-publicに対する参照権限のみ与えた

  • Importantグループ
    groupsImportant.png
    MasterDB-publicならびにMasterDBに対する参照権限を与えた

  • Writerグループ
    groupsWriter.png
    MasterDB-publicならびにMasterDBに対するFull Access権限を与えた。

クエリを作成する

上記の通り作成するとWriterユーザーのみ(厳密にいうとAdminは無条件で書き込み可能)
クエリを作成することができる。

Writerユーザーは、
誰にでも見せていいクエリをMasterDB-public
制限したいクエリをMasterDB
に書くようにする。

今回は以下のように作成した。
writer-query.png

countryのみMasterDB-Publicにして、一般ユーザーにも見せる事ことにし、
MasterDBは限られたグループ(Important)のみとする

一般ユーザーからの見え方

viewByDefault.png

MasterDB-Publicしか見えない

全参照権限保持ユーザーからの見え方

viewByImportant.png

参照ユーザーでクエリを書く

クエリの作成ボタン自体は消えるわけではないので、Create Queryは押せるが
当然権限を持っていないため、エラーになる。

permisionError.png

誰がどのクエリを投げたのか把握する

dockerで稼働している場合、
redash_server_1
コンテナに誰がログインしたのかがログに出力される

2_anotherUser-log.png

このログの中に、メールアドレスと、その前後にQuery Hashというのが表示される。

Adminユーザーでログインしている状態で
/admin/queryresult
へアクセス。

ログの中に記載のあったQuery Hashを元に検索すると、
どのクエリが実行されたのか確認することができる。

2_クエリ結果.png

そのクエリの結果はどうだったのか。
左のペンボタンをクリックすると、その時の実行結果を確認する事ができる。
2_結果.png

まとめ

MySQLのAuditで制限すればいいじゃないかという議論も出ると思うが、
もしMySQLのAuditで確認するとなると、ユーザー分データソースを作らなければならなくなる。
そのため、redash側で今回は対応することにした。

最後に

他社でどのような運用をしているか知りたいので、ぜひ教えてください。

S-T
10年続けたフリーランスのシステムエンジニアを経て、オンライン英会話会社のインフラにジョイン。金髪のおねーさんが道で迷った時のために英語勉強してます。
https://tsukada.sumito.jp/
rarejob
明治神宮にあるオンライン英会話サービスを提供するベンチャー
https://www.rarejob.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away