何番煎じ、、？

はい、、そんな気はするのですが、今回検証用の手元にElasticsearch + Kibana構成を組んだ際に、けっつまづくポイントがちょこちょこあったので、一応メモっておこうと思います。

導入方法

Ubuntuの標準レポジトリには、elasticsearchもkibanaも入っていません。
tar.gzで固めてあるものをElastic社のサイトからDLしてくるか、Elastic社のレポジトリを追加してそこからpkgで導入するかになります。

日本語版のトラップ

Elasticのユーザガイドについて、日本語版は5.4までしか存在しません！！
20220626時点の最新版は8.2（.3）。
日本語のユーザガイドを見てしまうと、非常に古いパッケージを導入することになるので、注意。。
（最初気が付かず、kibanaだけ5.4で入れてしまいました、、）
https://www.elastic.co/guide/jp/index.html

英語版のユーザガイドの手順に素直に従えば、問題なく導入できます。
Ubuntuのレポジトリからの配布はないので、Elasticのレポジトリを追加するか、tar.gzで設定と実行ファイル軍がまとまったものを落としてきて展開するか、のどちらかです。

（脱線）tar.gzとpkg

最初ちゃんとドキュメント読まずに上から導入したので、tar.gzで導入してしまい、後で気がついてpkgで入れ直しましたhttps://www.elastic.co/guide/en/elasticsearch/reference/current/install-elasticsearch.html

ざっと見た感じ、違いはなさそうです。
コンフィグは、パス周りがpkgではちょっと調整されているくらいか。

< #path.data: /path/to/data
---
> path.data: /var/lib/elasticsearch
37c37
< #path.logs: /path/to/logs
---
> path.logs: /var/log/elasticsearch
93c93
< # generated to configure Elasticsearch security features on 26-06-2022 00:48:50
---
> # generated to configure Elasticsearch security features on 26-06-2022 03:52:19

ただし、厄介なのは、自動生成される初期パスワードと、kibanaで接続するためのトークン
tar.gz版でbin/elasticsearchで実行した場合は、自動生成されたパスワードとトークン（有効時間30分）がターミナルに表示されます。
一方、pkgで導入して、systemctlで起動すると、これが見えません。ログにも出力されないっぽい、、

どちらも、コマンドで再設定/再生成できるので、なんか気持ち悪いですが、それで対応ですね。。
まぁ、あるいは、初回起動はsystemctlを使わない、とするほうがいいのかもしれません。なんとも。

パスワードの再発行

上記のとおり、パッケージ導入して、初回からsystemctlを使ってしまうと、自動生成されてたパスワードとトークンがわかんなくなります。
また、パスワードも自動生成なので、任意のものが使えず、やりにくい。
そういうわけで、再設定の処理が必須になります。

# /usr/share/elasticsearch/bin/elasticsearch-reset-password -i -u elastic

elasticsearch-setup-passwordsという実行ファイルも用意されているのですが、そちらを使うとエラーとなり、resetを使うことを求められます。
そもそも「deprecated(将来リリースで消す)」て言われているのでエラー理由とかはちゃんと調べてないです。

-iはインタラクティブモード。これつけないと、自動生成されたパスワードが使われて、それが事後に表示される、という形になります。
-uはユーザ指定。"elastic"というのがディフォの特権ユーザらしいので、このアカウントのパスワードを変えます。

とりあえず動いているかを見るには、

$ curl -k -u elastic https://localhost:9200/

ディフォルトでsslを有効にしていて、自己証明書を作ってしまってくれているので、普通にcurlすると証明書検証に失敗してクライアントがアクセスを自粛してしまいます。
-kは証明書検証をしないオプション。
で、-uはユーザアカウント指定。コマンド実行後パスワード入力が求められ、
対話で、パスワードを聞かれます。ここで、先のパスワードを入力する、と。

トークンの再発行とKibanaの初期設定

こっちも。

# /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

ここで表示されるトークンを、Kibanaで初回アクセスしたら表示されるトークン欄に入れます。
で、６桁数字の入力が求められるので、kibanaを入れているサーバにログインして

# /usr/share/kibana/bin/kibana-verification-code

で表示される数字を入れます。

結構ゴテゴテしてますね。。
Elasticsearchのサーバの持ち主であることをトークン入力で確認して、次に6ケタ数字でKibanaサーバの持ち主であることも確認させる。
うーん、、、まぁやってることは正しいか。
そういうのはkibanaのコンフィグファイルでやるとか、kibanaサーバで叩くとかすれば？という気もしてきますが、トークンに時間制限をつけようとして、設定作業をブラウザという第三者がアクセスできるものでやろうとすると、こうなる、と。
。。。ユーザとパスワードをコンフィグに書かせる旧来的なSQLサーバとの接続方式と比べれば、遥かにセキュアだとは思うのですけれど。

ちなみに、Elasticsearchのelasticのユーザ名/パスワードは、KibanaのWebUIのログインの際に使います。

ログを流し込んで見る

とりあえずファイルをアップしてみる。

とりあえずファイルをアップするだけなら、kibanaからできるようです。
左上の三本線-Management/Integrationsをクリック。
更に左のタブを下まで降りて、Upload a fileをクリック。
で、右のUpload a fileをクリック。

