Secured API-Keys in elastic


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.

More info:

There's templated searches that might match this, same with a filtered alias. Which specific part are you interested in?

Hi @warkolm

It doesn't seem to be, no.

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 ( 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. :slight_smile:

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)?

Ahh it's a bit deeper than I thought then :slight_smile:

Lemme move this to the X-Pack section as one of the devs there will have a better idea!

1 Like

Thanks @warkolm :slight_smile:

I wonder if there is anything with JWT we could use here?!

I would look at using PKI authentication to solve this today:

You give each user a different certificate for authentication, no worries about having to share a single certificate.

We don't currently support JWT for authentication.

1 Like

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.

If a user leaves the organization you would remove their username from the role mapping file.

Then you would configure Role Based Access Control to determine what a given user can or can't do.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.