1

I've got an elasticsearch instance, with an Nginx reverse proxy sat in front of it, implementing a URL level access control mechanism - approximately as described in this article

This is giving me per-index granularity, which is handy.

What I'm trying to figure out next though is - can I enforce a blanket filter criteria that excludes results from searches and direct document retrievals?

I'm thinking a 'group' model, where docs in my indices are tagged by group, and users can only see results and docs for their group.

Now, I know I could do a per-group index, and apply URL level controls. That may be my workaround if I can't do this.

I have had a look at aliasing - this seems to do 90% of what I want, in that I can restrict a search to an alias. But what I can't then do is inhibit a direct 'GET' request with an (unauthorised) document ID.

Is there a way of doing this, or am I just on a road to nowhere?

Note - part of my reasons for this, is I'm trying to use a fairly standard kibana setup, and I have overlapping groups of users.

2 Answers 2

1

While I can't directly answer your question (+1), I wanted to point out that the people working at elastic finally listened to all the requests made by people demanding access control for Elasticsearch and introduced Shield. Quoting the website:

With the rapid adoption of Elasticsearch, it is easier than ever to store, search, and analyze your data. Shield allows you to easily protect this data with a username and password, while simplifying your architecture. Advanced security features like encryption, role-based access control, IP filtering, and auditing are also available when you need them.

Your data is increasingly your most valuable asset. Password protect it with Shield.

Maybe having a look at least to check if this fulfills your requirements would be worth.

7
  • I had a look at shield. I'd been shying away a little, as I'm still at 'proof-of-concept' and shield is a costed extra. But it does look like it implements the document level security (query-based) that I'm interested in.
    – Sobrique
    Jan 13, 2016 at 12:29
  • @Sobrique What do you mean by "is a costed extra"? Could you elaborate? You mean it's "not for free"? (Sorry, I'm not a native English speaker.)
    – gxx
    Jan 13, 2016 at 12:59
  • Yes. You need a subscription to use it.
    – Sobrique
    Jan 13, 2016 at 13:32
  • @Sobrique AFAIK (and just verified this right now again) this is not the case. Installing the license and shield itself doesn't require a subscription.
    – gxx
    Jan 13, 2016 at 13:47
  • Isn't the license a 30d trial?
    – Sobrique
    Jan 13, 2016 at 13:51
1

While starting a new project today at work with Elasticsearch I did some research and found Search Guard - Elasticsearch security for free. Obviously I can't judge (yet) how good this works but wanted to leave a pointer here in case you or others are still searching for (a) solution(s), and in case Shield can't be used, for whatever reasons.

Quoting the website, these are the features:

  • Flexible REST layer access control (User/Role based; on aliases, indices and types)
  • Flexible transport layer access control (User/Role based; on aliases, indices and types)
  • Document level security (DLS): Retrieve only documents matching criterias
  • Field level security (FLS): Filter out fields/sourceparts from a search response
  • HTTP authentication (Basic, Proxy header, SPNEGO/Kerberos, Mutual SSL/CLIENT-CERT)
  • HTTP session support through cookies
  • Flexible authentication backends (LDAP(s)/Active Directory, File based, Proxy header, Native Windows through WAFFLE)
  • Flexible authorization backends (LDAP(s)/Active Directory, File based, Native Windows through WAFFLE)
  • Node-to-node encryption through SSL/TLS (Transport layer)
  • Secure REST layer through HTTPS (SSL/TLS)
  • X-Forwarded-For (XFF) support
  • Audit logging
  • Anonymous login/unauthenticated access
  • Works with Kibana 4 and logstash

But, there are limitations as well:

  • When using DLS or FLS you can still search in all documents/fields but not all documents/fields are returned
  • Transport layer access control only with simple username/password login
  • No automatic multi index filters (see below)
  • Currently monitoring of the cluster needs no authentication and is allowed always (this may change in the future)

Maybe this is helpful and of value for you or someone else, who comes across this post.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .