Courier Fetch Error

Search Guard
1

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {"_index":".kibana","_type":"config","_id":"4.0.1","error":"RuntimeException[java.lang.RuntimeException: Action 'indices:data/read/mget[shard]' is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard]' is forbidden due to DEFAULT]; "}

at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26)
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30)
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22)
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81)
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81)
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

···

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from Using Kibana with Shield | Shield [2.4] | Elastic. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.
2

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

···

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.
3

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

···

Kibana: Not Found

Error: Not Found

at respond (http://xxx/index.js?_b=5930:81566:15)

at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7)

at http://xxx/index.js?_b=5930:80203:7

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at http://xxx/index.js?_b=5930:21015:76

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.
4

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.
···

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond (http://xxx/index.js?_b=5930:81566:15)

at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7)

at http://xxx/index.js?_b=5930:80203:7

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at http://xxx/index.js?_b=5930:21015:76

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.
5

add “indices:admin/mappings/fields/get*” (or indices:admin/mappingsget") to the allowed actions.

“DEFAULT” means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

···

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond (http://xxx/index.js?_b=5930:81566:15)

at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7)

at http://xxx/index.js?_b=5930:80203:7

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at http://xxx/index.js?_b=5930:21015:76

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.
6

Discover: Cannot read property ‘indexOf’ of undefined

TypeError: Cannot read property ‘indexOf’ of undefined

at Notifier.error (http://xxx/index.js?_b=5930:45607:23)

at Notifier.bound (http://xxx/index.js?_b=5930:32081:21)

at http://xxx/index.js?_b=5930:118772:18

at wrappedCallback (http://xxx/index.js?_b=5930:20873:81)

at http://xxx/index.js?_b=5930:20959:26

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

at done (http://xxx/index.js?_b=5930:17641:45)

at completeRequest (http://xxx/index.js?_b=5930:17855:7)

In the Elasticsearch debug logs, I see the following :-

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actionrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted .kibana, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match .kibana

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted ea, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match ea

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Index abc does not have a matching pattern, skip this rule

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: /bypassFilters:

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.transport.SearchGuardNettyTransport] [xxx_client] send indices:admin/validate/query[s] from xxx_client to yyy_data

[2015-06-10 12:28:33,779][ERROR][com.floragunn.searchguard.filter.SearchGuardActionFilter] Error while apply() due to com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all for action indices:data/read/msearch

com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all

at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.validateAndMerge(TokenEvaluator.java:374)

at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.(TokenEvaluator.java:362)

at com.floragunn.searchguard.tokeneval.TokenEvaluator.getEvaluator(TokenEvaluator.java:310)

My allowed_actions list already contains __“indices:data/read/*” __:-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get*”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

Thanx !

  • mahesh.
···

On Wednesday, June 10, 2015 at 2:00:34 PM UTC+5:30, in...@search-guard.com wrote:

“DEFAULT” means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond (http://xxx/index.js?_b=5930:81566:15)

at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7)

at http://xxx/index.js?_b=5930:80203:7

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at http://xxx/index.js?_b=5930:21015:76

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.

add “indices:admin/mappings/fields/get*” (or indices:admin/mappingsget") to the allowed actions.

I added “indices:admin/mappings/fields/get*” to the allowed actions. I now see the following error :-

7

hi,

I dont know what else I can try here. I am attaching the Elasticsearch and kibana logs. I see an error in the Elasticsearch logs, but, nothing in the kibana logs.

Thanx !

  • mahesh.

elasticsearch-test1.log (204 KB)

kibana.log (21.6 KB)

···

On Wednesday, June 10, 2015 at 6:19:22 PM UTC+5:30, Mahesh Bhat wrote:

Discover: Cannot read property ‘indexOf’ of undefined

TypeError: Cannot read property ‘indexOf’ of undefined

at Notifier.error (http://xxx/index.js?_b=5930:45607:23)

at Notifier.bound (http://xxx/index.js?_b=5930:32081:21)

at http://xxx/index.js?_b=5930:118772:18

at wrappedCallback (http://xxx/index.js?_b=5930:20873:81)

at http://xxx/index.js?_b=5930:20959:26

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

at done (http://xxx/index.js?_b=5930:17641:45)

at completeRequest (http://xxx/index.js?_b=5930:17855:7)

In the Elasticsearch debug logs, I see the following :-

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actionrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted .kibana, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match .kibana

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted ea, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match ea

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Index abc does not have a matching pattern, skip this rule

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: /bypassFilters:

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.transport.SearchGuardNettyTransport] [xxx_client] send indices:admin/validate/query[s] from xxx_client to yyy_data

[2015-06-10 12:28:33,779][ERROR][com.floragunn.searchguard.filter.SearchGuardActionFilter] Error while apply() due to com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all for action indices:data/read/msearch

com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all

at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.validateAndMerge(TokenEvaluator.java:374)

at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.(TokenEvaluator.java:362)

at com.floragunn.searchguard.tokeneval.TokenEvaluator.getEvaluator(TokenEvaluator.java:310)

My allowed_actions list already contains __“indices:data/read/*” __:-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get*”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 2:00:34 PM UTC+5:30, in...@search-guard.com wrote:

“DEFAULT” means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond (http://xxx/index.js?_b=5930:81566:15)

at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7)

at http://xxx/index.js?_b=5930:80203:7

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at wrappedErrback (http://xxx/index.js?_b=5930:20882:78)

at http://xxx/index.js?_b=5930:21015:76

at Scope.$eval (http://xxx/index.js?_b=5930:22002:28)

at Scope.$digest (http://xxx/index.js?_b=5930:21814:31)

at Scope.$apply (http://xxx/index.js?_b=5930:22106:24)

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.
Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard] ’ is forbidden due to DEFAULT]; "}
at http://xxx/index.js?_b=5930:42978:38
at Function.Promise.try (http://xxx/index.js?_b=5930:46205:26 )
at http://xxx/index.js?_b=5930:46183:27
at Array.map (native)
at Function.Promise.map (http://xxx/index.js?_b=5930:46182:30 )
at callResponseHandlers (http://xxx/index.js?_b=5930:42950:22 )
at http://xxx/index.js?_b=5930:43068:16
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at wrappedCallback (http://xxx/index.js?_b=5930:20873:81 )
at http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

“Comment”: “By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.”,

“filters_bypass”: ,

“filters_execute”:

},

{

“Comment”: “For role ‘admin’ all filters are bypassed (so none will be executed). This means unrestricted access.”,

“roles”: [“admin”],

“filters_bypass”: [“*”],

“filters_execute”:

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“spock”],

“indices”: [“abc”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

},

{

“Comment”: “This means that the user spock has readonly access on index abc and ea”,

“users”: [“mahesh”],

“indices”: [“ea”,“.kibana”],

“filters_bypass”: ,

“filters_execute”: [“actionrequestfilter.readonly_kibana”]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.

add “indices:admin/mappings/fields/get*” (or indices:admin/mappingsget") to the allowed actions.

I added “indices:admin/mappings/fields/get*” to the allowed actions. I now see the following error :-

8

we will provide a guide, how to setup and configure search guard with kibana, soon

In your case below it seems that you try to access an index "abc" for which no rule exists

···

Am 11.06.2015 um 11:14 schrieb Mahesh Bhat <maheshbh@gmail.com>:

hi,

I dont know what else I can try here. I am attaching the Elasticsearch and kibana logs. I see an error in the Elasticsearch logs, but, nothing in the kibana logs.

Thanx !
- mahesh.

On Wednesday, June 10, 2015 at 6:19:22 PM UTC+5:30, Mahesh Bhat wrote:
I added "indices:admin/mappings/fields/get*" to the allowed actions. I now see the following error :-

Discover: Cannot read property 'indexOf' of undefined
TypeError: Cannot read property 'indexOf' of undefined
    at Notifier.error (http://xxx/index.js?_b=5930:45607:23\)
    at Notifier.bound (http://xxx/index.js?_b=5930:32081:21\)
    at http://xxx/index.js?_b=5930:118772:18
    at wrappedCallback (http://xxx/index.js?_b=5930:20873:81\)
    at http://xxx/index.js?_b=5930:20959:26
    at Scope.$eval (http://xxx/index.js?_b=5930:22002:28\)
    at Scope.$digest (http://xxx/index.js?_b=5930:21814:31\)
    at Scope.$apply (http://xxx/index.js?_b=5930:22106:24\)
    at done (http://xxx/index.js?_b=5930:17641:45\)
    at completeRequest (http://xxx/index.js?_b=5930:17855:7\)

In the Elasticsearch debug logs, I see the following :-

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actionrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, __Comment__="This means that the user spock has readonly access on index abc and ea"]
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> User mahesh match
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Role wildcard match
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Host wildcard match
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Alias wildcard match
[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted .kibana, requestedTypes [*]
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match .kibana
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted ea, requestedTypes [*]
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match ea
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Index abc does not have a matching pattern, skip this rule
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: /bypassFilters:
[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.transport.SearchGuardNettyTransport] [xxx_client] send indices:admin/validate/query[s] from xxx_client to yyy_data
[2015-06-10 12:28:33,779][ERROR][com.floragunn.searchguard.filter.SearchGuardActionFilter] Error while apply() due to com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all for action indices:data/read/msearch
com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all
        at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.validateAndMerge(TokenEvaluator.java:374)
        at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.<init>(TokenEvaluator.java:362)
        at com.floragunn.searchguard.tokeneval.TokenEvaluator.getEvaluator(TokenEvaluator.java:310)

My allowed_actions list already contains "indices:data/read/*" :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: ["cluster:monitor/nodes/info", "cluster:monitor/health", "indices:admin/mappings/fields/get*", "indices:admin/validate/query", "indices:data/read/*", "indices:admin/create", "indices:admin/exists", "indices:admin/mapping/put", "indices:admin/refresh", "indices:admin/validate/query", "indices:data/write/delete", "indices:data/write/index", "indices:data/write/update", "indices:admin/create"]

Thanx !
- mahesh.

On Wednesday, June 10, 2015 at 2:00:34 PM UTC+5:30, in...@search-guard.com wrote:
add "indices:admin/mappings/fields/get*" (or indices:admin/mappings*get*") to the allowed actions.

"DEFAULT" means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:
I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]
[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx
[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]
[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]
[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa
ss=[*], isDefault()=false, __Comment__="For role admin all filters are bypassed (so none will be executed). This means unrestricted access."]
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> User wildcard match
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Host wildcard match
[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Users or roles or hosts does not match, so we skip this rule
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio
nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, __Comment__="This means that the user spock has readonly access on index abc and ea"]
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Role wildcard match
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Host wildcard match
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Users or roles or hosts does not match, so we skip this rule
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio
nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, __Comment__="This means that the user spock has readonly access on index abc and ea"]
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> User mahesh match
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Role wildcard match
[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Host wildcard match
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] --> Alias wildcard match
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana -> .kibana
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana -> .kibana
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern
[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:
[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action 'indices:admin/mappings/fields/get[index]' is forbidden due to DEFAULT

Which "DEFAULT" rule is the logs referring to ?

Thanx !
- mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:
I replaced all the "indices:/data/read/..." with "indices:data/read/*". The "allowed_actions" part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: ["cluster:monitor/nodes/info", "cluster:monitor/health", "indices:admin/mappings/fields/get", "indices:admin/validate/query", "indices:data/read/*", "indices:admin/create", "indices:admin/exists", "indices:admin/mapping/put", "indices:admin/mappings/fields/get", "indices:admin/refresh", "indices:admin/validate/query", "indices:data/write/delete", "indices:data/write/index", "indices:data/write/update", "indices:admin/create"]

I now see the error :

-----------------------------------

Kibana: Not Found

Error: Not Found
    at respond (http://xxx/index.js?_b=5930:81566:15\)
    at checkRespForFailure (http://xxx/index.js?_b=5930:81534:7\)
    at http://xxx/index.js?_b=5930:80203:7
    at wrappedErrback (http://xxx/index.js?_b=5930:20882:78\)
    at wrappedErrback (http://xxx/index.js?_b=5930:20882:78\)
    at wrappedErrback (http://xxx/index.js?_b=5930:20882:78\)
    at http://xxx/index.js?_b=5930:21015:76
    at Scope.$eval (http://xxx/index.js?_b=5930:22002:28\)
    at Scope.$digest (http://xxx/index.js?_b=5930:21814:31\)
    at Scope.$apply (http://xxx/index.js?_b=5930:22106:24\)

--------------------------

Thanx !
- mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:
searchguard.actionrequestfilter.readonly_kibana.allowed_actions: ["cluster:monitor/nodes/info", "cluster:monitor/health", "indices:admin/mappings/fields/get", "indices:admin/validate/query", "indices:data/read/search", "indices:data/read/msearch", "indices:admin/create", "indices:admin/exists", "indices:admin/mapping/put", "indices:admin/mappings/fields/get", "indices:admin/refresh", "indices:admin/validate/query", "indices:data/read/get", "indices:data/read/mget", "indices:data/read/search", "indices:data/write/delete", "indices:data/write/index", "indices:data/write/update", "indices:admin/create"]

try to replace "indices:data/read/mget" with "indices:data/read/mget*" in the above filter definition.
Maybe you want to shorten this to "indices:data/read/*"

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:
hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user "mahesh" , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {"_index":".kibana","_type":"config","_id":"4.0.1","error":"RuntimeException[java.lang.RuntimeException: Action 'indices:data/read/mget[shard]' is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard]
' is forbidden due to DEFAULT]; "}
    at
http://xxx/index.js?_b=5930:42978:38

    at Function.Promise.try (
http://xxx/index.js?_b=5930:46205:26
)
    at
http://xxx/index.js?_b=5930:46183:27

    at Array.map (native)
    at Function.Promise.map (
http://xxx/index.js?_b=5930:46182:30
)
    at callResponseHandlers (
http://xxx/index.js?_b=5930:42950:22
)
    at
http://xxx/index.js?_b=5930:43068:16

    at wrappedCallback (
http://xxx/index.js?_b=5930:20873:81
)
    at wrappedCallback (
http://xxx/index.js?_b=5930:20873:81
)
    at
http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null
searchguard.http.xforwardedfor.trustedproxies: null
searchguard.http.xforwardedfor.enforce: false

#####################################################
# Settings based authentication (define users and password directly here in the settings. Note: this is per node)
searchguard.authentication.settingsdb.user.spock: passwd
searchguard.authentication.settingsdb.user.root: passwd
searchguard.authentication.settingsdb.user.mahesh: passwd
#####################################################

#####################################################
# Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)
searchguard.authentication.authorization.settingsdb.roles.spock: ["enduser"]
searchguard.authentication.authorization.settingsdb.roles.mahesh: ["enduser"]
searchguard.authentication.authorization.settingsdb.roles.root: ["admin"]
#####################################################

#############################################################################################
#Below here you configure what authenticated and authorized users are allowed to do (or not)#
#This maps to the acl defined in the searchguard configuration index #
#############################################################################################

# Configure the actionrequestfilter to allow or forbid action
searchguard.actionrequestfilter.names: ["readonly","readonly_kibana"]
searchguard.actionrequestfilter.readonly.allowed_actions: ["indices:data/read/*", "*monitor*"]
searchguard.actionrequestfilter.readonly.forbidden_actions: ["cluster:*", "indices:admin*"]
searchguard.actionrequestfilter.readonly_kibana.allowed_actions: ["cluster:monitor/nodes/info", "cluster:monitor/health", "indices:admin/mappings/fields/get", "indices:admin/validate/query", "indices:data/read/search", "indices:data/read/msearch", "indices:admin/create", "indices:admin/exists", "indices:admin/mapping/put", "indices:admin/mappings/fields/get", "indices:admin/refresh", "indices:admin/validate/query", "indices:data/read/get", "indices:data/read/mget", "indices:data/read/search", "indices:data/write/delete", "indices:data/write/index", "indices:data/write/update", "indices:admin/create"]

I picked up that list for "actionrequestfilter.readonly_kibana.allowed_actions" from Using Kibana with Shield | Shield [2.4] | Elastic. The ACL that I used is as follows :-

"acl": [
    {
      "__Comment__": "By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.",
      "filters_bypass": ,
      "filters_execute":
    },
    {
      "__Comment__": "For role 'admin' all filters are bypassed (so none will be executed). This means unrestricted access.",
      "roles": ["admin"],
      "filters_bypass": ["*"],
      "filters_execute":
    },
    {
      "__Comment__": "This means that the user spock has readonly access on index abc and ea",
      "users": ["spock"],
      "indices": ["abc",".kibana"],
      "filters_bypass": ,
      "filters_execute": ["actionrequestfilter.readonly_kibana"]
    },
    {
      "__Comment__": "This means that the user spock has readonly access on index abc and ea",
      "users": ["mahesh"],
      "indices": ["ea",".kibana"],
      "filters_bypass": ,
      "filters_execute": ["actionrequestfilter.readonly_kibana"]
    }
]

Note that, Kibana comes up fine if I use the credentials of user "root". But, I am unable to get through if I login as users "spock" or "mahesh".

Any ideas on what is missing ?

Thanx !
- mahesh.

--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/033aee1c-d9c7-445b-a84e-d3d42428dbfd%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.
<elasticsearch-test1.log><kibana.log>

9

hi !

I played with this a bit more. I found that the error that I see is primarily because of the need to set a DefaultIndex in kibana. This is what I observed :-

I am looking to achieve user access control to kibana using different indexes. i.e. In this particular case, the user “mahesh” is supposed to get access only to data in index “ea”, whereas, the user “spock” is to get access only to data in index “abc”. Now, that kibana notices two indexes, it is required to choose one of them as a DefaultIndex. In this case, the DefaultIndex was set as “abc”. Now, if I use the user credentials of “mahesh” to login, then, it results in an error. But, things work fine if the user “spock” signs in. This is because the DefaultIndex in kibana is set to “abc” and in the SearchGuard ACL rule definition, the user “spock” is allowed to access index “abc” only.

This possibly means that in order to achieve index-based user access control, we might have to run multiple instances of kibana with the corresponding DefaultIndex set to the appropriate index name (set index name for which user has rights to access). So, say, if I have 10 different indexes, then, I would need 10 different instances of kibana running on different ports ! :-S I am not sure if that is feasible solution.

Thanx !

  • mahesh.
···

On Friday, June 12, 2015 at 1:50:20 AM UTC+5:30, SG wrote:

we will provide a guide, how to setup and configure search guard with kibana, soon

In your case below it seems that you try to access an index “abc” for which no rule exists

Am 11.06.2015 um 11:14 schrieb Mahesh Bhat mahe...@gmail.com:

hi,

I dont know what else I can try here. I am attaching the Elasticsearch and kibana logs. I see an error in the Elasticsearch logs, but, nothing in the kibana logs.

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 6:19:22 PM UTC+5:30, Mahesh Bhat wrote:

I added “indices:admin/mappings/fields/get*” to the allowed actions. I now see the following error :-

Discover: Cannot read property ‘indexOf’ of undefined

TypeError: Cannot read property ‘indexOf’ of undefined

at Notifier.error ([http://xxx/index.js?_b=5930:45607:23](http://xxx/index.js?_b=5930:45607:23))

at Notifier.bound ([http://xxx/index.js?_b=5930:32081:21](http://xxx/index.js?_b=5930:32081:21))

at [http://xxx/index.js?_b=5930:118772:18](http://xxx/index.js?_b=5930:118772:18)

at wrappedCallback ([http://xxx/index.js?_b=5930:20873:81](http://xxx/index.js?_b=5930:20873:81))

at [http://xxx/index.js?_b=5930:20959:26](http://xxx/index.js?_b=5930:20959:26)

at Scope.$eval ([http://xxx/index.js?_b=5930:22002:28](http://xxx/index.js?_b=5930:22002:28))

at Scope.$digest ([http://xxx/index.js?_b=5930:21814:31](http://xxx/index.js?_b=5930:21814:31))

at Scope.$apply ([http://xxx/index.js?_b=5930:22106:24](http://xxx/index.js?_b=5930:22106:24))

at done ([http://xxx/index.js?_b=5930:17641:45](http://xxx/index.js?_b=5930:17641:45))

at completeRequest ([http://xxx/index.js?_b=5930:17855:7](http://xxx/index.js?_b=5930:17855:7))

In the Elasticsearch debug logs, I see the following :-

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actionrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted .kibana, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match .kibana

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted ea, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match ea

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Index abc does not have a matching pattern, skip this rule

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: /bypassFilters:

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.transport.SearchGuardNettyTransport] [xxx_client] send indices:admin/validate/query[s] from xxx_client to yyy_data

[2015-06-10 12:28:33,779][ERROR][com.floragunn.searchguard.filter.SearchGuardActionFilter] Error while apply() due to com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all for action indices:data/read/msearch

com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all

    at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.validateAndMerge(TokenEvaluator.java:374)

    at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.<init>(TokenEvaluator.java:362)

    at com.floragunn.searchguard.tokeneval.TokenEvaluator.getEvaluator(TokenEvaluator.java:310)

My allowed_actions list already contains “indices:data/read/*” :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get*”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 2:00:34 PM UTC+5:30, in...@search-guard.com wrote:

add “indices:admin/mappings/fields/get*” (or indices:admin/mappingsget") to the allowed actions.

“DEFAULT” means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond ([http://xxx/index.js?_b=5930:81566:15](http://xxx/index.js?_b=5930:81566:15))

at checkRespForFailure ([http://xxx/index.js?_b=5930:81534:7](http://xxx/index.js?_b=5930:81534:7))

at [http://xxx/index.js?_b=5930:80203:7](http://xxx/index.js?_b=5930:80203:7)

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at [http://xxx/index.js?_b=5930:21015:76](http://xxx/index.js?_b=5930:21015:76)

at Scope.$eval ([http://xxx/index.js?_b=5930:22002:28](http://xxx/index.js?_b=5930:22002:28))

at Scope.$digest ([http://xxx/index.js?_b=5930:21814:31](http://xxx/index.js?_b=5930:21814:31))

at Scope.$apply ([http://xxx/index.js?_b=5930:22106:24](http://xxx/index.js?_b=5930:22106:24))

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.

Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard]

’ is forbidden due to DEFAULT]; "}

at

http://xxx/index.js?_b=5930:42978:38

at Function.Promise.try (

http://xxx/index.js?_b=5930:46205:26

)

at

http://xxx/index.js?_b=5930:46183:27

at Array.map (native)

at Function.Promise.map (

http://xxx/index.js?_b=5930:46182:30

)

at callResponseHandlers (

http://xxx/index.js?_b=5930:42950:22

)

at

http://xxx/index.js?_b=5930:43068:16

at wrappedCallback (

http://xxx/index.js?_b=5930:20873:81

)

at wrappedCallback (

http://xxx/index.js?_b=5930:20873:81

)

at

http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

  "__Comment__": "By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.",

  "filters_bypass": [],

  "filters_execute": []

},

{

  "__Comment__": "For role 'admin' all filters are bypassed (so none will be executed). This means unrestricted access.",

  "roles": ["admin"],

  "filters_bypass": ["*"],

  "filters_execute": []

},

{

  "__Comment__": "This means that the user spock has readonly access on index abc and ea",

  "users": ["spock"],

  "indices": ["abc",".kibana"],

  "filters_bypass": [],

  "filters_execute": ["actionrequestfilter.readonly_kibana"]

},

{

  "__Comment__": "This means that the user spock has readonly access on index abc and ea",

  "users": ["mahesh"],

  "indices": ["ea",".kibana"],

  "filters_bypass": [],

  "filters_execute": ["actionrequestfilter.readonly_kibana"]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.

–
You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/033aee1c-d9c7-445b-a84e-d3d42428dbfd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<elasticsearch-test1.log><kibana.log>

10

hi,

Did anyone else experience this ? Is there a better solution ?

Thanx !

  • mahesh.
···

On Friday, July 10, 2015 at 2:37:31 PM UTC+5:30, Mahesh Bhat wrote:

hi !

I played with this a bit more. I found that the error that I see is primarily because of the need to set a DefaultIndex in kibana. This is what I observed :-

I am looking to achieve user access control to kibana using different indexes. i.e. In this particular case, the user “mahesh” is supposed to get access only to data in index “ea”, whereas, the user “spock” is to get access only to data in index “abc”. Now, that kibana notices two indexes, it is required to choose one of them as a DefaultIndex. In this case, the DefaultIndex was set as “abc”. Now, if I use the user credentials of “mahesh” to login, then, it results in an error. But, things work fine if the user “spock” signs in. This is because the DefaultIndex in kibana is set to “abc” and in the SearchGuard ACL rule definition, the user “spock” is allowed to access index “abc” only.

This possibly means that in order to achieve index-based user access control, we might have to run multiple instances of kibana with the corresponding DefaultIndex set to the appropriate index name (set index name for which user has rights to access). So, say, if I have 10 different indexes, then, I would need 10 different instances of kibana running on different ports ! :-S I am not sure if that is feasible solution.

Thanx !

  • mahesh.

On Friday, June 12, 2015 at 1:50:20 AM UTC+5:30, SG wrote:

we will provide a guide, how to setup and configure search guard with kibana, soon

In your case below it seems that you try to access an index “abc” for which no rule exists

Am 11.06.2015 um 11:14 schrieb Mahesh Bhat mahe...@gmail.com:

hi,

I dont know what else I can try here. I am attaching the Elasticsearch and kibana logs. I see an error in the Elasticsearch logs, but, nothing in the kibana logs.

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 6:19:22 PM UTC+5:30, Mahesh Bhat wrote:

I added “indices:admin/mappings/fields/get*” to the allowed actions. I now see the following error :-

Discover: Cannot read property ‘indexOf’ of undefined

TypeError: Cannot read property ‘indexOf’ of undefined

at Notifier.error ([http://xxx/index.js?_b=5930:45607:23](http://xxx/index.js?_b=5930:45607:23))

at Notifier.bound ([http://xxx/index.js?_b=5930:32081:21](http://xxx/index.js?_b=5930:32081:21))

at [http://xxx/index.js?_b=5930:118772:18](http://xxx/index.js?_b=5930:118772:18)

at wrappedCallback ([http://xxx/index.js?_b=5930:20873:81](http://xxx/index.js?_b=5930:20873:81))

at [http://xxx/index.js?_b=5930:20959:26](http://xxx/index.js?_b=5930:20959:26)

at Scope.$eval ([http://xxx/index.js?_b=5930:22002:28](http://xxx/index.js?_b=5930:22002:28))

at Scope.$digest ([http://xxx/index.js?_b=5930:21814:31](http://xxx/index.js?_b=5930:21814:31))

at Scope.$apply ([http://xxx/index.js?_b=5930:22106:24](http://xxx/index.js?_b=5930:22106:24))

at done ([http://xxx/index.js?_b=5930:17641:45](http://xxx/index.js?_b=5930:17641:45))

at completeRequest ([http://xxx/index.js?_b=5930:17855:7](http://xxx/index.js?_b=5930:17855:7))

In the Elasticsearch debug logs, I see the following :-

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actionrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 12:28:33,777][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted .kibana, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match .kibana

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request abc, granted ea, requestedTypes [*]

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index abc not match ea

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Index abc does not have a matching pattern, skip this rule

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: /bypassFilters:

[2015-06-10 12:28:33,778][DEBUG][com.floragunn.searchguard.transport.SearchGuardNettyTransport] [xxx_client] send indices:admin/validate/query[s] from xxx_client to yyy_data

[2015-06-10 12:28:33,779][ERROR][com.floragunn.searchguard.filter.SearchGuardActionFilter] Error while apply() due to com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all for action indices:data/read/msearch

com.floragunn.searchguard.tokeneval.MalformedConfigurationException: no bypass or execute filters at all

    at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.validateAndMerge(TokenEvaluator.java:374)

    at com.floragunn.searchguard.tokeneval.TokenEvaluator$Evaluator.<init>(TokenEvaluator.java:362)

    at com.floragunn.searchguard.tokeneval.TokenEvaluator.getEvaluator(TokenEvaluator.java:310)

My allowed_actions list already contains “indices:data/read/*” :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get*”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 2:00:34 PM UTC+5:30, in...@search-guard.com wrote:

add “indices:admin/mappings/fields/get*” (or indices:admin/mappingsget") to the allowed actions.

“DEFAULT” means that there is no allow nor a forbid rule for this action so its forbidden by DEFAULT

Am Mittwoch, 10. Juni 2015 09:16:44 UTC+2 schrieb Mahesh Bhat:

I was looking at the debug logs. This is what I see :-

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] user User [name=mahesh, roles=[enduser]]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedHostAddress: 10.xx.xx.xx OR xxx

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedAliases: [*]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedIndices: [.kibana]

[2015-06-10 07:10:58,111][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] requestedTypes: [*]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Checking 3 rules

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filtersExecute

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Default set to filterBypass

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 1.: ACRule [hosts=null, users=null, roles=[admin], indices=null, aliases=null, filters_execute=, filters_bypa

ss=[*], isDefault()=false, Comment=“For role admin all filters are bypassed (so none will be executed). This means unrestricted access.”]

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User does not have role admin

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] No role does not match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,112][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 2.: ACRule [hosts=null, users=[spock], roles=null, indices=[abc, .kibana], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] User mahesh does not match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Users or roles or hosts does not match, so we skip this rule

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Check rule 3.: ACRule [hosts=null, users=[mahesh], roles=null, indices=[.kibana, ea], aliases=null, filters_execute=[actio

nrequestfilter.readonly_kibana], filters_bypass=, isDefault()=false, Comment=“This means that the user spock has readonly access on index abc and ea”]

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → User mahesh match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Role wildcard match

[2015-06-10 07:10:58,113][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Host wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Identity would match, see if aliases and indices are also ok?

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] → Alias wildcard match

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] typeAndMatch(): request .kibana, granted .kibana, requestedTypes [*]

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard indices/aliases: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Wildcard without types: .kibana → .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] -->Index .kibana match .kibana

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Index .kibana has a matching pattern

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] ----> APPLY RULE <---- which means the following executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,114][DEBUG][com.floragunn.searchguard.tokeneval.TokenEvaluator] Final executeFilters: [actionrequestfilter.readonly_kibana]/bypassFilters:

[2015-06-10 07:10:58,117][WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] actionrequestfilter.readonly_kibana Action ‘indices:admin/mappings/fields/get[index]’ is forbidden due to DEFAULT

Which “DEFAULT” rule is the logs referring to ?

Thanx !

  • mahesh.

On Wednesday, June 10, 2015 at 10:18:32 AM UTC+5:30, Mahesh Bhat wrote:

I replaced all the “indices:/data/read/…” with “indices:data/read/*”. The “allowed_actions” part now looks like :-

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/*”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I now see the error :

Kibana: Not Found

Error: Not Found

at respond ([http://xxx/index.js?_b=5930:81566:15](http://xxx/index.js?_b=5930:81566:15))

at checkRespForFailure ([http://xxx/index.js?_b=5930:81534:7](http://xxx/index.js?_b=5930:81534:7))

at [http://xxx/index.js?_b=5930:80203:7](http://xxx/index.js?_b=5930:80203:7)

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at wrappedErrback ([http://xxx/index.js?_b=5930:20882:78](http://xxx/index.js?_b=5930:20882:78))

at [http://xxx/index.js?_b=5930:21015:76](http://xxx/index.js?_b=5930:21015:76)

at Scope.$eval ([http://xxx/index.js?_b=5930:22002:28](http://xxx/index.js?_b=5930:22002:28))

at Scope.$digest ([http://xxx/index.js?_b=5930:21814:31](http://xxx/index.js?_b=5930:21814:31))

at Scope.$apply ([http://xxx/index.js?_b=5930:22106:24](http://xxx/index.js?_b=5930:22106:24))

Thanx !

  • mahesh.

On Tuesday, June 9, 2015 at 7:49:53 PM UTC+5:30, in...@search-guard.com wrote:

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

try to replace “indices:data/read/mget” with “indices:data/read/mget*” in the above filter definition.

Maybe you want to shorten this to “indices:data/read/*”

Am Dienstag, 9. Juni 2015 15:37:56 UTC+2 schrieb Mahesh Bhat:

hi,

Thanx ! for the good work on this plugin. I have been playing with this a bit and have run into issues for kibana access.

I have kibana - 4.0.1 and Elasticsearch - 1.5.2 running in my test ELK environment. I am currently using Nginx to authenticate users. Nginx reverse proxies requests to kibana. When I try accessing kibana with the user “mahesh” , I see the following error at the browser :-

Courier Fetch Error: unhandled error Error: Request to Elasticsearch failed: {“_index”:“.kibana”,“_type”:“config”,“_id”:“4.0.1”,“error”:"RuntimeException[java.lang.RuntimeException: Action ‘indices:data/read/mget[shard]’ is forbidden due to DEFAULT]; nested: RuntimeException[Action 'indices:data/read/mget[shard]

’ is forbidden due to DEFAULT]; "}

at

http://xxx/index.js?_b=5930:42978:38

at Function.Promise.try (

http://xxx/index.js?_b=5930:46205:26

)

at

http://xxx/index.js?_b=5930:46183:27

at Array.map (native)

at Function.Promise.map (

http://xxx/index.js?_b=5930:46182:30

)

at callResponseHandlers (

http://xxx/index.js?_b=5930:42950:22

)

at

http://xxx/index.js?_b=5930:43068:16

at wrappedCallback (

http://xxx/index.js?_b=5930:20873:81

)

at wrappedCallback (

http://xxx/index.js?_b=5930:20873:81

)

at

http://xxx/index.js?_b=5930:20959:26

Here is my SearchGuard Configuration :-

searchguard.key_path: /opt/elasticsearch/

searchguard.http.xforwardedfor.header: null

searchguard.http.xforwardedfor.trustedproxies: null

searchguard.http.xforwardedfor.enforce: false

#####################################################

Settings based authentication (define users and password directly here in the settings. Note: this is per node)

searchguard.authentication.settingsdb.user.spock: passwd

searchguard.authentication.settingsdb.user.root: passwd

searchguard.authentication.settingsdb.user.mahesh: passwd

#####################################################

#####################################################

Settings based authorization (define users and their roles directly here in the settings. Note: this is per node)

searchguard.authentication.authorization.settingsdb.roles.spock: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.mahesh: [“enduser”]

searchguard.authentication.authorization.settingsdb.roles.root: [“admin”]

#####################################################

#############################################################################################

#Below here you configure what authenticated and authorized users are allowed to do (or not)#

#This maps to the acl defined in the searchguard configuration index #

#############################################################################################

Configure the actionrequestfilter to allow or forbid action

searchguard.actionrequestfilter.names: [“readonly”,“readonly_kibana”]

searchguard.actionrequestfilter.readonly.allowed_actions: [“indices:data/read/*”, “monitor”]

searchguard.actionrequestfilter.readonly.forbidden_actions: [“cluster:", "indices:admin”]

searchguard.actionrequestfilter.readonly_kibana.allowed_actions: [“cluster:monitor/nodes/info”, “cluster:monitor/health”, “indices:admin/mappings/fields/get”, “indices:admin/validate/query”, “indices:data/read/search”, “indices:data/read/msearch”, “indices:admin/create”, “indices:admin/exists”, “indices:admin/mapping/put”, “indices:admin/mappings/fields/get”, “indices:admin/refresh”, “indices:admin/validate/query”, “indices:data/read/get”, “indices:data/read/mget”, “indices:data/read/search”, “indices:data/write/delete”, “indices:data/write/index”, “indices:data/write/update”, “indices:admin/create”]

I picked up that list for “actionrequestfilter.readonly_kibana.allowed_actions” from https://www.elastic.co/guide/en/shield/current/_shield_with_kibana_4.html. The ACL that I used is as follows :-

“acl”: [

{

  "__Comment__": "By default no filters are executed and no filters a by-passed. In such a case a exception is throws an access will be denied.",

  "filters_bypass": [],

  "filters_execute": []

},

{

  "__Comment__": "For role 'admin' all filters are bypassed (so none will be executed). This means unrestricted access.",

  "roles": ["admin"],

  "filters_bypass": ["*"],

  "filters_execute": []

},

{

  "__Comment__": "This means that the user spock has readonly access on index abc and ea",

  "users": ["spock"],

  "indices": ["abc",".kibana"],

  "filters_bypass": [],

  "filters_execute": ["actionrequestfilter.readonly_kibana"]

},

{

  "__Comment__": "This means that the user spock has readonly access on index abc and ea",

  "users": ["mahesh"],

  "indices": ["ea",".kibana"],

  "filters_bypass": [],

  "filters_execute": ["actionrequestfilter.readonly_kibana"]

}

]

Note that, Kibana comes up fine if I use the credentials of user “root”. But, I am unable to get through if I login as users “spock” or “mahesh”.

Any ideas on what is missing ?

Thanx !

  • mahesh.

–
You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/033aee1c-d9c7-445b-a84e-d3d42428dbfd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<elasticsearch-test1.log><kibana.log>