With Algolia we use Secured API-Keys feature and we really like it. We're wondering is there anything similar that we could use with Elastic?
Here is how Algolia's docs describe it:
The goal of a secured API key is to ensure a set of query parameters cannot be changed by the end user. In order to do that, we compute a HMAC SHA-256 hash between one of your API keys that is used as a secret and the set of query parameters you want to enforce.
On your backend, you use our API Client to compute the hash with a set of query parameters that you want to have applied in a secure way. The method to do that is generate_secured_api_key. The input is the API key that you want to use and the query parameters. The output is a hash containing inputs encoded in base 64. This method is just a hash computation, there is no network call to our service.
You pass this hash to the end-user browser or mobile app and the string is used as an API Key.
In our backend, we will scan all of your API keys and compute the hash corresponding to the set of query parameters. When the hash matches one key, this key, and associated restrictions, will be used to perform the query and the query parameters will be used. If the user tries to change the forced query parameters in the string, then the hash won’t match and the query will be rejected.
The HMAC Keys from Algolia let us provide each logged in user to the site with their own key to access Algolia directly via the client. This means we dont have to hand each user a non-expiring global key; each user has their own key which has short-expiry and can even be restricted in its own way (ie limited to specific indexes or preset filters (this is possibly where templates share some features)).
From what I can see, there is no such feature in Elastic.
Currently, we route Elastic searches through a Rails app to protect the access key. This lets us use Rails (via Warden and Devise) to authenticate the requests. Obviously, this adds overhead to each search in both request speed and server load. It would be nice for the client to hit Elastic directly.
We are moving to 5.x imminently, so it looks like X-Pack (https://www.elastic.co/guide/en/x-pack/current/how-security-works.html) is the way forward. It seems we could define a restricted user for the frontend (eg read-only, etc), but we will have to send those user credentials in plain text to our users. That's not great.
LDAP and AD are not really valid options here.
How hard is PKI to setup? Doesn't this still suffer the same problem that we'll be giving out the same cert to all users?
The Algolia HMAC system uses a single base key as part of the generated key for each user:
Are there any documented examples of how to securely use Elastic Search in a frontend JS application (like Ember, Angular or React)?
Thanks @joshbressers - so does this mean we need one certificate setup in Elastic per user? If we onboard a new user, we have to setup a new cert (and the reverse; when we remove users, we remove certs?)
You would sign the user certificates with a trusted certificate authority. Only the users would need certificates on their end. The server only needs a copy of the public CA certificate.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
