Seite wählen

NETWAYS Blog

Netways auf der Elastic{ON}17

Wie letztes Jahr hatten einige von uns die grossartige Gelegenheit, die Elastic{ON} in San Francisco besuchen. Dort stellt Elastic sämtliche kommenden Neuerungen am Elastic Stack vor. Daneben haben auch einige Kunden und Partner die Möglichkeit, ihre Use-cases oder Services zu präsentieren sowie ihr eigenes Setup und dessen Herausforderungen zu zeigen.
Die Neuigkeiten im Stack zeigen vor allem drei Schwerpunkte: Graphische Bedienung, mehr Visualisierungen in Kibana und noch mehr Stabilität. So sind eine graphische Aufbereitung und wohl auch eine teilweise graphische Konfiguration von Logstash Pipelines via Kibana geplant.
In Kibana selbst tut sich sehr viel. Da kommen neue Visualisierungen, insb. für Geolocation und ein „Visualisation Builder“, mit dem man deutlich ausgefallenere Graphen als bisher erstellen kann. In einer one-on-one Test Session konnte ich dieses Feature schon mal bestaunen, bin aber, ehrlich gesagt, etwas an der Komplexität und der ungewohnten Bedienung gescheitert. Entweder hat da noch der Jet-Lag zugeschlagen oder Elastic sollte noch etwas an der Bedienung feilen, die ja sonst doch sehr eingängig ist.
An der Stabilität wird insbesondere bei Elasticsearch gearbeitet. Dabei ist wohl eine Art „Transaction Log“ geplant, das endlich schnelle Neustarts von Clusterknoten ohne vorherigen „Flushed Sync“ ermöglicht und auch sonst sehr zur Stabilität beitragen soll.
Es wäre nicht Elastic, wenn nicht auch eine Menge Livedemos vorgeführt werden würden, was wir sehr schätzen, da sie doch auch einen wirklich sehr konkreten Nutzen für die Teilnehmer haben. Da heben sich die Elastic Mitarbeiter wirklich von vielen anderen Sprechern auf, insbesondere amerikanischen, Konferenzen positiv ab. Eine besonders beeindruckende Demo war der Auftakt der Konferenz mit einer Tänzerin, deren Bewegungen und Herzschlag live in Kibana visualisiert wurden. Das schien tatsächlich live zu sein, da Kibana durchaus auch mal den ambivalenten Smiley zeigte, der angibt, dass aktuell keine Datensätze gefunden wurden.
Es ist noch etwas zu früh, um alle Änderungen sichten und bewerten zu können, aber es sieht jedenfalls so aus, als hätte Elastic etliches in petto, das uns als Elastic Stack Usern das Leben deutlich einfacher und vor allem bunter machen würde. Wie immer schwebt das Damoklesschwert „kommt dieses Feature in X-Pack oder bleibt es frei“ über jeder angekündigten Neuerung, aber das scheint teilweise noch gar nicht entschieden zu sein. Ziemlich sicher wird „Machine Learning“ ein Kibana Feature, das aus „Prelert“ entstanden ist, nur für Nutzer von X-Pack erhältlich sein. Ob „Canvas“, ein Feature, mit dem Reports und Präsentationen aus Kibana heraus erstellt werden können, frei verfügbar sein wird, wird noch entschieden. Auf jeden Fall würde das vielen Usern sehr weiterhelfen, nach dem, was wir an Nachfragen erhalten.
Viele der Features wurden für „kommende Releases“ angekündigt. Einige davon kommen in 5.3, andere erst in 6.0.
Auf jeden Fall war die Konferenz wieder die Reise wert und ich kann es kaum erwarten, mit den neuen Features zu experimentieren und sie umzusetzen.
Ganz abgesehen von der Konferenz ist San Francisco natürlich auch für sich genommen eine wunderbare Stadt und wir alle sind sehr froh, dass die Reise so gefallen ist, dass wir uns auch noch etwas die Stadt ansehen konnten.
Wer noch keinen Kontakt zum Elastic Stack hatte, sollte sich einmal unsere Schulungen zum Thema ansehen. Die kurz und knackig und bieten alles, was man für einen Start in die Welt des Logmanagement braucht.
Dass der Blogpost etwas später als gewohnt erscheint liegt an der Zeitverschiebung und dem einen oder anderen wunderbaren IPA, das es hier zu probieren gab.
Die Talks gibt es sicherlich demnächst im Archiv nachzusehen.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Diving into Elastic Stack 5.0.0-beta1 and Elastic Beats

logo2_elastic_150x75I’m always trying to look into new devops tools and how they fit best with Icinga 2 as a monitoring solution. Often demanded is an integration with Elastic Stack and Elastic Beats with Icinga 2. Gathering metrics and events, correlated to additional input sources analysing a greater outage and much more.
Last week the first 5.0.0 beta1 release hit my channels and I thought I’d give it a try. The installation is pretty straight forward using packages. Note: This is my first time installing Elastic Stack, still have little knowledge from colleague hero stories and the OSDC talk by Monica Sarbu and earlier conferences.
mehr lesen…

