ReadonlyREST has evolved very rapidly in the last year, we ticked a lot of boxes in the features list. To the point X-Pack security module made by Elastic team, and ReadonlyREST Enterprise features set almost overlap.

Let’s compare the two pairs of Elasticsearch and Kibana security plugins and discover where the main differences are.

 

Licensing Model and Price

Both plugins rely on a subscription fee model. This is reflect the continuous process of keeping them up to date with the latest changes in the Kibana and Elasticsearch internals and APIs, the development of new features, and the vulnerability research behind keeping these products on top of the information security food-chain.

Notably though, ReadonlyREST Free, the security plugin for Elasticsearch is free software (GPLv3 license), and it’s the only FOSS-licensed realistic competitor to X-Pack Security at the moment of writing. Its development is entirely sponsored by the sales of ReadonlyREST PRO and Enterprise Kibana security plugins, which have .

ReadonlyREST PRO and Enterprise security plugins for Kibana have a flat subscription model. That is: doesn’t matter how many nodes you have, you pay the same yearly price.

On the other hand, the pricing model of X-Pack Security is way aggressive. And that’s in a way understandable because X-Pack Security is not sold as a stand alone plugin: it comes as one of the plugins inside of a multi-functional swiss army knife extension pack, that all together build up in perceived value, justifying higher prices.

The below graph explains how X-Pack prices start at three times ReadonlyREST prices, and  grows quasi-linearly as the  number of nodes in your Elasticsearch cluster grow. On the same chart, we observe how ReadonlyREST Enterprise (their most expensive Kibana security plugin) price remains constant as your project grows.

 

X-Pack prices by number of nodes

Price (approx, normalised to ROR Enterprise) X-Pack ReadonlyREST Enterprise
1 node ~3x 1
3 nodes ~5x 1
10 nodes ~10x 1

ReadonlyREST pricing policy remains constant, and growing in nodes and number of clusters is never a problem.

Encryption

Sending across credentials over plain HTTP in any form (basic auth, JWT, hashed) is risky: eavesdroppers can intercept credentials and impersonate users.

Both ReadonlyREST and X-Pack got your back becaus both support HTTPS.

X-Pack Security ReadonlyREST
HTTPS (port 9200) (free)
HTTPS Protocol/Cypher negotiation (free)
Inter-node SSL (port 9300) (*)

The inter-node SSL is the encryption is an encryption layer of the Elasticsearch transport protocol. This interface is used by the Elasticsearch nodes for joining the cluster, replication, master election, forwarding of queries, and so forth.

Although Elastic recommends to enable this by default, the performance cost to pay for encrypting this kind of traffic may not be negligible. For example at CERN inter-node encryption slowed things down to the point they simply gave up on it and used a firewall.

(*) If you use ReadonlyREST, and still require Inter-node SSL, you can use the Apache 2.0 licensed “Search Guard SSL” plugin, remembering to disable the HTTP encryption using “searchguard.ssl.http.enabled: false” in elasticsearch.yml.

Access Control

X-Pack access control is role based (RBAC), while ReadonlyREST with its ACL (access control list) resembles an application level firewall. However, both behave like filters that grant access (or not) to incoming requests.

We are going to go through all the levels each product is able to analyze a request and compare the two solutions.

Network level

Network level X-Pack Security ReadonlyREST
IP Address (free)
IP Mask (free)

Although it is possible to explicitly block a set of IP addresses and masks in X-Pack, this will act as a global pre-filter. That is, X-Pack will block the request before even running the RBAC logic.

xpack.security.transport.filter.allow: "192.168.0.1"
xpack.security.transport.filter.deny: "192.168.0.0/24"

In ReadonlyREST, you can use network level filtering as ACL rules. This is way more versatile:

readonlyrest:
    access_control_rules:
    - name: "let localhost in"
      type: allow
      hosts: ["127.0.0.1"]
      
    - name: "let LAN in, but they see only logstash indices"
      type: allow
      hosts: ["10.0.0.0/16"]
      indices: ["logstash*"]
  
    # Implicitly reject any other requests

If it wasn’t clear enough, the above example literally reads:

  1. Does the request originate from 127.0.0.1? Then let it through.
  2. Does the request come from the local network AND refers to one or more indices whose name starts with “logstash”? Then let it through.
  3. If none of the above is verified, reject the request.

