Seite wählen

NETWAYS Blog

Achtung Handlungsbedarf: Kibana schreibt sensitive Benutzerinformationen im Log mit

Kibana Insertion of Sensitive Information into Log File (ESA-2023-25)

Und erneut wurden in den Kibana-Logs in bestimmten Fehlerfällen sensible Informationen gefunden. Wir empfehlen dringend ein Update auf Kibana 8.11.1. In diesen Fällen werden Anmeldeinformationen des Benutzers „kibana_system“, API-Schlüssel und Anmeldedaten von Kibana-Endnutzern in das Log geschrieben.

Hier der Post zum CVE ESA-2023-25

Betroffene Versionen

Kibana nach 8.0.0 und vor 8.11.1

Nicht betroffene Versionen

Kibana Versionen 7.x.x

Schweregrad : 9,0 (Critical)

Handlungsablauf

Es besteht also bereits Handlungsbedarf. Im Folgenden wird ein möglicher Handlungsablauf beschrieben:

  • Aktualisierung von Kibana auf  8.11.11
  • Identifizieren ob ihr betroffen seit. Genau beschrieben hier
    • Beispiel für eigene Elastic Stack Instanz mit Stack Monitoring:
      message: ("headers" AND "x-elastic-product-origin" AND "authorization")

      gesucht mit Verwendung des Agents in „logs-kibana.*-default“ oder bei Verwendung des Filebeats „filebeat-{version}“

  • Beheben der Schwachstelle (Remediation Actions) . Beispiel eigene Instanz:
    • Rotation des Passwords für den User „kibana_system“ mittels API oder Passwort-Reset Tool
      bin/elasticsearch-reset-password -u kibana_systems
      curl -X POST "localhost:9200/_security/user/kibana_system/_password?pretty" -H 'Content-Type: application/json' -d'
      {
        "password" : "new_password"
      }
      '
      
    • Für alle Kibana-Endanwender  welche in den Logs gefunden wurden, könnt ihr die Kibana UI oder die Change passwords API wie oben beschrieben verwenden.

Für alle weiteren Varianten wie ECE, ECK und Elastic Cloud findet ihr alles genauer beschrieben unter den Punkten Identification and Remediation of credentials in logs und Remediation Actions

Hinweis

Es gilt auch hier ist eine Aktualisierung von Elasticsearch auf die Version 8.11.1 empfohlen. Bei jeder Aktualisierung gilt wie immer Release Notes lesen und „Breaking Changes“ beachten.

Anmerkung der Redaktion

Wo gehobelt wird , da fallen auch Spähne

Deshalb ist Handeln erforderlich. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

NETWAYS GitHub Update Juli 2023

Willkommen beim NETWAYS GitHub Update, unser monatlicher Überblick über unsere neuesten Releases.

Im Juli 2023 haben wir wieder einen ganzen Schwung spannender Updates an den Start gebracht. Dazu gehören unter anderem eine Aktualisierung der Golang Bibliothek für Check-Plugins, Version 1.2.5 unseres beliebten Icinga Installers sowie ein neuer Release des NETWAYS Support Collectors.

Zudem haben die Check-Plugins für Bareos, Elasticsearch und Logstash einige Änderungen spendiert bekommen!

Wenn du in Zukunft Updates direkt zu Release erhalten willst, folge uns einfach auf GitHub: https://github.com/NETWAYS/

check-bareos Release v2.0.0

Wir haben diesen Monat einen großen Refactor des Check Plugins durch, damit werden wir das Tool in Zukunft besser warten können. Gibt viele Änderungen, am besten die Release Notes lesen.

Changelog

  • Hinzugefügt: Viele neue Unittests!
  • Hinzugefügt: CLI Parameter unterstützen Thresholds
  • Ausgabe normalisiert und erweitert
  • Diverse Bugfixes

https://github.com/NETWAYS/check_bareos/releases/tag/v2.0.0

go-check Release v0.5.0

Ein etwas größeres Release unserer Golang Bibliothek für Check Plugins. Mit diesem Release haben wir einiges an Code aufgeräumt.

