Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Die Zeit ist reif!


Viele unserer Trainer werden sich bald in den verdienten Sommerurlaub verabschieden und auch unser Schulungsprogramm pausiert in den heißen Sommermonaten. Im September starten wir dann wieder voll durch mit neuen Trainings, noch mehr Wissen und viel Raum und Zeit zum Lernen und Ausprobieren. Mit der Erfahrung aus über 300 Open Source Projekten, wissen wir genau, worauf es ankommt und freuen uns darauf, dieses Wissen mit Ihnen zu teilen. Sichern Sie sich jetzt Ihren Platz und planen Sie sich im Herbst ein wenig Abwechslung und neuen Input ein! Die Zeit ist reif!
Alle Schulungen im Überblick finden Sie hier.

Das bietet unser Schulungsprogramm im Herbst:

 

  1. Elastic Stack | 2 Tage | 12.09. – 13.09.2018

Sie erhalten eine detaillierte Einführung in die, auf Open Source basierenden Logmanagement Tools Elasticsearch, Logstash und Kibana. Darüber hinaus werden Techniken der Logübertragung, -auswertung und -analyse vermittelt.

  1. Icinga 2 Advanced | 3 Tage | 18.09. – 20.09.2018

In diesem Lehrgang für Fortgeschrittene erfahren Sie alles, was für den Betrieb von größeren und komplexeren Umgebungen notwendig ist: über das Icinga 2 Setup, distributed Monitoring und Hochverfügbarkeit, Performancegraphing und vieles mehr.

  1. GitLab | 2 Tage | 18.09. – 19.09.2018

GitLab ist mittlerweile das Tool zur verteilten Versionsverwaltung und erfreut sich immer größerer Beliebtheit, nicht nur unter Entwicklern, auch in der DevOps-Bewegung. In unserer Schulung erfahren Sie, wie Git und GitLab die tägliche Arbeit erleichtern.

  1. Advanced Puppet | 3 Tage | 25.09. – 27.09.2018

Lernen Sie den Umgang mit systemübergreifender Konfiguration mit Puppet, Module um Komponenten zu erweitern und die Qualität ihrer Module mit Tests zu verbessern. Außerdem im Programm: Module-Design und Troubleshooting.

  1. Graphite + Grafana | 2 Tage | 25.09. – 26.09.2018

Ihre Schulung für erfolgreiches Performance-Monitoring, vom Sammeln und Auswerten von Werten mit Graphite, bis zum Darstellen und Analysieren mit Grafana und weiteren Tools für den Aufbau eines individuellen, integrierbaren Stacks.

  1. Icinga 2 Fundamentals | 4 Tage | 09.10. – 12.10.2018

In diesem Training erhalten Sie Basiswissen zur Installation von Icinga 2 und Icinga Web 2 garniert mit Praxisbeispielen und Best Practices für Icinga 2 Konfiguration, Integration von Remote Clients und PNP4Nagios und weiteren nützlichen Inhalten.

  1. Fundamentals for Puppet | 3 Tage | 16.10 – 18.10.2018

Lernen Sie die grundsätzliche Funktionsweise hinter der Abstraktionsschicht von Puppet kennen, den Aufbau von Puppet-Modulen und deren Entwicklung vom lokalen Prototyp zum Deployment auf dem Puppet-Master.

  1. Ansible | 2 Tage | 23.10. – 24.10.2018

Nebst Installation und Umgang mit Ansible geht das Training auf die Konfiguration von Linux/Unix Systemen, den Umgang mit Playbooks und Rollen ein und gibt Hinweise zur Erstellung eigener Module.
9. Ansible AWX (Tower) | 1 Tag | 25.10.2018
Ansible AWX und Ansible Tower begleiten Unternehmen bei der Automatisierung. In diesem Kurs geben wir Ihnen einen umfassenden Überblick über deren Einsatzmöglichkeiten.
10. Jenkins | 1 Tag | 25.10.2018
Erfahren Sie alles über Jenkins, ein erweiterbares, webbasiertes Continuous Integration System zur Automatisierung von Integration, Tests und Paketbau.
 
Die NETWAYS Schulungen bestehen aus einer Kombination von Vortrag und praktischen Übungen. Unsere kompetenten Trainer arbeiten – wie Sie – als Praktiker tagtäglich mit den entsprechenden Open Source Anwendungen. Im Preis enthalten sind umfangreiche Schulungsunterlagen und volle Verpflegung. Notebooks und Wifi stellen wir.
Alle hier gelisteten Schulungen finden im NETWAYS Headquarter in Nürnberg statt, Deutschherrnstraße 15-19. Gerne sind wir Ihnen bei der Buchung eines Hotels behilflich. Melden Sie sich einfach bei uns.
Weitere Infos und Anmeldung unter: netways.de/schulungen

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

NETWAYS' Upcoming Training #Summer2018

Our Open Source trainings are designed to support your modern business processes

New Ways with NETWAYS – Our goal is to design your learning process as comfortable as possible! 


