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!
0 Comments