return results if field equals username

Search Guard
1

per the documentation I should be able to allow/block a record if a field contains the elasticsearch user as a value. However, I haven’t been able to get this to work.

However, if i hard code the field value (filter b in the examples from documentation below), It works correctly. However, that doesn’t really work since we’re going to have a lot of kibana users in elasticsearch. It would be nice if I could just match against the logged in user.

When I have access control configured to match against current user kibana shows all records not just the records for that user. I have tried both false and true field conditions but neither work. I also tried using the logstash .raw fields but that doesn’t work either.

from documentation:

searchguard.dlsfilter.names: [“a”, “b”, “c”, “d”, “e”, “f”, “g”]

searchguard.dlsfilter.d: [“user_name”,“field”, “false”]

searchguard.dlsfilter.b: [“term”, “field”,“value”, “false”]

searchguard.dlsfilter.e: [“user_roles”,“field”, “false”]

…

elasticsearch.yml:

searchguard.authentication.settingsdb.user.test1: test1

searchguard.authentication.settingsdb.user.test2: test2

searchguard.authentication.authorization.settingsdb.roles.test1: [“kibana”,“loguser”]

searchguard.authentication.authorization.settingsdb.roles.test2: [“kibana”,“loguser”]

#filter by field value

searchguard.dlsfilter.names: [“acc_test1”,“acc_test2”,“acc_false”,“acc_true”]

searchguard.dlsfilter.acc_test1: [“term”, “account”, “test1”, “false”]

searchguard.dlsfilter.acc_test2: [“term”, “account”, “test2”, “false”]

searchguard.dlsfilter.acc_false: [“account”,“field”, “false”]

searchguard.dlsfilter.acc_true: [“account”,“field”, “true”]

curl -XPUT ‘http://localhost:9200/searchguard/ac/ac?pretty’ -d ’