Schnellere Neustarts für Elasticsearch

Dass Elasticsearch das „Elastic“ in seinem Namen richtig ernst meint, hat jeder, der mal mit mehr als einem Knoten experimentiert hat, feststellen können. Anders als viele andere geclusterte Dienste können Knoten fast nach Belieben zu einem bestehenden Cluster hinzugefügt und wieder entfernt werden.
Wie ernst es Elastic mit der Elastizität ist, sieht man unter anderem an den folgenden Eigenschaften. (Wer sich intensiver mit Elasticsearch auseinandergesetzt hat, wird wissen, dass es sich hier um Defaulteinstellungen handelt und man in komplexeren Setups doch das eine oder andere einstellt und nicht dem Automatismus überlässt. Also bitte keine Kommentare wie „In meinem Cluster steht aber, dass gateway.expected_nodes den Wert 23 hat.“)

  • Elasticsearch Cluster haben üblicherweise nirgends vermerkt, wie viele Knoten der Cluster beinhaltet. Lastverteilung, Wahl des Masters, etc. rechnet immer mit der aktuell vorhandenen Anzahl an Knoten.
  • Es gibt keinen Weg, einen Knoten aus einem Cluster „sauber“ zu entfernen oder ihn hinzuzufügen. Entfernen bedeutet Beenden des Dienstes und Hinzufügen bedeutet Starten des Dienstes mit gleicher Konfiguration wie der Rest.
  • Backups bzw. Snapshots werden von allen beteiligten Knoten auf einen Share geschrieben und von dort gelesen. Egal, wie viele Knoten zum jeweiligen Zeitpunkt aktiv sind. Ein zwei Knoten Cluster kann ohne weiteres einen Snapshot restoren, der von einem 12 Knoten Cluster gemacht wurde, solange die Ressourcen dazu ausreichen. Konfiguration braucht man dafür nicht.
  • Kommunikation mit dem Cluster geschieht üblicherweise über die REST-API eines einzelnen Knotens, der die Anfrage im Cluster weiter verteilt. Egal, ob es sich dabei um ein Query oder eine dynamische Konfigurationsänderung handelt.

Der Nachteil dieser Elastizität ist, dass der Cluster nicht wissen kann, ob ein Knoten entfernt wurde oder nur mal kurz neu gestartet wird. Das hat zur Folge dass üblicherweise sofort nach Wegummiringerlgfall eines Knotens der restliche Cluster beginnt, Shards und ihre Repliken (Daten in Elasticsearch werden in Indices aufgeteilt, die wiederum in Shards unterteilt werden, die ihrerseits in Repliken kopiert werden – so erreicht Elasticsearch mit beliebigen Daten Lastverteilung und Redundanz) umzuverteilen, um den „Verlust“ des Knotens auszugleichen. Dazu werden die Daten, die auf diesem Knoten waren, sofort auf andere Knoten kopiert – das ist möglich weil Elasticsearch per default jeden Datensatz mindest zweimal vorhält. Nachdem die Redundanz wieder hergestellt ist, werden die Shards und Repliken nochmal verschoben, jedoch langsamer, um die Last im Cluster gleichmässig zu verteilen.
Was aber nun, wenn der Knoten sofort wieder dem Cluster beitritt, weil er nur, z.B. wegen eines Kernel Updates, rebooted wurde? Die Daten, die sich noch auf dem Knoten befinden, werden validiert, ob sie noch brauchbar sind oder in der Zwischenzeit verändert wurden und eventuell verschobene Daten werden vielleicht wieder zurückverschoben. Wird Elasticsearch als Teil des Elastic Stack mit Logstash und Kibana verwendet (und das wollen wir doch alle), dann werden üblicherweise nur in den Index des aktuellen Tages Daten geschrieben und die anderen bleiben unverändert. Da Elasticsearch das jedoch nicht weiss, wird der gesamte Datenbestand überprüft. Abhängig von verschiedenen Faktoren kann dieses Überprüfen wenige Minuten bis etliche Stunden dauern. Während dieses Prüfens sind üblicherweise die Daten nicht so verteilt, wie es sein soll und der Cluster bleibt im Status „Yellow“, was einige Arbeiten daran verhindert und auch bedeutet, dass kein weiterer Knoten ausfallen sollte, um Datensicherheit zu gewährleisten. Das macht den Neustart eines gesamten Clusters Knoten für Knoten im laufenden Betrieb zum Geduldsspiel.
Zum Glück gibt es einen einfachen, wenn auch nicht weithin bekannten, Weg, Elasticsearch vom Rebalancing des Clusters abzuhalten und auch die Daten bereits im Vorfeld als unveränderlich zu markieren.