Changelog

  • Einige Abhängigkeiten entfernt
  • Breaking Change: metric und benchmark Pakete entfernt
  • Breaking Change: http/mock Paket entfernt
  • Breaking Change: Ältere Funktionen entfernt
  • Bugfix: Fehler in der Ausgabe von PartialResult gefixt
  • Viele kleine Fixes unter der Haube

https://github.com/NETWAYS/go-check/releases/tag/v0.5.0

check-elasticsearch Release v0.3.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Ingest Pipelines
  • Refactor um teilweise kompatibel mit OpenSearch zu sein
  • Viele Optimierungen unter der Haube

https://github.com/NETWAYS/check_elasticsearch/releases/tag/v0.3.0

check-logstash Release v0.9.0

Changelog

  • Hinzugefügt: Neuer Subcheck für Logstash 8 Pipeline Metriken
  • Hinzugefügt: Neuer Subcheck für Logstash Pipeline Reload Fehler

https://github.com/NETWAYS/check_logstash/releases/tag/v0.9.0

support-collector Release v0.9.0

Changelog

  • Hinzugefügt: Viele neue Kollektoren (Elastic Stack, Prometheus, Graylog, MongoDB, Foreman, diverse Webserver)
  • Hinzugefügt: Neue CLI Option um sensitive Daten zu entfernen
  • Hinzugefügt: Das Tool sammelt jetzt auch teilweise Logdateien ein
  • Viele Abhängigkeiten unter der Haube aktualisiert

https://github.com/NETWAYS/support-collector/releases/tag/v0.9.0

icinga-installer Release v1.2.5

Changelog

  • Bugfix: Weitere PHP und Apache Konfiguration wird nun von Puppet verwaltet
  • Bugfix: Puppet Daemon auf Debian/Ubuntu deaktiviert

https://github.com/NETWAYS/icinga-installer/releases/tag/v1.2.5

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

Elasticsearch: Herzstück des Elastic Stack

Nachdem wir uns im letzten Blogpost den Elastic Stack im Allgemeinen angesehen haben, wollen wir uns heute auf den Teil Elasticsearch konzentrieren. Gerade zum Thema Elasticsearch gibt es aufgrund der Mächtigkeit des Tools eine Vielzahl an Fakten und Features.

Wie im Titel schon erwähnt, ist Elasticsearch das Herzstück des Elastic Stack. Elasticsearch ist eine Such- und Analytics-Engine, die als Kernaufgabe die Speicherung der (Log-)Daten übernimmt. Im Vordergrund stehen hier die hohe Performanz, die Relevanz von Daten kann granular geregelt werden und ein Elasticsearch Cluster kann problemlos skaliert werden.

 

Features von Elasticsearch

  • Suchanfragen sind kombinierbar – egal, ob strukturiert oder unstrukturiert. Suchparameter können selbst gesetzt werden, als Beispiel Metriken oder Geodaten. Hier kann aber indviduell angepasst werden.
  • Volltextsuche und Verstehen von Tippfehlern
  • Ranking von Suchergebnissen – nach individueller Definition können Suchergebnisse sortiert werden, z. B. nach Datum, Beliebtheit, Häufigkeit des Auftretens von Begriffen. Die Einstellungen für diese Rankings können auch per Funktion definiert werden.
  • Analysieren von Milliarden von Logfiles – mit Hilfe von Aggregationen kann mehr als nur eine Facette dargestellt werden. Die Analyse ermöglich das Erkennen von Zusammenhängen, Mustern und Trends sowie einen regelmäßigen Überblick.
  • Hohe Performance – jedes Log File wird mit einem Index versehen. Daten werden automatisch auf den Nodes verteilt, um ein perfektes Balancing zu erreichen.
  • Skalierbarkeit – vom One-Node-Setup im Testumfeld hin zur Produktivumgebung. Hier muss nichts neu aufgesetzt werden, sondern es wird skaliert durch das Hinzufügen von Nodes. Konfigurationen werden im Cluster automatisch verteilt. (Elastic empfiehlt für Produktivumgebungen mindestens drei Nodes)
  • Cluster-übergereifende Replikation – hier wird in einer verteilten Umgebung gearbeitet, so dass der Cluster und die darin enthaltenen Daten auch bei Hardware- oder Netzwerkausfall verfügbar sind. Auch kann jederzeit ein Hot Backup einspringen.
  • Elasticsearch Node weg? Der Cluster erkennt dies und erstetzt den verschwundenen Knoten mit einer Replika.

 

