Icinga Web 2 – Das gefällt jedem

Und wenn doch nicht, kann man es ganz einfach seinen eigenen Design-Vorstellungen entsprechend anpassen, denn darum geht es heute:

Theming

Wer es bis jetzt noch nicht entdeckt hat, darf nun erst einmal im Menü auf seinen Benutzernamen klicken und die Konto-Einstellungen öffnen. Dort versteckt sich seit v2.1.1 eine Möglichkeit das Theme, in dem Icinga Web 2 erstrahlt, zu ändern. (Sofern diese Möglichkeit nicht vom Administrator deaktiviert wurde.) Diese Themes werden teilweise von Icinga Web 2, teilweise von Modulen bereit gestellt können aber auch vom System-Administrator eingepflegt werden.

Von Haus aus stellt aktuell nur Icinga Web 2 zwei Themes bereit: High-Contrast und Winter.
Das High-Contrast Theme, wie der Name schon suggeriert, erhöht den Kontrast der Farben in Icinga Web 2. Es ist dafür gedacht die Barrierefreiheit zu erhöhen. Das Winter Theme hingegen ist einfach nur eine Spielerei für die kalten Winter-Tage.

Würde es aber heute nur um die einfache Nutzung der Themes gehen, wären wir nun schon wieder am Ende angelangt. Aber das wäre ja langweilig und für viele sicher auch nichts neues, nicht? Deshalb:

Eigene Themes erstellen

Erst einmal ein paar Grundsätze:

  • Globale Themes liegen hier: icingaweb2-installation/public/css/themes/
  • Modul Themes liegen hier: modul-installation/public/css/themes/
  • Der Name eines Themes wird direkt vom Dateinamen abgeleitet
  • Themes müssen die Datei-Endung “less” haben
  • Geschrieben wird ein Theme mit CSS oder LESS

Auf CSS oder LESS gehen wir nun nicht näher ein, das wäre zu viel des Guten. Interessant allerdings dürfte sein, wie Stylesheets in Icinga Web 2 behandelt werden und was in den einzelnen bereits mitgelieferten Dateien enthalten ist.

Stylesheets in Icinga Web 2

Alle Stylesheets in den oben erwähnten Verzeichnissen, werden automatisch von Icinga Web 2 in eine einzelne Datei zusammengefasst und an den Browser ausgeliefert:

  • Mit Originaler (lesbarer) Formatierung: /icingaweb2/css/icinga.css
  • Keine Formatierung (Komprimiert): /icingaweb2/css/icinga.min.css

Da die Stylesheets von Icinga Web 2 immer zuerst kommen und danach die aller Module, können Themes (da sie als letztes kommen) alles andere beeinflussen.

Prinzipiell solltet ihr euch einfach einmal alle mitgelieferten Stylesheets ansehen: icingaweb2-installation/public/css/icinga/

Aber um den Überblick und die Orientierung etwas zu vereinfachen, ist hier eine grobe Zusammenfassung zu den wichtigsten Dateien:

  • base.less
    Allgemeine Regeln und alle globalen Farb-Variablen
  • login.less
    Regeln für den Login, inklusive welches Logo verwendet wird
  • layout.less
    Regeln für das globale Layout (Header, Container, Footer)
  • menu.less
    Regeln für das Haupt-Menü
  • forms.less
    Regeln für alle Formulare
  • tabs.less
    Regeln für die Tabs
  • controls.less
    Speziellere Regeln für Form-Elemente bzw. “Widgets”

Jetzt könnt ihr bereits loslegen. Einfach eine neue Datei in einem der oben genannten Pfade anlegen (je nachdem ob es sich um ein Modul handelt, oder nicht) und fröhlich drauf los stylen. Treten Probleme auf oder ihr möchtet mit den Developer-Tools des Browsers die Regeln inspizieren, kann es hilfreich sein den “_dev” URL-Parameter an die URL anzuhängen. (z.B. /icingaweb2/dashboard?_dev) Dies führt dazu, dass das Stylesheet nicht komprimiert ausgeliefert wird.

Das wars dann nun aber. Falls noch Fragen aufkommen, verweise ich auf das Forum. Frohes schaffen!

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

atexit, oder wie man Python-Dienste nicht beenden sollte

Wer schon einmal einen Dienst mit Python realisiert hat, wird bereits vor der Aufgabe gestanden haben die Aufgaben die er verrichtet sauber und geordnet zu beenden. Python bietet einem hier vielerlei Lösungen an, darunter auch das atexit Modul. Für schnelle und simple Aufräum-Arbeiten ist dieses Modul wunderbar geeignet, nicht jedoch wenn Thread-Synchronisation und externe Kommunikation im Spiel ist. Warum das so ist und was die saubere Alternative ist, darum geht es heute in diesem Blogpost.

Wie der Name des Moduls und dessen Dokumentation bereits sagt, werden registrierte Routinen ausgeführt kurz bevor der Interpreter angehalten wird. Klingt erst einmal nicht besonders problematisch, ist es doch gerade was man haben möchte. Und es funktioniert sogar, solange keine Threads laufen. Dann werden die registrierten Routinen nicht aufgerufen. Das liegt daran, dass “normale” Threads explizit beendet werden müssen, sonst verhindern diese den Stopp des Interpreters. Damit das nicht passiert, kommt man möglicherweise auf folgende Idee:

