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

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

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


# redashを導入する上で運用上の要件
* 「クエリを書けるグループ」/「書けないが作られたクエリを全て見るグループ」/「その中の一部のクエリを見れるグループ」に分けたい。
* クエリを書けるグループの中で、誰が何のクエリを投げたか、後で確認できるようにしたい。

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

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

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

# 見せる/見せないの制御のためにやったこと
## データソースとグループを分ける

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

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

その後、以下のようにユーザをグルーピングした。
![ユーザー種別.png](https://qiita-image-store.s3.amazonaws.com/0/75761/98afab90-b3a3-a85e-9c61-9a1f60620f25.png)

### データソースについて
接続先のDatabaseは同じだが、
redashの管理上の名前を変えただけで同じような設定を作成した。

* MasterDB
* MasterDB-public

![architecture.png](https://qiita-image-store.s3.amazonaws.com/0/75761/e0e6edea-95b0-44a9-ab41-3c7f7da49862.png)

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

![architecture2.png](https://qiita-image-store.s3.amazonaws.com/0/75761/89a591b3-e9ab-6c23-8f5d-21de1bdf6dcf.png)


### グループについて
* Default
* Important
* Writer

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

* Defaultグループ

Before
![groups-setting.png](https://qiita-image-store.s3.amazonaws.com/0/75761/12c608a7-5f3e-b45e-9c8a-cc0c7980f183.png)

After
![groupsDefault.png](https://qiita-image-store.s3.amazonaws.com/0/75761/6d8f41bd-d60a-487e-f7a0-033440455f87.png)
MasterDB-publicに対する参照権限のみ与えた



* Importantグループ
![groupsImportant.png](https://qiita-image-store.s3.amazonaws.com/0/75761/2e02c732-5c0b-dad7-9fe2-ad5bcee00771.png)
MasterDB-publicならびにMasterDBに対する参照権限を与えた


* Writerグループ
![groupsWriter.png](https://qiita-image-store.s3.amazonaws.com/0/75761/489eddd8-d902-cde1-4a8b-8561eddcb49d.png)
MasterDB-publicならびにMasterDBに対するFull Access権限を与えた。

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

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

今回は以下のように作成した。
![writer-query.png](https://qiita-image-store.s3.amazonaws.com/0/75761/d9a66f2e-6ce8-8267-f5eb-fa89608eae1b.png)

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


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

![viewByDefault.png](https://qiita-image-store.s3.amazonaws.com/0/75761/44e98849-ad39-3b5b-b1af-5cab9d24a062.png)

MasterDB-Publicしか見えない

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

![viewByImportant.png](https://qiita-image-store.s3.amazonaws.com/0/75761/bf201a2d-8af5-2109-e1bb-4b17de32915b.png)

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

![permisionError.png](https://qiita-image-store.s3.amazonaws.com/0/75761/92387313-17d2-a18c-f118-a423b6d50c03.png)


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

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

![2_anotherUser-log.png](https://qiita-image-store.s3.amazonaws.com/0/75761/415626cc-2af4-8824-c5eb-c8a3fff10ec6.png)

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

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

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

![2_クエリ結果.png](https://qiita-image-store.s3.amazonaws.com/0/75761/b30cfd76-0fb7-76cd-af75-57e64aece26f.png)

そのクエリの結果はどうだったのか。
左のペンボタンをクリックすると、その時の実行結果を確認する事ができる。
![2_結果.png](https://qiita-image-store.s3.amazonaws.com/0/75761/ac8f7626-107d-3e3a-1d88-d96c3fc20bd3.png)

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

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