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
Developer

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
Johannes Meyer
Developer

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