Foreman – Life Cycle Management for Servers
2 days training sessions | 03.07.2018 to 04.07.2018
CEPH – Scale out Storage
2 days training sessions | 03.07.2018 to 04.07.2018
GitLab – Modern Software Development
2 days training sessions | 10.07.2018 to 11.07.2018
Icinga 2 Fundamentals – Monitoring Redesigned
4 days training sessions | 10.07.2018 to 13.07.2018
Bareos – Level 1 – Introduction to Bareos
3 days training sessions | 16.07.2018 to 18.07.2018
Graylog – Centralized Logfile Management
2 days training sessions | 17.07.2018 to 18.07.2018
Bareos – Level 2  – Backup with LTO
2 days training sessions | 19.07.2018 to 20.07.2018
Ansible  Configuration Management
2 days training sessions | 24.07.2018 to 25.07.2018
Ansible AWX (Tower) 
1 day training session | 26.07.2018


For the whole NETWAYS training schedule visit: netways.de/training. For assistance please contact us.
 

Keya Kher
Keya Kher
Marketing Manager

Keya ist seit Oktober 2017 in unserem Marketing Team. Sie kennt sich mit Social Media Marketing aus und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

Elastic{ON} 2018 Reisebericht und Rückblick

Wie alle guten Weine brauch auch manchmal ein Erlebnis eine Weile um zu einer guten Erfahrung zu reifen. So war es für mich mit der Elastic{ON} 2018 und passend zum Feiertag hole ich für euch nun unsere Review aus dem Keller, öffne die Flasche und wir schauen gemeinsam zurück auf das Event.
Thomas Widhalm und ich waren  für NETWAYS bei der Elasti{CON}2018 für euch vor Ort und haben uns die neuesten Entwicklungen und Best Practice Geschichten für euch angehört.

 

Keynote und Party

Die Keynote geführt von Gründer Shay Banon ging schon spannend los, nach dem wir von unzähligen Mitarbeitern in einem Intro begrüßt wurden, folgten für alle Produkte des Elastic Stacks kurze Feature Vorstellungen fürs nächste Release. Highlight dieser Keynote war der Vortrag von Ryan Kazanciyan der technische Consultant für die Serie Mr. Robot. Eine weitere große Ankündigung war mit Abstand die “Doubling down on open” Strategie, welche eine Veröffentlichung der Quellen des X-Pack  mit sich bringt. Dies bedeutet aber nicht das diese Quellen unter eine Open Source Lizenz gestellt werden. Hierzu gab es noch einen Nachruf von Philipp Krenn im Elastic Blog, denn dieses Thema sorgte für viel Diskussionsstoff und hinterließ zuerst einige Unklarheiten.
Bei der Anschließenden Keynote-Party ging es spielerisch mit Frischlufteinlage zu. Denn der Feueralarm ertönte als die Party im vollen Gange war und wir mussten das Gebäude kurzfristig verlassen. Für alle die uns kennen, soll gesagt sein, Thomas und ich hatten damit nichts zu tun.

 

1 Konferenztag

Am ersten Konferzenz-Tag haben Thomas und ich uns auf die unterschiedlichen Sessions verteilt. Thomas Schwerpunkt lag am ersten Tag hier auf den Talks zu den einzelnen Tools des Stacks und deren neuen Features, während ich mich auf Best Practice und BoF (Birth of Feather) Sessions konzentriert.
Die hier spannendste BoF Session war die zur GDPR welche zum 25.Mai 2018 in kraft tritt. Hier wurde in einer großen Runde darüber diskutiert wie man im Bezug auf Logmanagement und das Auswerten von Logingdaten zu reagieren hat. Klar ist das es einige Möglichkeiten gibt mit denen die sensiblen Daten wie eine IP mit dem Fingerprint Filter gehasht werden können. Aber auch die Auflagen zur Absicherung des Zugangs zu den Daten und deren Aufbewahrungszeiten gilt es zu berücksichtigen. Zu dieser Session findet sich im Elastic Blog eine sehr gute Zusammenfassung.
Thomas konnte für uns einen sehr guten Überblick über die Neuerungen im Stack am ersten Tag gewinnen. Da diese nicht gerade wenig sind, haben wir hier für euch kurz zu jedem Tool drei Punkte:

Elasticsearch

  • Cross-Cluster Search ersetzt vollständig die Tribe Node Funktion, die Tribe Node Funktion wurde entfernt. Mit einem Node als Cross-Cluster-Node ist das verbinden mehrere Cluster und der Darstellung der Cluster-Daten in einem zentralen Kibana möglich. Wichtig dabei ist, dass laut Plan drei Major Versions in einem Verbund unterstützt werden. Diese Funktion kann unter anderem sehr nützlich bei Migrationen und Upgrade-Szenarien sein.
  • “Cross-Cluster-Sync”, wodurch Daten zwischen Clustern synchronisiert werden können. Damit können Daten in verschiedenen Standorten synchron gehalten werden ohne einen Cluster über mehrere Rechenzentren zu spannen (was nicht supported wird)
  • Die Angabe von minimum master nodes um Split Brain zu verhinden wird automatisch werden. Wie und wie die eingestellt werden kann wurde noch nicht genau gezeigt.