{“acl”: [

{

“Comment”: “Default is to execute no filters - return no results”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “kibana index”,

“roles” : [“kibana”],

“indices”: [“kibana-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash indices read/write”,

“roles” : [“logstash”],

“indices”: [“logstash-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash test org”,

“users” : [“test1”],

“indices”: [“logstash-*”],

“filters_bypass”: ,

“filters_execute”: [“dlsfilter.acc_false”]

}

]}’

Log’s aren’t really that helpful:

[2015-11-11 12:26:20,538][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,542][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,543][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:admin/get (class org.elasticsearch.action.admin.indices.get.GetIndexRequest) due to types method not found

…

2

I turned on debug log and was able to get some more details. However, I’m not really sure what it means.

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[test1], roles=null, indices=[logstash-*], aliases=null, filters_execute=[dlsfilter.acc_false], filters_bypass=, isDefault()=false, Comment=“logstash test org”]

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User test1 match

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request logstash-2015.11.11, granted logstash-, requestedTypes []

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: logstash-2015.11.11 → logstash-*

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: logstash-2015.11.11 → logstash-*

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index logstash-2015.11.11 match logstash-*

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index logstash-2015.11.11 has a matching pattern

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [dlsfilter.acc_false]/bypassFilters:

[2015-11-11 12:31:48,041][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [dlsfilter.acc_false]/bypassFilters:

[2015-11-11 12:31:48,044][DEBUG][com.floragunn.searchguard.filter.level.ConfigurableSearchContextCallback] will bypass

[2015-11-11 12:31:48,044][DEBUG][com.floragunn.searchguard.filter.level.ConfigurableSearchContextCallback] will bypass

[2015-11-11 12:31:48,044][DEBUG][com.floragunn.searchguard.filter.level.ConfigurableSearchContextCallback] will bypass

[2015-11-11 12:31:48,651][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] REQUEST on node estest: indices:data/read/get (class org.elasticsearch.action.get.GetRequest) from INTRANODE

[2015-11-11 12:31:48,651][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] Context

[2015-11-11 12:31:48,651][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] Headers

[2015-11-11 12:31:48,651][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] TYPE: intra node request, skip filters

···

On Wednesday, November 11, 2015 at 12:27:25 PM UTC-8, Rory Schramm wrote:

per the documentation I should be able to allow/block a record if a field contains the elasticsearch user as a value. However, I haven’t been able to get this to work.

However, if i hard code the field value (filter b in the examples from documentation below), It works correctly. However, that doesn’t really work since we’re going to have a lot of kibana users in elasticsearch. It would be nice if I could just match against the logged in user.

When I have access control configured to match against current user kibana shows all records not just the records for that user. I have tried both false and true field conditions but neither work. I also tried using the logstash .raw fields but that doesn’t work either.

from documentation:

searchguard.dlsfilter.names: [“a”, “b”, “c”, “d”, “e”, “f”, “g”]

searchguard.dlsfilter.d: [“user_name”,“field”, “false”]

searchguard.dlsfilter.b: [“term”, “field”,“value”, “false”]

searchguard.dlsfilter.e: [“user_roles”,“field”, “false”]

…

elasticsearch.yml:

searchguard.authentication.settingsdb.user.test1: test1

searchguard.authentication.settingsdb.user.test2: test2

searchguard.authentication.authorization.settingsdb.roles.test1: [“kibana”,“loguser”]

searchguard.authentication.authorization.settingsdb.roles.test2: [“kibana”,“loguser”]

#filter by field value

searchguard.dlsfilter.names: [“acc_test1”,“acc_test2”,“acc_false”,“acc_true”]

searchguard.dlsfilter.acc_test1: [“term”, “account”, “test1”, “false”]

searchguard.dlsfilter.acc_test2: [“term”, “account”, “test2”, “false”]

searchguard.dlsfilter.acc_false: [“account”,“field”, “false”]

searchguard.dlsfilter.acc_true: [“account”,“field”, “true”]

curl -XPUT ‘http://localhost:9200/searchguard/ac/ac?pretty’ -d ’

{“acl”: [

{

“Comment”: “Default is to execute no filters - return no results”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “kibana index”,

“roles” : [“kibana”],

“indices”: [“kibana-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash indices read/write”,

“roles” : [“logstash”],

“indices”: [“logstash-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash test org”,

“users” : [“test1”],

“indices”: [“logstash-*”],

“filters_bypass”: ,

“filters_execute”: [“dlsfilter.acc_false”]

}

]}’

Log’s aren’t really that helpful:

[2015-11-11 12:26:20,538][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,542][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,543][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:admin/get (class org.elasticsearch.action.admin.indices.get.GetIndexRequest) due to types method not found

…

3

hardcoded account filter shows this in logs by comparison:

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[test1], roles=null, indices=[logstash-*], aliases=null, filters_execute=[dlsfilter.acc_test1], filters_bypass=, isDefault()=false, Comment=“logstash test org”]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User test1 match

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request logstash-2015.11.11, granted logstash-, requestedTypes []

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: logstash-2015.11.11 → logstash-*

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: logstash-2015.11.11 → logstash-*

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index logstash-2015.11.11 match logstash-*

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index logstash-2015.11.11 has a matching pattern

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [dlsfilter.acc_test1]/bypassFilters:

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [dlsfilter.acc_test1]/bypassFilters:

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] REQUEST on node estest: indices:data/read/search (class org.elasticsearch.action.search.SearchRequest) from INTRANODE

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] Context [searchguard.dlsfilter.acc_false.filters=>[account, field, false], searchguard.dlsfilter.acc_test2.filters=>[term, account, test2, false], searchguard_authenticated_user=>User [name=test1, roles=[loguser, kibana]], searchguard_filter=>[dlsfilter:acc_false, dlsfilter:acc_true, dlsfilter:acc_test2, dlsfilter:acc_test1], searchguard.dlsfilter.acc_test1.filters=>[term, account, test1, false], _searchguard_token_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator@391b1543, searchguard_resolved_rest_address=>dc1.preprod.local/172.16.31.60, searchguard.dlsfilter.acc_true.filters=>[account, field, true], searchguard_ac_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator@4de47fa7]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] Headers [searchguard.dlsfilter.acc_true.filters, searchguard.dlsfilter.acc_false.filters, searchguard_authenticated_user, searchguard.dlsfilter.acc_test1.filters, searchguard_ac_evaluator, searchguard_filter, searchguard_resolved_rest_address, searchguard.dlsfilter.acc_test2.filters]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.RequestActionFilter] TYPE: rest authenticated request, apply filters

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.DLSActionFilter] REQUEST on node estest: indices:data/read/search (class org.elasticsearch.action.search.SearchRequest) from INTRANODE

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.DLSActionFilter] Context [searchguard.dlsfilter.acc_false.filters=>[account, field, false], searchguard.dlsfilter.acc_test2.filters=>[term, account, test2, false], searchguard_authenticated_user=>User [name=test1, roles=[loguser, kibana]], searchguard_filter=>[dlsfilter:acc_false, dlsfilter:acc_true, dlsfilter:acc_test2, dlsfilter:acc_test1], searchguard.dlsfilter.acc_test1.filters=>[term, account, test1, false], _searchguard_token_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator@391b1543, searchguard_resolved_rest_address=>dc1.preprod.local/172.16.31.60, searchguard.dlsfilter.acc_true.filters=>[account, field, true], searchguard_ac_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator@4de47fa7]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.DLSActionFilter] Headers [searchguard.dlsfilter.acc_true.filters, searchguard.dlsfilter.acc_false.filters, searchguard_authenticated_user, searchguard.dlsfilter.acc_test1.filters, searchguard_ac_evaluator, searchguard_filter, searchguard_resolved_rest_address, searchguard.dlsfilter.acc_test2.filters]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.DLSActionFilter] TYPE: rest authenticated request, apply filters

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.FLSActionFilter] REQUEST on node estest: indices:data/read/search (class org.elasticsearch.action.search.SearchRequest) from INTRANODE

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.FLSActionFilter] Context [searchguard.dlsfilter.acc_false.filters=>[account, field, false], searchguard.dlsfilter.acc_test2.filters=>[term, account, test2, false], searchguard_authenticated_user=>User [name=test1, roles=[loguser, kibana]], searchguard_filter=>[dlsfilter:acc_false, dlsfilter:acc_true, dlsfilter:acc_test2, dlsfilter:acc_test1], searchguard.dlsfilter.acc_test1.filters=>[term, account, test1, false], _searchguard_token_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator@391b1543, searchguard_resolved_rest_address=>dc1.preprod.local/172.16.31.60, searchguard.dlsfilter.acc_true.filters=>[account, field, true], searchguard_ac_evaluator=>com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator@4de47fa7]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.FLSActionFilter] Headers [searchguard.dlsfilter.acc_true.filters, searchguard.dlsfilter.acc_false.filters, searchguard_authenticated_user, searchguard.dlsfilter.acc_test1.filters, searchguard_ac_evaluator, searchguard_filter, searchguard_resolved_rest_address, searchguard.dlsfilter.acc_test2.filters]