Ein sehr interessanter Aspekt ist auch, dass das Alternativprodukt Graylog auch auf Elasticsearch aufbaut. Das heißt, wer sich mit Elasticsearch auskennt, kann gleich zweimal punkten! Woher Ihr das Wissen bekommt? Natürlich von uns!

Über unsere Website könnt Ihr direkt Schulungen buchen für Elastic, aber auch für viele andere Produkte wie Graylog oder Icinga 2. Solltet Ihr Euch unsicher sein oder weitere Infos benötigen, dann kontaktiert einfach unsere Kollegen über events@netways.de.

Wer kurzfristig was lernen möchte, dem empfehle ich unsere Webinare. Hier findet hier auf unserer Website die bereits gehaltenen Webinare sowie Ankündigungen für neue. Insbesondere haben wir kürzlich Webinare zum Thema Elastic hinzugefügt.

Wir haben Euer Interesse an Elasticsearch und dem Elastic Stack geweckt? Ihr wollt vielleicht wissen, ob die Tools als Lösung für Eure Use Cases in Frage kommen? Dann kommt einfach auf uns zu! Wir sind erreichbar unter sales@netways.de oder über unser Kontaktformular.

Secure Elasticsearch and Kibana with an Nginx HTTP Proxy

Elasticsearch provides a great HTTP API where applications can write to and read from in high performance environments. One of our customers sponsored a feature for Icinga 2 which writes events and performance data metrics to Elasticsearch. This will hit v2.8 later this year.
We’re also concerned about security, and have been looking into security mechanisms such as basic auth or TLS. Unfortunately this isn’t included in the Open Source stack.
 

Why should you care about securing Elasticsearch and Kibana?

Modern infrastructure deployments commonly require Elasticsearch listening on an external interface and answering HTTP requests. Earlier this year we’ve learned about ransomware attacks on MongoDB and Elasticsearch too.
During development I’ve found this API call – just clear everything inside the database.

[root@icinga2-elastic ~]# curl -X DELETE http://localhost:9200/_all
{"acknowledged":true}

I don’t want any user to run this command from anywhere. You can disable this by setting „action.destructive_requires_name“ to „true“ inside the configuration, but it is not the default.
A similar thing is that you can read and write anything without any access rules in place, no matter if querying Elasticsearch or Kibana directly.
 

Firewall and Network Segments

A possible solution is to limit the network transport to only allowed hosts via firewall rules and so on. If your Elasticsearch cluster is running on a dedicated VLAN, you would need to allow the Icinga 2 monitoring host to write data into – anyone on that machine could still read/write without any security mechanism in place.
 

HTTP Proxy with Nginx

Start with the plain proxy pass configuration and forward http://localhosT:9200 to your external interface (192.168.33.7 in this example).

# MANAGED BY PUPPET
server {
  listen       192.168.33.7:9200;
  server_name  elasticsearch.vagrant-demo.icinga.com;
  index  index.html index.htm index.php;
  access_log            /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.access.log combined;
  error_log             /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.error.log;
  location / {
    proxy_pass            http://localhost:9200;
    proxy_read_timeout    90;
    proxy_connect_timeout 90;
    proxy_set_header      Host $host;
    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header      Proxy "";
  }
}

Restart Nginx and test the connection from the external interface.

# systemctl restart nginx
# curl -v http://192.168.33.7:9200

Once this is working, proceed with adding basic auth and TLS.
 

HTTP Proxy with Basic Auth