そもそもIntegrationsというのは、Elasticのサイトを見ると「Connect and collect with integrations」とあり。
データ取り込み用の機能群、、、という理解でいいのかな。
AWS EC2やらBoxやらMongoDBやらやら、非常に豊富です。

。。豊富なのはいいのですが、運用用途でガッチガチに要件を固めた環境で使うという思想で見てしまうと、逆に余分なものが大量に入っているように見えてしまって、なんか気持ち悪さがあるんですよね、、。
そういう時代ではないのでしょうけれど、なんとも。

定期的に流し込むなら

Beats(Filebeat)短期か、Filebeat + Logstashの組み合わせ。
あるいはfluentd。

とりあえずシンプルにfilebeat短期で。

# apt install filebeat

で、/etc/filebeat/filebeat.ymlを設定。
https://www.elastic.co/guide/en/beats/filebeat/8.2/filebeat-installation-configuration.html

接続設定

例だとパスワードを平文で入れてしまっているので、ちゃんと正しいやり方にしておく。
https://www.elastic.co/guide/en/beats/filebeat/8.2/keystore.html

# filebeat keystore create
Created filebeat keystore

# filebeat keystore add ES_PWD
Enter value for ES_PWD: 
Successfully updated the keystore

あとはsslのフィンガープリントを入れろとある。
フィンガープリントは以下で調べる。

# cat /etc/elasticsearch/certs/http_ca.crt | openssl x509 -sha256 -fingerprint -noout | cut -d "=" -f 2 | sed "s/://g"

で、まとめると、以下の通り。

# cat /etc/filebeat/filebeat.yml
(抜粋)
output.elasticsearch:
  hosts: ["localhost:9200"]

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  username: "elastic"
  password: "${ES_PWD}"

  ssl:
    enabled: true
    ca_trusted_fingerprint: "<上で調べたやつ>"

パスワードは、"${ES_PWD}"とすると、先にkeystoreに登録したものを使ってくれる。
protocolは、明にhttpsにしないと、httpでつなぎに行っちゃう。
フィンガープリントが結構厄介で手こずりました。。
最初はopenssl s_client -connectで撮ってたんですけど、これやるとサーバ証明書の方になっちゃう。入力すべきはCAの方（いや、そう書いてあるだろと言われりゃそうなんですけど、、）。

トークンを使う方法？もあるっぽいので、ここは改めて見返して置く必要がありますね。。

飛ばすログの設定

"module"という扱いで、飛ばすログを決めるようです。
テストがてらauditdのログだけ飛ばします。

# filebeat modules enable auditd
Enabled auditd

モジュールの設定は/etc/filebeat/modules.dの下に入っていて、最初はauditd.yml.disabledとなっています。
上記のコマンドを叩くと名前がauditd.ymlに変わります。
でも中身はもとのまま(enabled: false)になっているので、マニュアル通りに直します。

# cat /etc/filebeat/modules.d/auditd.yml
- module: auditd
  log:
    enabled: true
    var.paths: ["/var/log/audit.log*"]

で、シンタックスチェック。

# filebeat test config -e

ずらずら出てきて、最後に"Config OK"がでればOK。

で、飛ばしてみる。

まずはテスト。

# filebeat setup -e

設定がうまくいっていれば、ズラズラとログが出て、Elasticsearch側に.ds-filebeat..というようなインデックスが作られます。

ただ、、Kibana起動していないと最後にエラーが出ます。
Kibanaにダッシュボードを登録する機能が強制で動くらしく。
設定のsetup.kibanaという部分だと思うのですが、disableの方法がわからず。

EOL

利用する以上、常に把握しておかないといけな情報です。
https://www.elastic.co/jp/support/eol

「Elasticプロダクトのサポート期間はメジャーリリースのGA/一般公開日から18か月です。」
8.2.2なら、8が「メジャーリリース」、8.2が「マイナーリリース」、8.2.2が「メンテナンスリリース」だそうです。
ただし、EOL一覧を見るに、「マイナーリリース」について一般公開から18ヶ月、と設定しているぽいです。どっちだよ。。
実際には7.0と8.0の間が３年弱あるところを見るに、「マイナーリリースの一般公開から18ヶ月」なのでしょうね、きっと。

いずれにしても、18ヶ月というと結構際どい数字ですが、感覚的にはRHELと似たようなもんですね。
マイナーはパッチ気分で積極的にガンガン上げていけ、ということで。
7系でいうと、7.0のリリースが2019/4(GIT情報より、他にいいソース見つからず、、）、で、（いまのところ)7系最後の7.17が9.0.0のリリース予定日の2023/8/2まで。
マイナーバージョンを積極的に上げていれば、4年ちょいはもつ、と。

ubuntuなら、そのくらいでLTS板もEOLしますし。

一応、cvedetailsで過去のElasticsearchの脆弱性情報を見ても、全然ヒットはないですが、、それが逆に怖い。。
また、javaもセットで配布される形で、そちらの脆弱性が出た場合は見落としが非常にしやすくなります。
むしろそっちのほうが怖いか。
同梱されているjavaのバージョンを後追いでざーっと調べてみようかな。。

とりあえず

今日はここまで。
取り込んだデータの分析とかもやっていないので、ほんとに取り込めてるか自体も怪しいですが、そこらはまた改めて。
あと、セキュリティ設定/運用（脆弱性管理）は一回丁寧に考えないとアブなさそう。
そしてリソース問題の考え方と、、やるべきことはいっぱいだ。。