t = threading.Thread(target=func)
t.daemon = True  # Avoids that python hangs during shutdown
t.start()

Ganz schlecht. Das mag möglicherweise den gewünschten Effekt haben und die Aufräum-Routinen können ihre Arbeit verrichten. Aber tatsächlich ist dies nur eine Lösung für ein Symptom, das eigentliche Problem ist noch immer nicht gelöst. Das wird einem spätestens klar, wenn es nicht mehr nur darum geht Threads zu beenden, sondern auch noch mit anderen über das Netzwerk verbundenen Diensten/Klienten eine saubere Unterbrechung der Kommunikation einzuleiten.

Denn was genau passiert wenn der Interpreter angehalten wird?

  1. Der MainThread wird sofort angehalten
  2. Offene File-Handles werden geschlossen
  3. Es wird gewartet dass alle nicht-Daemon Threads beendet wurden
  4. Die atexit-Routinen werden ausgeführt
  5. Garbage Collection
  6. Der Prozess wird beendet

Der zweite Punkt lässt einige vielleicht bereits aufhorchen, denn sockets sind nichts anderes als File-Handles. Wer nun immer noch denkt er könne in einem daemon-Thread die Netzwerk-Kommunikation mit seinem Gegenüber sauber beenden, ist auf dem Holzweg. Zum Zeitpunkt zu dem die atexit-Routinen laufen, sind bereits alle sockets unwiderruflich geschlossen.

Angenommen der Stopp des Dienstes wird ganz normal über SIGTERM initiiert, so könnte man nun alle atexit-Routinen in einen Signal-Handler verlagern. Dadurch würden sie laufen noch bevor der Interpreter angehalten wird, allerdings kommt man so sehr schnell wieder in die Bredouille, je nachdem welche Art von Arbeit der MainThread verrichtet. Denn da Signal-Handler asynchron im MainThread ausgeführt werden, ist das Risiko für ein Deadlock sehr groß. Kommen wir also zur erwähnten, sauberen Alternative: Feuer mit Feuer bekämpfen.

Was vormals in etwa so aussah:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...

    def _sigterm(self, signum, frame):
        sys.exit(0)

    def _atexit(self):
        # Alle Aufräum-Arbeiten

Kann ganz einfach, mit durchschlagendem Erfolg, so umgebaut werden:

class SomeDaemon:
    def start():
        # ...
        signal.signal(signal.SIGTERM, self._sigterm)
        atexit.register(self._atexit)
        # ...

    def _sigterm(self, signum, frame):
        threading.Thread(target=self._cleanup, name='CleanupThread').start()

    def _cleanup(self):
        # Komplexe Aufräum-Arbeiten

    def _atexit(self):
        # Einfache Aufräum-Arbeiten

Der “CleanupThread” sollte selbstverständlich keine Arbeit verrichten die unkontrolliert blockt. Denn dann sieht das ganze am Ende wieder so aus:

    def _sigterm(self, signum, frame):
        t = threading.Thread(target=self._cleanup, name='CleanupThread')
        t.daemon = True
        t.start()

Und der ganze Spaß geht von vorne los..

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

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

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

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

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Bottle – Klein aber fein

Vor einiger Zeit war es notwendig für ein Kunden-Projekt dessen Umgebung bei uns nachzubilden. Es war von vornherein klar, dass es keine 1:1 Nachbildung sein muss (kann) und somit war es nur notwendig einige wenige Bestandteile einer REST Api zu simulieren. Da REST rein HTTP basiert ist und die zu simulierenden Aktionen nur GET waren, kam uns erst gar nicht in den Sinn ein großartiges PHP-Projekt ins Leben zu rufen und entschieden uns daher für eine schnelle Lösung mittels eines Standalone Python Skriptes.

Mir war Bottle schon seit einigen Jahren bekannt und deshalb noch als Werkzeug für schnelle und einfache Lösungen in Erinnerung. Tatsächlich eingesetzt hatte ich es allerdings noch nie, weshalb dies die Chance war es endlich einmal zu tun. Gesagt getan, runtergeladen und ausgeführt. Da Bottle allein auf der Standard-Library von Python basiert und mit Python 2.6+ wie auch Python 3.2+ kompatibel ist, funktionierte das sofort ohne Probleme. Und es hält was es verspricht!

Allein das erste Beispiel auf seiner Webseite zeigt bereits wie schnell ein Web-Server mit dynamischem Routing und Inhalten aufgesetzt wird:

from bottle import route, run, template

@route('/hello/<name>')
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)

run(host='localhost', port=8080)

Ja sogar Basic Authentication beherrscht es:

from bottle import route, run, template, auth_basic

def authenticate(username, password):
    return username == 'max' and password == 'mustermann'

@route('/hello/<name>')
@auth_basic(authenticate)
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)

run(host='localhost', port=8080)

Ist das nicht toll? Ich nehme stark an, dass da noch mehr geht, aber für den Moment bin ich vollauf zufrieden. 🙂

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.