[2015-11-11 12:35:54,046][DEBUG][com.floragunn.searchguard.filter.FLSActionFilter] TYPE: rest authenticated request, apply filters

Just from comparing logs it doesn’t look like it event attempts to filter when using the username → field filter.

···

On Wednesday, November 11, 2015 at 12:27:25 PM UTC-8, Rory Schramm wrote:

per the documentation I should be able to allow/block a record if a field contains the elasticsearch user as a value. However, I haven’t been able to get this to work.

However, if i hard code the field value (filter b in the examples from documentation below), It works correctly. However, that doesn’t really work since we’re going to have a lot of kibana users in elasticsearch. It would be nice if I could just match against the logged in user.

When I have access control configured to match against current user kibana shows all records not just the records for that user. I have tried both false and true field conditions but neither work. I also tried using the logstash .raw fields but that doesn’t work either.

from documentation:

searchguard.dlsfilter.names: [“a”, “b”, “c”, “d”, “e”, “f”, “g”]

searchguard.dlsfilter.d: [“user_name”,“field”, “false”]

searchguard.dlsfilter.b: [“term”, “field”,“value”, “false”]

searchguard.dlsfilter.e: [“user_roles”,“field”, “false”]

…

elasticsearch.yml:

searchguard.authentication.settingsdb.user.test1: test1