curl -XPUT http://elasticsearch001:9200/_cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "none"
    }
}
curl -XPOST http://elasticsearch001:9200/_flush/synced

Mehr dazu gibt in der Elasticsearch Doku. Der erste Befehl schaltet das Umverteilen von Shards komplett ab und der zweite führt einen sogenannten „Synced Flush“ aus. Dabei werden ein paar Ressourcen freigegeben und Elasticsearch erstellt etwas ähnliches wie eine Checksum für jeden Index, der sich in den letzten 5 Minuten nicht verändert hat. Diese beiden Befehle haben zur Folge, dass auch bei Wegfall (in unserem Beispiel Neustart) eines Knotens weder die Redundanz im Cluster wieder hergestellt noch die Last gleichmässig verteilt wird. Das ist in diesem Fall gut, da der Knoten ja gleich wieder da sein wird. Wenn denn der neu gestartete Knoten wieder da ist, prüft Elasticsearch nur kurz, ob die Prüfsummen noch stimmen, wovon auszugehen ist, und bringt die Shards und Repliken auf diesem Knoten sofort wieder online. Das beschleunigt einen Neustart enorm.
Wenn alle geplanten Neustarts abgeschlossen sind, muss unbedingt der folgende Befehl abgesetzt werden, um die Umverteilung wieder zu aktivieren, da Elasticsearch sonst nicht auf den echten Ausfall eines Knotens reagieren kann.


curl -XPUT http://elasticsearch022:9200/_cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "all"
    }
}
Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Securing Elasticsearch

This is the English version of my last week’s post.
It is nowadays a really hot topic: Data protection
And by this I do not mean the long-standing topic which is passionately discussed in especially German IT-News. No, I am referring to data which is stored in your Elasticsearch cluster. Although it is undoubtful that some privacy related data is stored in it just as well.
Most of you already utilize some kind of solution to regulate access to your Elasticsearch cluster. This goes from simple URL-filters over dedicated reverse proxies to full-blown solutions like „Shield“. But what they all have in common, is that they do not suit everyone’s needs. They are either too limited in the provided functionality or just too expensive for what is intended to achieve.
That is why a company of the German automotive industry wanted us to create an open-source solution which combines most if not all of the requirements in a single product. The result is a reverse proxy service built from scratch. It is able to authenticate clients, authorize them on the index-, type- and field-level as well as based on particular functionalities offered by the REST API of Elasticsearch. And it has also got a cool name: ElasticArmor
The initial release will only provide the basic functionality to cover standard requests made by Kibana. However, since the product is open-source and is developed with simple extension in mind we suspect that the remaining functionality will arrive sooner or later. Additionally, note that because of this service’s nature you will still need a security perimeter to protect the communication of the cluster itself as ElasticArmor will only regulate the communication between the client and Elasticsearch.
So how does ElasticArmor actually accomplish its work? Well, that is pretty straight forward. A request made by a client needs to get past ElasticArmor first. Whether it is a human being or a service like Kibana, a client is by definition the origin of a request. Thus it can carry authentication details or be completely anonymous and is only identified by the IP address where it is coming from.
Once ElasticArmor receives a request made by an authenticated client it will apply the roles assigned to him. These define what and how much a client is permitted to do. They are applied by inspecting the URL and payload of the request. Inspecting a URL is not that much difficult but issues arise if it is about the payload as it is way more complex. (e.g. Search-API) For this reason ElasticArmor knows very well what kind of functionality is offered by which API to the client. Will it encounter something it does not know about (e.g. a newly introduced query) the request is instantly rejected. This prevents vulnerabilities in case ElasticArmor is connected to a Elasticsearch cluster with which it is not compatible yet.
Modifications will only applied to a request unless the response will not fundamentally change. This means that e.g. queries, filters and aggregations are not modified. The URL however will potentially change if it is about indices, documents and fields. Source filtering will also be used to make sure that a client does not have access to more than he is permitted to.
However, some features of Elasticsearch are very difficult to handle. (e.g. Fuzzy Like This, Fuzzy Like This Field and More Like This) For this reason ElasticArmor will only ensure the permission to utilize them so you should think well whom to grant this permission.
ElasticArmor represents itself as Elasticsearch to the outside as it is the one a client will communicate with after all. A smooth integration in your already existing infrastructure should therefore be easily possible.
We are now at the end of this post. I hope I was able to awaken your interest. If you have any questions, do not hesitate to ask in the comments!

Johannes Meyer
Johannes Meyer
Lead Developer

Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.

Securing Elasticsearch