HTTP Level

HTTP level X-Pack Security ReadonlyREST
Path (free)
Method (free)
Body length (free)

X-Pack mainly takes access control decisions at the Elasticsearch level (actions, indices).
ReadonlyREST can build ACLs at many levels, including HTTP.

Elasticsearch level

Elasticsearch level X-Pack Security ReadonlyREST
indices (free)
actions (coarse granularity) (free)
snapshots (free)

In the Elasticsearch protocol, all operations clients or cluster members can perform, are internally named with a string called “action“.

Example of actions:

 	indices:data/read/msearch
 	indices:data/write/bulk
 	indices:data/write/delete

You can see all the actions available in Elasticsearch in the our documentation.

Now, a list of actions represents the most granular, detailed way to describe what kind of operations are allowed or forbidden to a client. And this is exactly what ReadonlyREST allows you to do.

X-Pack instead took a different design decision that groups actions into non intersecting sets, called “privileges“. This is a handy tradeoff, but without the possibility to specify single actions, may be a bit too coarse grained.

Completely missing in X-Pack is instead the control on managing snapshots by name. I.e. the possibility to give a user the ability to restore only snapshots named after them. I.e.

readonlyrest:
    access_control_rules:
    - name: "users can create/restore snapshots prefixed witht their name"
      type: allow
      ldap_authentication: ldap1
      snapshots: [${user}_snapshot*]

Auditing

X-Pack Security ReadonlyREST
write to file (free)
write to time-rolling index (free)
be selective on what to log (free)
custom serializer API (free)
forward logs to another ES cluster

User experience

X-Pack settings can be changed from either file, in-index settings, CLI tools or API calls. The API is organised in a very granular way. There is an endpoint for everything. This makes it simpler for developers to integrate very specific pieces of automation because there’s a smaller probability to accidentally affect other features’ settings.

ReadonlyREST takes a way simpler approach: the settings is a monolithic entity, an immutable object that can be either loaded from file (readonlyrest.yml), loaded from index (.readonlyrest) or overridden entirely, or rejected (if invalid) via a single API endpoint.

UX Warts

X-Pack

X-Pack suffers a fragmented interaction model: despite the numerous way to alter settings, they are not equipotent. For example LDAP/SAML authorization won’t work before adding role mappings. And the only way to do it is via API i.e. with cURL instead of editing a YAML file like usual.

ReadonlyREST

Monolithic settings object. Will need to submit the whole settings to change a small thing.

There is no form-based GUI to add local users/groups like in X-Pack. Only a semigraphical UI with a syntax checked and validated YAML editor.

Authentication

Who are you? Authentication connectors are crucial for security, and for enabling seamless integration with the existing enterprise infrastructure.

Both the solutions support the major enterprise grade authentication systems, but what happens when the we need to integrate with a rare/custom authentication system?

X-Pack requires you to implement two Java classes, with ReadonlyREST, we can simply delegate the task to a well known, battle tested reverse proxy. If Apache HTTPD, Nginx, or any other reverse proxy can handle it, we can handle it.

X-Pack Security ReadonlyREST
Unix Style password shadowing (free)
Hashed credentials in cache (free)
Basic HTTP (free)
LDAP (free)
SAML coming soon
JWT (free)
Reverse Proxy (X-Forwarded-User) (free)
External site Basic HTTP (free)
Custom authentication (requires Java code) (via rev. proxy)

Authorization

X-Pack Security ReadonlyREST
Local groups (free)
LDAP (free)
Reverse Proxy (X-Forwarded-Groups) (free)
External JSON service (free)
LDAP group mapping (free)
Custom authorization (requires Java code) (via rev. proxy)

Kibana User Experience

X-Pack Security ReadonlyREST
Remove Kibana apps from UI (PRO/Enterprise)
Hide add/edit/delete buttons (RO users) (PRO/Enterprise)
Multi user (PRO/Enterprise)
Multi tenancy (Enterprise)
Tenant impersonation (Enterprise)

 

Conclusions

All in all, if what you are after is strictly a security solution for the Elastic stack (Kibana, Elasticsearch, Logstash, Beats, etc), ReadonlyREST Enterprise offers much more value for the price. And the contract includes private SLA support too.

If you need all the extras of X-Pack (i.e. machine learning, SQL, Graph relationships) the only choice is to buy from Elastic.