searchguard.authentication.settingsdb.user.test2: test2

searchguard.authentication.authorization.settingsdb.roles.test1: [“kibana”,“loguser”]

searchguard.authentication.authorization.settingsdb.roles.test2: [“kibana”,“loguser”]

#filter by field value

searchguard.dlsfilter.names: [“acc_test1”,“acc_test2”,“acc_false”,“acc_true”]

searchguard.dlsfilter.acc_test1: [“term”, “account”, “test1”, “false”]

searchguard.dlsfilter.acc_test2: [“term”, “account”, “test2”, “false”]

searchguard.dlsfilter.acc_false: [“account”,“field”, “false”]

searchguard.dlsfilter.acc_true: [“account”,“field”, “true”]

curl -XPUT ‘http://localhost:9200/searchguard/ac/ac?pretty’ -d ’

{“acl”: [

{

“Comment”: “Default is to execute no filters - return no results”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “kibana index”,

“roles” : [“kibana”],

“indices”: [“kibana-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash indices read/write”,

“roles” : [“logstash”],

“indices”: [“logstash-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash test org”,

“users” : [“test1”],

“indices”: [“logstash-*”],

“filters_bypass”: ,

“filters_execute”: [“dlsfilter.acc_false”]

}

]}’

Log’s aren’t really that helpful:

[2015-11-11 12:26:20,538][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,542][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,543][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:admin/get (class org.elasticsearch.action.admin.indices.get.GetIndexRequest) due to types method not found

…

4

I was able to get this working.

The synax for the fields is a little confusing

correct maping for matching user against username field

searchguard.dlsfilter.d: [“user_name”,“my_username_field”, “false”]

However,

kibana graphs are bypassing the access control filters…

in attached picture, currently logged in user only has access to see log data for es01 host. However, kibana is graphing data for all hosts and users.

any idea’s on how to fix the acl filters so the data doesn’t get graphed by kibana?

using kibana 3.1.1

···

On Wednesday, November 11, 2015 at 12:27:25 PM UTC-8, Rory Schramm wrote:

per the documentation I should be able to allow/block a record if a field contains the elasticsearch user as a value. However, I haven’t been able to get this to work.

However, if i hard code the field value (filter b in the examples from documentation below), It works correctly. However, that doesn’t really work since we’re going to have a lot of kibana users in elasticsearch. It would be nice if I could just match against the logged in user.

When I have access control configured to match against current user kibana shows all records not just the records for that user. I have tried both false and true field conditions but neither work. I also tried using the logstash .raw fields but that doesn’t work either.

from documentation:

searchguard.dlsfilter.names: [“a”, “b”, “c”, “d”, “e”, “f”, “g”]

searchguard.dlsfilter.d: [“user_name”,“field”, “false”]

searchguard.dlsfilter.b: [“term”, “field”,“value”, “false”]

searchguard.dlsfilter.e: [“user_roles”,“field”, “false”]

…

elasticsearch.yml:

searchguard.authentication.settingsdb.user.test1: test1

searchguard.authentication.settingsdb.user.test2: test2

searchguard.authentication.authorization.settingsdb.roles.test1: [“kibana”,“loguser”]

searchguard.authentication.authorization.settingsdb.roles.test2: [“kibana”,“loguser”]

#filter by field value

searchguard.dlsfilter.names: [“acc_test1”,“acc_test2”,“acc_false”,“acc_true”]

searchguard.dlsfilter.acc_test1: [“term”, “account”, “test1”, “false”]

searchguard.dlsfilter.acc_test2: [“term”, “account”, “test2”, “false”]

searchguard.dlsfilter.acc_false: [“account”,“field”, “false”]

searchguard.dlsfilter.acc_true: [“account”,“field”, “true”]

curl -XPUT ‘http://localhost:9200/searchguard/ac/ac?pretty’ -d ’

{“acl”: [

{

“Comment”: “Default is to execute no filters - return no results”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “kibana index”,

“roles” : [“kibana”],

“indices”: [“kibana-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash indices read/write”,

“roles” : [“logstash”],

“indices”: [“logstash-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash test org”,

“users” : [“test1”],

“indices”: [“logstash-*”],

“filters_bypass”: ,

“filters_execute”: [“dlsfilter.acc_false”]

}

]}’

Log’s aren’t really that helpful:

[2015-11-11 12:26:20,538][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,542][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,543][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:admin/get (class org.elasticsearch.action.admin.indices.get.GetIndexRequest) due to types method not found

…

5

Hey Rory I now have the same problem, that the kibana charts bypasses the “user_role” dls filter. I’m stuck trying to fix this for a while now.
Can you share how you solved this?

Thanks a lot

···

On Thursday, November 12, 2015 at 12:27:35 AM UTC+2, Rory Schramm wrote:

I was able to get this working.

The synax for the fields is a little confusing

correct maping for matching user against username field

searchguard.dlsfilter.d: [“user_name”,“my_username_field”, “false”]

However,

kibana graphs are bypassing the access control filters…

in attached picture, currently logged in user only has access to see log data for es01 host. However, kibana is graphing data for all hosts and users.

any idea’s on how to fix the acl filters so the data doesn’t get graphed by kibana?

using kibana 3.1.1

On Wednesday, November 11, 2015 at 12:27:25 PM UTC-8, Rory Schramm wrote:

per the documentation I should be able to allow/block a record if a field contains the elasticsearch user as a value. However, I haven’t been able to get this to work.

However, if i hard code the field value (filter b in the examples from documentation below), It works correctly. However, that doesn’t really work since we’re going to have a lot of kibana users in elasticsearch. It would be nice if I could just match against the logged in user.

When I have access control configured to match against current user kibana shows all records not just the records for that user. I have tried both false and true field conditions but neither work. I also tried using the logstash .raw fields but that doesn’t work either.

from documentation:

searchguard.dlsfilter.names: [“a”, “b”, “c”, “d”, “e”, “f”, “g”]

searchguard.dlsfilter.d: [“user_name”,“field”, “false”]

searchguard.dlsfilter.b: [“term”, “field”,“value”, “false”]

searchguard.dlsfilter.e: [“user_roles”,“field”, “false”]

…

elasticsearch.yml:

searchguard.authentication.settingsdb.user.test1: test1

searchguard.authentication.settingsdb.user.test2: test2

searchguard.authentication.authorization.settingsdb.roles.test1: [“kibana”,“loguser”]

searchguard.authentication.authorization.settingsdb.roles.test2: [“kibana”,“loguser”]

#filter by field value

searchguard.dlsfilter.names: [“acc_test1”,“acc_test2”,“acc_false”,“acc_true”]

searchguard.dlsfilter.acc_test1: [“term”, “account”, “test1”, “false”]

searchguard.dlsfilter.acc_test2: [“term”, “account”, “test2”, “false”]

searchguard.dlsfilter.acc_false: [“account”,“field”, “false”]

searchguard.dlsfilter.acc_true: [“account”,“field”, “true”]

curl -XPUT ‘http://localhost:9200/searchguard/ac/ac?pretty’ -d ’

{“acl”: [

{

“Comment”: “Default is to execute no filters - return no results”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “kibana index”,

“roles” : [“kibana”],

“indices”: [“kibana-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash indices read/write”,

“roles” : [“logstash”],

“indices”: [“logstash-*”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “logstash test org”,

“users” : [“test1”],

“indices”: [“logstash-*”],

“filters_bypass”: ,

“filters_execute”: [“dlsfilter.acc_false”]

}

]}’

Log’s aren’t really that helpful:

[2015-11-11 12:26:20,538][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,542][INFO ][com.floragunn.searchguard.rest.DefaultRestFilter] Authenticated user is User [name=test1, roles=[logreader, kibana]]

[2015-11-11 12:26:20,543][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:admin/get (class org.elasticsearch.action.admin.indices.get.GetIndexRequest) due to types method not found

…