Elasticsearch access control based on field value

I am currently investigating the ELK (Elasticsearch, Logstash, Kibana)
stack for centralized log file analysis.

The plan is to store logs of multiple applications in the same
Elasticsearch cluster using logstash and day-based indexes.

All documents contain a field called application, e.g."application":
"superapp".

Now we are looking for a way to implement access control like this:

A) Superuser: is able to see log entries of all applications.

B) Developer: can only see log entries of the applications he is allowed
to. For example the dev team for application "superapp" should only be able
to see the entries for this application.

To wrap it up: we need access control based on the value in the field
application.

While reading the documentation for Elastisearch and Shield I could not
find an obvious way to do it.

Any ideas how we could realize this in a way that would also work with
Kibana 3 and 4?

My first idea was to use aliases which are being automatically assigned to
documents using index templates. I am wondering if this is the right
direction.

--
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/54593215-2f62-47c5-ac87-5e3515a9b916%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Aliases + shield will definitely do this.

On 27 March 2015 at 19:39, Philipp R. p.rossberger@googlemail.com wrote:

I am currently investigating the ELK (Elasticsearch, Logstash, Kibana)
stack for centralized log file analysis.

The plan is to store logs of multiple applications in the same
Elasticsearch cluster using logstash and day-based indexes.

All documents contain a field called application, e.g."application":
"superapp".

Now we are looking for a way to implement access control like this:

A) Superuser: is able to see log entries of all applications.

B) Developer: can only see log entries of the applications he is
allowed to. For example the dev team for application "superapp" should only
be able to see the entries for this application.

To wrap it up: we need access control based on the value in the field
application.

While reading the documentation for Elastisearch and Shield I could not
find an obvious way to do it.

Any ideas how we could realize this in a way that would also work with
Kibana 3 and 4?

My first idea was to use aliases which are being automatically assigned to
documents using index templates. I am wondering if this is the right
direction.

--
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/54593215-2f62-47c5-ac87-5e3515a9b916%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%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/CAEYi1X_41dhfdHAp0C-wKgBLh3CpppiMUeiDc6wEd7ToN8%2Baaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Hi Mark,

could you please elaborate a little more detailed how this could be done?
Would you suggest indexes per application and tie them together via
aliases? Still wonder how this could be integrated into Kibana...

Best regards,

Philipp

Am Freitag, 27. März 2015 10:17:37 UTC+1 schrieb Mark Walkom:

Aliases + shield will definitely do this.

On 27 March 2015 at 19:39, Philipp R. <p.ross...@googlemail.com
<javascript:>> wrote:

I am currently investigating the ELK (Elasticsearch, Logstash, Kibana)
stack for centralized log file analysis.

The plan is to store logs of multiple applications in the same
Elasticsearch cluster using logstash and day-based indexes.

All documents contain a field called application, e.g."application":
"superapp".

Now we are looking for a way to implement access control like this:

A) Superuser: is able to see log entries of all applications.

B) Developer: can only see log entries of the applications he is
allowed to. For example the dev team for application "superapp" should only
be able to see the entries for this application.

To wrap it up: we need access control based on the value in the field
application.

While reading the documentation for Elastisearch and Shield I could not
find an obvious way to do it.

Any ideas how we could realize this in a way that would also work with
Kibana 3 and 4?

My first idea was to use aliases which are being automatically assigned
to documents using index templates. I am wondering if this is the right
direction.

--
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/54593215-2f62-47c5-ac87-5e3515a9b916%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%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/bf6b1a97-060d-43cb-b1ab-53d0172eb39e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

This is where it gets hard and you need to leverage your own domain
knowledge.

You can separate out the different types of logs into their own indices
which would make things much easier, you could also setup an alias with a
filter and then provide access to that alias to certain users.
Currently KB isn't multi-tenanted but it is a feature that is going to be
added, you'd have to setup multiple instances with each going to their own
alias.

On 27 March 2015 at 21:24, Philipp R. p.rossberger@googlemail.com wrote:

Hi Mark,

could you please elaborate a little more detailed how this could be done?
Would you suggest indexes per application and tie them together via
aliases? Still wonder how this could be integrated into Kibana...

Best regards,

Philipp

Am Freitag, 27. März 2015 10:17:37 UTC+1 schrieb Mark Walkom:

Aliases + shield will definitely do this.

On 27 March 2015 at 19:39, Philipp R. p.ross...@googlemail.com wrote:

I am currently investigating the ELK (Elasticsearch, Logstash, Kibana)
stack for centralized log file analysis.

The plan is to store logs of multiple applications in the same
Elasticsearch cluster using logstash and day-based indexes.

All documents contain a field called application, e.g."application":
"superapp".

Now we are looking for a way to implement access control like this:

A) Superuser: is able to see log entries of all applications.

B) Developer: can only see log entries of the applications he is
allowed to. For example the dev team for application "superapp" should only
be able to see the entries for this application.

To wrap it up: we need access control based on the value in the field
application.

While reading the documentation for Elastisearch and Shield I could not
find an obvious way to do it.

Any ideas how we could realize this in a way that would also work with
Kibana 3 and 4?

My first idea was to use aliases which are being automatically assigned
to documents using index templates. I am wondering if this is the right
direction.

--
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.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%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/bf6b1a97-060d-43cb-b1ab-53d0172eb39e%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/bf6b1a97-060d-43cb-b1ab-53d0172eb39e%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/CAEYi1X-nqgdnkyfKtbeUwQPOWXdfbGs3LcJArFvA%3DS3ij4q3CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

When you mention to "setup an alias with a filter", you mean a setup along
these lines,
right? http://www.elastic.co/guide/en/elasticsearch/guide/master/faking-it.html

Regarding search performance: would you recommend using aliases+filters or
separate indexes per application?

Am Samstag, 28. März 2015 06:46:00 UTC+1 schrieb Mark Walkom:

This is where it gets hard and you need to leverage your own domain
knowledge.

You can separate out the different types of logs into their own indices
which would make things much easier, you could also setup an alias with a
filter and then provide access to that alias to certain users.
Currently KB isn't multi-tenanted but it is a feature that is going to be
added, you'd have to setup multiple instances with each going to their own
alias.

On 27 March 2015 at 21:24, Philipp R. <p.ross...@googlemail.com
<javascript:>> wrote:

Hi Mark,

could you please elaborate a little more detailed how this could be done?
Would you suggest indexes per application and tie them together via
aliases? Still wonder how this could be integrated into Kibana...

Best regards,

Philipp

Am Freitag, 27. März 2015 10:17:37 UTC+1 schrieb Mark Walkom:

Aliases + shield will definitely do this.

On 27 March 2015 at 19:39, Philipp R. p.ross...@googlemail.com wrote:

I am currently investigating the ELK (Elasticsearch, Logstash, Kibana)
stack for centralized log file analysis.

The plan is to store logs of multiple applications in the same
Elasticsearch cluster using logstash and day-based indexes.

All documents contain a field called application, e.g."application":
"superapp".

Now we are looking for a way to implement access control like this:

A) Superuser: is able to see log entries of all applications.

B) Developer: can only see log entries of the applications he is
allowed to. For example the dev team for application "superapp" should only
be able to see the entries for this application.

To wrap it up: we need access control based on the value in the field
application.

While reading the documentation for Elastisearch and Shield I could not
find an obvious way to do it.

Any ideas how we could realize this in a way that would also work with
Kibana 3 and 4?

My first idea was to use aliases which are being automatically assigned
to documents using index templates. I am wondering if this is the right
direction.

--
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.
To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%
40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/54593215-2f62-47c5-ac87-5e3515a9b916%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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/bf6b1a97-060d-43cb-b1ab-53d0172eb39e%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/bf6b1a97-060d-43cb-b1ab-53d0172eb39e%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/c24b62c6-03f2-4787-bf9d-894d7dad671a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.