This leverages the access level to authenticated users only. Best is to manage the basic auth users file with Puppet, Ansible, etc. – similar to how you manage your Nginx configuration. Our consultants use that method on a regular basis, and provided me with some examples for Nginx. You could do the same for Apache – I would guess that is a matter of taste and performance here.
Generate a username/password combination e.g. using the htpasswd CLI command.

htpasswd -c /etc/nginx/elasticsearch.passwd icinga

Specify the basic auth message and the file which contains the basic auth users.

    auth_basic                "Elasticsearch auth";
    auth_basic_user_file      "/etc/nginx/elasticsearch.passwd";

Restart Nginx and connect to the external interface.

# systemctl restart nginx
# curl -v -u icinga:icinga http://192.168.33.7:9200

 

HTTP Proxy with TLS

The Elasticsearch HTTP API does not support TLS out-of-the-box. You need to enforce HTTPS via HTTP Proxy, enable ssl and set up the required certificates.
Enforce the listen address to SSL only. That way http won’t work.

  listen       192.168.33.7:9200 ssl;

Enable SSL, specify the certificate paths on disk, use TLSv1 and above and optionally secure the used ciphers.

  ssl on;
  ssl_certificate           /etc/nginx/certs/icinga2-elastic.crt;
  ssl_certificate_key       /etc/nginx/certs/icinga2-elastic.key;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;
  ssl_trusted_certificate   /etc/nginx/certs/ca.crt;

Restart Nginx and connect to the external interface on https. Note: Host verification is disabled in this example.

# systemctl restart nginx
# curl -v -k -u icinga:icinga https://192.168.33.7:9200

 

Combine HTTP Proxy, TLS and Basic Auth

A complete configuration example could look like this:

vim /etc/nginx/sites-enabled/elasticsearch.vagrant-demo.icinga.com.conf
# MANAGED BY PUPPET
server {
  listen       192.168.33.7:9200 ssl;
  server_name  elasticsearch.vagrant-demo.icinga.com;
  ssl on;
  ssl_certificate           /etc/nginx/certs/icinga2-elastic.crt;
  ssl_certificate_key       /etc/nginx/certs/icinga2-elastic.key;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;
  ssl_trusted_certificate   /etc/nginx/certs/ca.crt;
  uth_basic                "Elasticsearch auth";
  auth_basic_user_file      "/etc/nginx/elasticsearch.passwd";
  index  index.html index.htm index.php;
  access_log            /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.access.log combined;
  error_log             /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.error.log;
  location / {
    proxy_pass            http://localhost:9200;
    proxy_read_timeout    90;
    proxy_connect_timeout 90;
    proxy_set_header      Host $host;
    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header      Proxy "";
  }
}

The following example query does not verify the offered host certificate. In case you configure the ElasticWriter feature in Icinga 2 v2.8, you’ll find the options to specify certificates for TLS handshake verification.

