Taste of Tech Topics

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Kibanaのマルチテナント運用について考えてみた(後編)

こんにちは。
@です😊

この記事は
Kibanaのマルチテナント運用について考えてみた(前編) - Taste of Tech Topics
の後編となります。事前にそちらをご一読ください。

さて、前回の記事では
データが入っているindexに対してアクセス制限をかけることで、見せたくないデータを隠すことができました。
しかし、ダッシュボードが編集できてしまうなどの問題がありました。

ここでは、その対策としてkibana_dashboard_only_userを使ってみます。

ダッシュボードの閲覧専用ユーザー

バージョン5.xまでは自分で.kibanaへのアクセスを制限したroleを作る必要がありましたが、バージョン6からは予めkibana_dashboard_only_userというroleが定義されています。
これをkibana_userの代わりに付与してみます。
f:id:acro-engineer:20180121233236p:plain:w700

使える機能がダッシュボードだけに制限された上、編集などもできなくなっています。
良い感じです。
f:id:acro-engineer:20180121234155p:plain:w700

ダッシュボードの存在を隠す

しかし、dashboard_only_userを使うだけでは「B社のダッシュボードが存在すること」がA社の人間にもわかってしまします。
.kibana indexに対する制御をカスタマイズして、この問題を解決してみましょう。

何をするかと言うと、kibana_userの代わりに、roleA_kibanaといったようなロールを作ります。
(roleA_kibanaを作らず、roleA_adminなどにまとめて設定することも可能です)
f:id:acro-engineer:20180204230710p:plain:w700

設定内容としては、「DashboardとVisualizationは"[A社]"がタイトルに含まれる場合しかアクセスできない」というものになっています。
また、Kibanaの設定(config)や、company_aというindex-patternを読む権限もつけています。

※match_phrase_prefixではqueryがanalyzeされるので、予期せぬ名前がヒットしないよう、注意が必要です。
※本気で運用を考えるなら、saved searchやreportingについてもアクセス制御を考える必要がありますが、それに関しては本記事では考慮しません。

f:id:acro-engineer:20180207012532p:plain:w700

これでuserA_adminからはA社のダッシュボードのみが見えるようになりました。

一応、当初想定していた下記の要件を満たすことができました。

  • 「一部のダッシュボードだけを見せたい」
  • 「編集できないようにしたい」
  • ダッシュボードの存在を知られたくない」

...しかし、少しもやもやが残ります。
この方法では、ダッシュボードなどの作成時に命名の制約が生じるし、ロール定義が煩雑になる可能性が高く、スマートな方法とは言えません。

結局どうするのが良いのか?

さて、回りくどく色々と書きましたが、おそらくelasticsearch + kIbanaのマルチテナント運用をおこなう上で最も現実的な解は「Kibanaをテナントごとに用意する」というところに落ち着くのではないかと思います。(異論は認めます)


先ほど、

Kibanaのダッシュボード自体の情報は、.kibanaというindexに保存されている

と言いましたが、kibanaは設定を変更することで、.kibana以外のindex名でダッシュボードなどの情報を保存することができます。


つまり、A社のユーザーが利用するkibanaの情報は.kibana_aに、B社のユーザーが利用するkibanaの情報は.kibana_bに保存するという運用が可能になります。
そうすれば、kibana用のindexに対して細かく制限をかける必要がありません。


設定に必要な手順は、kibana.ymlを編集しkibana.indexの値を書き換えてKibanaを起動するだけです。

# kibana.index: ".kibana"
kibana.index: ".kibana_a"


こうすることで、elasticsearchのクラスタは単一でも、安全にマルチテナント運用が可能です。
この通り、A社のユーザーは、A社の情報だけが見られます。
めでたし、めでたし😇

f:id:acro-engineer:20180207012532p:plain:w700


おまけ(その他考慮すべきこと)

Kibanaは、DevToolsに関しても使用不可にすることができます。
こちらはkibana.ymlに下記の1行を追加することで使用不可にできます。
(古いバージョンでは、Kibana画面のadvanced settingsから設定できたと記憶しています)

console.enabled: false

興味のある方は試してみてください。

まとめ

  • kibanaのダッシュボード情報などは、専用のindexに保持されている
  • X-Pack Securityの機能で権限を制御できる
  • 現実的にはkibanaのインスタンスをテナント毎にわけるのが良さそう

※テナント数自体が膨大になった場合は、別の手段を考えたほうが良いケースもあるかもしれません

以上です。ツッコミ等あれば是非ご指摘ください。
お読みいただき、ありがとうございました。

Acroquest Technologyでは、キャリア採用を行っています。

  • ビッグデータHadoop/Spark、NoSQL)、データ分析(Elasticsearch、Python関連)、Web開発(SpringCloud/SpringBoot、AngularJS)といった最新のOSSを利用する開発プロジェクトに関わりたい。
  • マイクロサービスDevOpsなどの技術を使ったり、データ分析機械学習などのスキルを活かしたい。
  • 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。


少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
データ分析基盤Elasticsearchを使い倒したいエンジニア募集! - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com