Unix-like permissions and confidential documents in Elasticsearch

Elastic Stack Elasticsearch
1

Hi,

I have been trying to find a way to handle document access rights in
Elasticsearch. I have come up with a solution and written a few words
trying to explain it in a blog.

In order to avoid duplication, I'm not going to repeat it all here but the
general idea is to create a script that checks a document's user groups
against a list passed in the query.
I'm posting it here because it would be good to have feedback from people
who know a lot more about elasticsearch than I do. Also, would anyone know
if there is a way of optimising it?
Thanks

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/94ec8170-89e1-4f85-af1d-bf0828e5d7d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

From your blog:

"Elasticsearch has no in-built way to say that only certain people can find
certain documents and there's no indication that will change."

This is not true. Elasticsearch is multi-tenant. You can user filter
aliases to forward requests to the docs a tenant is restricted to.

Examples:

http://opennomad.com/content/controlling-access-elasticsearch-filtered-aliases-nginx-and-tokens

Jörg

On Mon, Dec 1, 2014 at 11:23 AM, dylan.bowden@enalean.com wrote:

Hi,

I have been trying to find a way to handle document access rights in
Elasticsearch. I have come up with a solution and written a few words
trying to explain it in a blog.
https://www.tuleap.org/elasticsearch-dealing-complex-permissions

In order to avoid duplication, I'm not going to repeat it all here but the
general idea is to create a script that checks a document's user groups
against a list passed in the query.
I'm posting it here because it would be good to have feedback from people
who know a lot more about elasticsearch than I do. Also, would anyone know
if there is a way of optimising it?
Thanks

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94ec8170-89e1-4f85-af1d-bf0828e5d7d2%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94ec8170-89e1-4f85-af1d-bf0828e5d7d2%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFQKkZxCzQL%2BZpeH9bAQGtBCMcQK30b2zE6hA8HtXX6rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

3

You're right, I will correct the blog accordingly.

However, if I'm understanding the nginx solution correctly, it does require
that each document is indexed with all the people that can access it or
doesn't it? The downside of that would be that each time a user is added/
removed to/ from a user group then all relevant documents would need to be
re-indexed (which could be massive). Also, there may be thousands or tens
of thousands of people that could access a particular document.
Also, if I decided to use the nginx solution (with user groups instead of
users) then I would still need a custom script to handle "the user must be
a member of this or that combination of user groups" scenario, wouldn't I?

Le lundi 1 décembre 2014 10:30:31 UTC, Jörg Prante a écrit :

From your blog:

"Elasticsearch has no in-built way to say that only certain people can
find certain documents and there's no indication that will change."

This is not true. Elasticsearch is multi-tenant. You can user filter
aliases to forward requests to the docs a tenant is restricted to.

Examples:

Elasticsearch Platform — Find real-time answers at scale | Elastic

http://opennomad.com/content/controlling-access-elasticsearch-filtered-aliases-nginx-and-tokens

Jörg

On Mon, Dec 1, 2014 at 11:23 AM, <dylan....@enalean.com <javascript:>>
wrote:

Hi,

I have been trying to find a way to handle document access rights in
Elasticsearch. I have come up with a solution and written a few words
trying to explain it in a blog.
https://www.tuleap.org/elasticsearch-dealing-complex-permissions

In order to avoid duplication, I'm not going to repeat it all here but
the general idea is to create a script that checks a document's user groups
against a list passed in the query.
I'm posting it here because it would be good to have feedback from people
who know a lot more about elasticsearch than I do. Also, would anyone know
if there is a way of optimising it?
Thanks

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/94ec8170-89e1-4f85-af1d-bf0828e5d7d2%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/94ec8170-89e1-4f85-af1d-bf0828e5d7d2%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/0bd7d7b2-d38c-43ed-a65a-5764fb6abef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.