$ curl -v -k -u icinga:icinga https://192.168.33.7:9200
* Rebuilt URL to: https://192.168.33.7:9200/
*   Trying 192.168.33.7...
* TCP_NODELAY set
* Connected to 192.168.33.7 (192.168.33.7) port 9200 (#0)
* WARNING: disabling hostname validation also disables SNI.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: icinga2-elastic
* Server auth using Basic with user 'icinga'
> GET / HTTP/1.1
> Host: 192.168.33.7:9200
> Authorization: Basic aWNpbmdhOmljaW5nYQ==
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.12.1
< Date: Tue, 12 Sep 2017 13:52:31 GMT
< Content-Type: application/json; charset=UTF-8
< Content-Length: 340
< Connection: keep-alive
<
{
  "name" : "icinga2-elastic-elastic-es",
  "cluster_name" : "elastic",
  "cluster_uuid" : "axUBwxpFSpeFBmVRD6tTiw",
  "version" : {
    "number" : "5.5.2",
    "build_hash" : "b2f0c09",
    "build_date" : "2017-08-14T12:33:14.154Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.0"
  },
  "tagline" : "You Know, for Search"
}
* Connection #0 to host 192.168.33.7 left intact

 

Conclusion

Secure data transfer from your monitoring instances to Elasticsearch is mandatory. Basic access control via basic auth should also be implemented. All of this is possible with the help of a dedicated HTTP Proxy host. Fine granular access control for specific HTTP requests is available in the commercial Shield package or variants. While securing Elasticsearch, also look into Kibana which runs on port 5601.
Since we’ve used the Icinga Vagrant boxes as a development playground, I’ve added Nginx as HTTP Proxy inside the icinga2x-elastic box. This provisions the required basic auth and TLS settings and offers to write data on https://192.168.33.7:9200 (icinga/icinga). The same applies for Kibana. The examples above can be replayed too.
If you want to learn more on this topic, make sure to join our Elastic Stack training sessions or kindly invite one of our consultants for a hands-on workshop. Hint: There is an Elastic Stack workshop at OSMC too 🙂

Manage Elasticsearch, Kibana & icingabeat with Puppet

A while back I’ve already looked into the Elastic Stack 5 Beta release and the beats integration. Time flies and the stable release is here. Blerim announced the icingabeat 1.0.0 release last week, and so I was looking into a smooth integration into a Vagrant box here.
The provisioner uses Puppet, which Puppet modules could be used here? I’m always looking for actively maintained modules, best by upstream projects which share the joy of automated setups of their tools with their community.
 

Elastic and Kibana Puppet Module

The Elastic developers started writing their own Puppet module for Kibana 5.x. Previously I’ve used community modules such as puppet-kibana4 or puppet-kibana5. puppet-elasticsearch already supports 5.x for a while, that works like a charm.
Simple example for a low memory Elasticsearch setup:

class { 'elasticsearch':
  manage_repo  => true,
  repo_version => '5.x',
  java_install => false,
  jvm_options => [
    '-Xms256m',
    '-Xmx256m'
  ],
  require => Class['java']
} ->
elasticsearch::instance { 'elastic-es':
  config => {
    'cluster.name' => 'elastic',
    'network.host' => '127.0.0.1'
  }
}

Note: jvm_options was released in 5.0.0.
 

Default index pattern

If you do not define any default index pattern, Kibana greets you with a fancy message to do so (and I have to admit – i still need an Elastic Stack training to fully understand why). I wanted to automate that, so that Vagrant box users don’t need to care about it. There are several threads around which describe the deployment by sending a PUT request to the Elasticsearch backend.
I’m using a small script here which waits until Elasticsearch is started. If you don’t do that, the REST API calls will fail later on. This is also required for specifying index patterns and importing dashboards. A Puppet exec timeout won’t do the trick here, because we’ll have to loop and check again if the service is available.

$ cat/usr/local/bin/kibana-setup
#!/bin/bash
ES_URL="http://localhost:9200"
TIMEOUT=300
START=$(date +%s)
echo -e "Restart elasticsearch instance"
systemctl restart elasticsearch-elastic-es
echo -e "Checking whether Elasticsearch is listening at $ES_URL"
until $(curl --output /dev/null --silent $ES_URL); do
  NOW=$(date +%s)
  REAL_TIMEOUT=$(( START + TIMEOUT ))
  if [[ "$NOW" -gt "$REAL_TIMEOUT" ]]; then
    echo "Cannot reach Elasticsearch at $ES_URL. Timeout reached."
    exit 1
  fi
  printf '.'
  sleep 1
done

If you would want to specify the default index pattern i.e. for an installed filebeat service, you could something like this:

ES_INDEX_URL="$ES_URL/.kibana/index-pattern/filebeat"
ES_DEFAULT_INDEX_URL="$ES_URL/.kibana/config/5.2.2" #hardcoded program version
curl -XPUT $ES_INDEX_URL -d '{ "title":"filebeat", "timeFieldName":"@timestamp" }'
curl -XPUT $ES_DEFAULT_INDEX_URL -d '{ "defaultIndex":"filebeat" }'

One problem arises: The configuration is stored by Kibana program version. There is no symlink like ‚latest‘, but you’ll need to specify ‚.kibana/config/5.2.2‘ to make it work. There is a certain requirement for pinning the Kibana version, or finding a programatic way to automatically determine the version.
 

Kibana Version in Puppet

Fortunately the Puppet module allows for specifying a version. Turns out, the class validation doesn’t support package revision known from rpm („5.2.2-1“). Open source is awesome – you manage to patch it, apply tests and after review your contributed patch gets merged upstream.
Example for Kibana with a pinned package version:

$kibanaVersion = '5.2.2'
class { 'kibana':
  ensure => "$kibanaVersion-1",
  config => {
    'server.port' => 5601,
    'server.host' => '0.0.0.0',
    'kibana.index' => '.kibana',
    'kibana.defaultAppId' => 'discover',
    'logging.silent'               => false,
    'logging.quiet'                => false,
    'logging.verbose'              => false,
    'logging.events'               => "{ log: ['info', 'warning', 'error', 'fatal'], response: '*', error: '*' }",
    'elasticsearch.requestTimeout' => 500000,
  },
  require => Class['java']
}
->
file { 'kibana-setup':
  name => '/usr/local/bin/kibana-setup',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/kibana-setup",
}
->
exec { 'finish-kibana-setup':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/kibana-setup",
  timeout => 3600
}

 

Icingabeat integration

That’s fairly easy, just install the rpm and put a slightly modified icingabeat.yml there.

$icingabeatVersion = '1.0.0'
yum::install { 'icingabeat':
  ensure => present,
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-$icingabeatVersion-x86_64.rpm"
}->
file { '/etc/icingabeat/icingabeat.yml':
  source    => 'puppet:////vagrant/files/etc/icingabeat/icingabeat.yml',
}->
service { 'icingabeat':
  ensure => running
}

I’ve also found the puppet-archive module from Voxpupuli which allows to download and extract the required Kibana dashboards from icingabeat. The import then requires that Elasticsearch is up and running (referencing the kibana setup script again). You’ll notice the reference to the pinned Kibana version for setting the default index pattern via exec resource.

# https://github.com/icinga/icingabeat#dashboards
archive { '/tmp/icingabeat-dashboards.zip':
  ensure => present,
  extract => true,
  extract_path => '/tmp',
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-dashboards-$icingabeatVersion.zip",
  checksum => 'b6de2adf2f10b77bd4e7f9a7fab36b44ed92fa03',
  checksum_type => 'sha1',
  creates => "/tmp/icingabeat-dashboards-$icingabeatVersion",
  cleanup => true,
  require => Package['unzip']
}->
exec { 'icingabeat-kibana-dashboards':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/share/icingabeat/scripts/import_dashboards -dir /tmp/icingabeat-dashboards-$icingabeatVersion -es http://127.0.0.1:9200",
  require => Exec['finish-kibana-setup']
}->
exec { 'icingabeat-kibana-default-index-pattern':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "curl -XPUT http://127.0.0.1:9200/.kibana/config/$kibanaVersion -d '{ \"defaultIndex\":\"icingabeat-*\" }'",
}

The Puppet code is the first working draft, I plan to refactor the upstream code. Look how fancy 🙂

Conclusion

Managing your Elastic Stack setup with Puppet really has become a breeze. I haven’t tackled the many plugins and dashboards available, there’s so much more to explore. Once you’ve integrated icingabeat into your devops stack, how would you build your own dashboards to correlate operations maintenance with Icinga alerts? 🙂
If you’re interested in learning more about Elastic and the awesome Beats integrations, make sure to join OSDC 2017. Monica Sarbu joins us with her talk on „Collecting the right data to monitor your infrastructure“.
PS: Test-drive the integration, finished today 🙂

Test-drive #icingabeat inside the #icinga vagrant box 'icinga2x-elastic' 🙂 https://t.co/DJuThyy6uu #elastic pic.twitter.com/qH1Kt8NB1l

— Icinga (@icinga) March 30, 2017