The English version of this post is available here.
Woah, was für ein Thema: Datenschutz
Und damit meine ich nicht das allseits bekannte Thema und die seit jeher leidenschaftlich verfochtenen persönlichen Daten. Nein, wovon ich rede sind die Daten, die in Elasticsearch landen. Wobei dort sicher auch bei dem einen oder anderen Personen bezogene Daten hinterlegt sind, keine Frage.
Viele setzen bereits diverse Lösungen ein, um den Zugriff auf Elasticsearch zu steuern. Das geht von einfachen URL-Filtern, über dedizierte Reverse Proxies mit Authentifizierung bis hin zu Elasticsearch’s hauseigener Rundum Lösung „Shield“. Doch was sie alle gemeinsam haben: Sie sind nicht für jeden geeignet, da sie entweder zu eingeschränkt hinsichtlich der Funktionalität oder schlicht zu teuer in der Anschaffung sind.
Deshalb kam eine namhafte Größe aus der Automobil-Branche auf uns zu, und schlug vor eine Opensource Lösung zu entwickeln, um all das in einem Produkt zu integrieren. Heraus kam ein von Grund auf neu geschriebener Reverse Proxy Dienst, welcher Authentifizierung und Autorisation auf Index-, Typ- und Feld-Ebene sowie auf Basis konkreter Funktionalitäten von Elasticsearch’s REST API vereint. Das ganze hat natürlich auch einen Namen: ElasticArmor
In der ersten Version werden zwar vorerst nur normale Anfragen die von Kibana stammen in vollem Umfang berücksichtigt, doch da das Projekt Opensource ist und mit der Absicht leicht zu erweitern zu sein geschrieben wurde, gehen wir davon aus nicht lange auf Erweiterungen warten zu müssen. Außerdem erfordert die Natur des Dienstes die zusätzliche Absicherung des angebundenen Elasticsearch-Cluster mittels eines Sicherheitsperimeters, da nur die Kommunikation zwischen Cient und Elasticsearch eingeschränkt wird, nicht jedoch die Kommunikation der einzelnen Elasticsearch-Nodes.
Doch wie funktioniert der ElasticArmor nun eigentlich? Nun, eigentlich ganz einfach. Ein Client der eine Anfrage an Elasticsearch stellt, muss zuerst am ElasticArmor vorbei. Ein Client ist, per Definition, der Ursprung der Anfrage. Dabei kann es sich um einen weiteren Dienst wie z.B. Kibana oder eine bestimmte Person handeln. Authentifizierung bedeutet allerdings nicht zwingend, dass es sich um eine reale Person mit Namen und Passwort handeln muss, es kann genauso gut ein anonymer Zugriff von einer ganz bestimmten IP sein.
Erhält der ElasticArmor nun letztendlich eine Anfrage von einem authentifizierten Client, werden die ihm zugeordneten Rollen angewendet. Diese definieren was und wie viel er darf. Angewendet werden sie, indem die URL der Anfrage und der Körper der selben analysiert werden. Im Falle der URL ist das nicht weiter schwer, doch der Körper einer Anfrage (z.B. Search-API) ist wesentlich komplexer. Aus diesem Grund ist dem ElasticArmor genau bekannt was für Möglichkeiten ein Client in einer solchen Anfrage hat. Trifft er auf etwas das ihm nicht bekannt ist, (z.B. ein neu eingeführtes Query) wird die Anfrage sofort abgelehnt. Dies verhindert Sicherheitslücken wenn die Version von Elasticsearch aktualisiert wird, ohne Rücksicht auf die Kompatibilität mit dem ElasticArmor zu nehmen.
Verändert wird eine Anfrage nur, wenn sich das Ergebnis nicht grundlegend ändert. Das bedeutet z.B. dass Queries, Filter, Aggregationen o.Ä. nicht verändert werden, die URL potentiell jedoch schon, jedenfalls was Indizes, Dokumente und Felder anbelangt. Auch das Source filtering wird verwendet um sicher zu stellen, dass jemand nur das sieht was er sehen darf.
Einige Features von Elasticsearch sind jedoch nur sehr schwer bis gar unmöglich einzuschränken, (z.B. Fuzzy Like This, Fuzzy Like This Field und More Like This) weshalb bei diesen nur das Recht sie zu benutzen sicher gestellt wird. Man sollte also aufpassen wem man dieses Recht gestattet.
Desweiteren verhält sich der ElasticArmor nach außen hin wie Elasticsearch. Schließlich ist er es mit dem sich ein Client tatsächlich unterhält. Somit sollte eine relativ problemlose Integration in die bereits bestehende Infrastruktur möglich sein.
Das war’s dann auch schon wieder. Ich hoffe ich konnte das Interesse, insbesondere die Vorfreude, bei dem einen oder anderen wecken. Bei Fragen, bitte einfach drauf los kommentieren!

Johannes Meyer
Johannes Meyer
Lead Developer

Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.