Kibana

  • Mit X-Pack gibt’s mehr Authentifizierungsbackends (inkl. SAML)
  • Query Autocompletion kommt
  • KQL wird die neue Querysprache, als Ersatz für die Lucene Query Syntax. Die beiden ähneln sich aber stark.
  • Neue Visualisierung: Waffle Map und Canvas sollen kommen

Beats

  • Es kommt eine Prometheus Integration
  • Auditbeat bekommt neue Features. Wird damit eine Kombination aus Auslesen von auditd plus Aide.
  • Beats senden jetzt eine Art Heartbeat, in dem auch ein paar Eckdaten des Hosts, auf dem sie installiert sind enthalten sind. So hat man ein rudimentäres Monitoring in Kibana und sieht auch gleich, ob alle Beats aktiv sind.

Logstash

  • Mit X-Pack soll ein Konfigmanagement für mehrere Logstash Instanzen inkl. Konfiguration von Pipelines kommen.
  • Logstash erhält einen Secret Key Store, mit dem Passwörter für Verbindungen sicher gespeichert werden können
  • Visual Pipeline Builder, mit dem in Kibana abgebildet wird, wie die Pipeline konfiguriert sind.

Party

Wer uns von NETWAYS kennt weis, dass wir immer gerne Feiern. Am Abend des ersten Tages waren wir zur Party von unseren Freunden von Graylog geladen. Ebenfalls eine Software für das Logmanagement welche unter anderem auch Elastic Software nutzt, wie zum Beispiel Elasticsearch zum speichern der Dokumente.

 

2 Konferenztag

Am zweiten Konferenztag waren wir überwiegend gemeinsam Unterwegs und durften uns über die Überklimatisierung der Räume erfreuen, welche für Eiszeiten sorgte. An diesem Tag nahmen Thomas und ich an einer Videostory teil, welche bis jetzt wohl noch nicht veröffentlich ist.
 

Talks

Der Talk der an diesem Tag für Thomas und mich besonders erwähnenswert war, war der Talk “The seven deadly Sins of Elasticsearch Benchmarking“.  In diesem Talk gaben Elastic Mitarbeiter aus der Entwicklung Einsicht in Ihre Erfahrung aus dem täglichen Elastisearch Support und wie Sie Elasticsearch zu Performance verhelfen. Klare Empfehlung ist immer auf der gleichen Infrastruktur zu testen wie diese in Produktion verwendet wird. Ein wichtiges Werkzeug für das Testen von Elasticsearch-Clustern wurde vorgestellt und auf Github zu finden https://github.com/elastic/rally.

Unsere Entdeckung

Unser Blerim Sheqa alias bobapple ist auf der “Thank you to the Contributors wall” für seine Beats verewigt!YEAHY!

Schön wars…

Es war insgesamt eine sehr gute Konferenz welche uns sehr viele Erfahrungsmehrwerte verschaffte und uns die Möglichkeit bot eine Zertifizierung einzufahren. Thomas und ich bedanken uns auch bei Bernd bedanken, dass wir unsere Firma vertreten durften.
Mein persönliches Highlight war wohl der AMA-Stand. Diese Chance mit den Schöpfern und den Supportern der Software direkt zu sprechen nehme ich gerne war um meine offenen Verständnisfragen zum Elastic Stack zu schließen und nicht eine konkrete Aufgabenstellung zu lösen. Jetzt bleibt nur noch zu sagen das wir von neuem Wissen und mehr Wissen nur so strotzen und wenn Ihr offene Fragen habt dann besucht doch einfach eine unserer Elastic Stack Trainings z.b  Anfang Juni. Oder meldet euch, wenn Ihr konkret Unterstützung braucht und von unserem mit neuen Informationen angereicherten Wissen profitieren wollt, bei den Kollegen vom Sales Team. So zum Abschied noch eine kleine Weisheit : “You Know for Search!”

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...

Hackathon auf der OSMC

Nachdem bis auf Ansible alle unsere Workshops bereits ausgebucht sind, kann die OSMC nicht mehr lange hin sein! Wohl wahr, in gut einem Monat geht’s schon los.
Und nun steht auch das Programm für den perfekten Konferenzausklang am Hackathon-Freitag. Fünf Themen haben wir ausgewählt, wir freuen uns natürlich auch über eure eigenen Vorschläge! Lasst euch diesen spannenden Hacker-Tag nicht entgehen und tüftelt mit Gleichgesinnten!
Das Programm steht auch schon länger fest, mit dabei sind unter anderem diese Highlights:

Die Workshops sind bis auf “Ansible – Configuration Management” schon restlos ausgebucht. Wer hier noch teilnehmen will, sollte also nicht lange zögern, sondern schnell klicken.
Alles weitere zur Konferenz findet ihr wie immer brandaktuell auf unserer Webseite!

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 http://elasticsearch.yourdomain:9200 – 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 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...