Unable to 'create index pattern' with RoR 5.6.1


(Kamen MacKay) #1

Hi:

I have ES 5.6.1 (down-graded from 5.6.3 so RoR would work). I’ve been able to configure it with the examples
from the github site and it’s working great. However, I have ran into perhaps a bug. When I log in with my admin user (in yaml file below) and try to create a new index pattern, I get the below error when trying to read the field data for the timestamp:

[2017-10-27T19:29:22,542][INFO ][o.e.p.r.a.ACL ] FORBIDDEN by default req={ ID:1459479432-478702143#424, TYP:FieldCapabilitiesRequest, CGR:N/A, USR:[no basic auth header], BRS:false, ACT:indices:data/read/field_caps, OA:10.0.0.158, IDX:logstash-, MET:POST, PTH:/logstash-/_field_caps?fields=*&ignore_unavailable=true&allow_no_indices=false, CNT:<N/A>, HDR:Connection,Content-Length,Host, HIS:[::KIBANA-SRV::->[auth_key->false]], [::LOGSTASH::->[auth_key->false]], [::RO log access::->[groups->false]], [::RW log access::->[groups->false]] }

The result is that the dropdown box to select the timestamp field is blank. This means that I can’t load new indexes into Kibana. I did notice that “indices:data/read/field_caps” is not listed as an action rule. Is this a bug or (hopefully) a misconfiguration error on my part?

Settings follow:

readonlyrest:

access_control_rules:

- name: "::LOGSTASH::"
  # auth_key is good for testing, but replace it with `auth_key_sha1`!
  auth_key: logstash:logstash
  actions: [ "cluster:monitor/main","indices:admin/types/exists","indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create" ]
  indices: [ "*" ]

# We trust Kibana's server side process, full access granted via HTTP authentication
- name: "::KIBANA-SRV::"
  # auth_key is good for testing, but replace it with `auth_key_sha256`!
  auth_key: kibana:kibana
  type: allow
  verbosity: error # don't log successful request

- name: "::RO log access::"
  kibana_access: rw
  groups: [ "ro-users" ]
  indices: [ ".kibana", "*" ]

- name: "::RW log access::"
  kibana_access: rw
  type: allow
  groups: [ "rw-users" ]
  indices: [ ".kibana", "*", "logstash-*" ]

users:

- username: logs
  auth_key: logs:logs
  groups: [ "ro-users" ]

- username: admin
  auth_key: admin:s3cr3t
  groups: [ "rw-users" ]

Hosts_local question
(Simone Scarduzio) #2

Hello @kamenmackay, it appears this is a feature labeled as “experimental” which Kibana started using. I will add it to the read only actions set. Well spotted.


(Kamen MacKay) #3

Wow…thanks for the quick response. Can you suggest a workaround until you’re able to add it to the read-only actions? The only thing I can think of (ugh) is uninstalling RoR (yaml and plugin), load the new index and then re-installing ROR.


(Simone Scarduzio) #4

Wait @kamenmackay, I was wrong. That’s not the cause.
Your log line shows we have no credentials attached to the request, that’s why it’s forbidding it.

USR:[no basic auth header] 

(Kamen MacKay) #5

Hmm…I have to log in twice with the admin credentials so I thought that would’ve worked. The error message indicates then that I’m missing a rule that would allow the admin user to perform this action. I tried modifying the admin user actions in the yaml file to specifically allow that action but it still didn’t perform as expected.


(Simone Scarduzio) #6

Are you using ROR plugin for Kibana by any chance? Because if you are not, there’s a Kibana bug such that some requests go off without basic authentication.

A workaround could be globally allowing that action in another rules block. As it is a read only op.


(Kamen MacKay) #7

No, I’m not using the Kibana plugin (yet). I will be recommending to my boss that we purchase the Pro subscription, though.
I added a rule block which didn’t help:

  • name: "::addindice::"
    kibana_access: rw
    type: allow
    actions: [ “indices:data/read/field_caps” ]
    groups: [ “rw-users” ]
    indices: [ “.kibana”, “*” ]

Can you suggest a rule block that would work?

Thanks!


(Simone Scarduzio) #8

Yeah that won’t work because all the rules in the block are evaluated in “logic AND”. You need to add another block of rules above it with just the actions rule.

- name: "workaround"
  actions:  [ "indices:data/read/field_caps" ]


(Kamen MacKay) #9

Sorry for the delayed response…I tried the above solution by making it the first rule and received the same error. I tried adding the ‘workaround’ rule to a group and granting it access to all indices but I still get the following errors:

[2017-11-02T18:11:34,760][INFO ][o.e.p.r.a.ACL ] FORBIDDEN by default req={ ID:1426872206-1444518798#184680, TYP:FieldCapabilitiesIndexRequest, CGR:N/A, USR:[no basic auth header], BRS:false, ACT:indices:data/read/field_caps[index], OA:10.0.0.158, IDX:qs2-, MET:POST, PTH:/qs2-/_field_caps?fields=*&ignore_unavailable=true&allow_no_indices=false, CNT:<N/A>, HDR:Connection,Content-Length,Host, HIS:[::KIBANA-SRV::->[auth_key->false]], [workaround->[actions->false]], [::RO log access::->[groups->false]], [::LOGSTASH::->[auth_key->false]], [::RW log access::->[groups->false]] }

[2017-11-02T18:11:34,760][INFO ][o.e.p.r.a.ACL ] FORBIDDEN by default req={ ID:1426872206-1608655956#184681, TYP:FieldCapabilitiesIndexRequest, CGR:N/A, USR:[no basic auth header], BRS:false, ACT:indices:data/read/field_caps[index], OA:10.0.0.158, IDX:qs2-, MET:POST, PTH:/qs2-/_field_caps?fields=*&ignore_unavailable=true&allow_no_indices=false, CNT:<N/A>, HDR:Connection,Content-Length,Host, HIS:[::KIBANA-SRV::->[auth_key->false]], [::RO log access::->[groups->false]], [workaround->[actions->false]], [::RW log access::->[groups->false]], [::LOGSTASH::->[auth_key->false]] }

I also tried the following rule block:

  • name: "workaround"
    groups: [ “rw-users” ]
    actions: [ “indices:data/read/field_caps” ]
    type: allow
    indices: [ “*” ]

I got the same error messages as above…I mentioned earlier that my test ES cluster was downgraded to 5.6.1 from 5.6.3 in order to test out this plugin. Is there a possibility that this is the culprit?


(Simone Scarduzio) #10

As you can see, the action being blocked is a variant of indices:data/read/field_caps. Just add a star to the rule I gave you. Should do the trick.


(Kamen MacKay) #11

This solution worked! Thanks so much!


(Sai) #12

Hi @sscarduzio I tried your workaround and added more actions (indices:data/read/search) since I am not able to access X-Pack monitoring data under Monitoring tab in Kibana. But this workaround is causing big trouble allowing all users to access elastic search _search api without any authentication since workaround is matching for all queries. Can you please suggest how to fix? Thanks.

Here are my ACL rules:

  • name: “::KIBANA RW DEVELOPER::”
    auth_key: xx:xx
    kibana_access: rw
    kibana_index: “.kibana”
    indices: [“log_index-",".monitoring-”,".kibana"]
  • name: “::ES READONLY::”
    auth_key: xx:xx
    actions: [“indices:data/read/","indices:monitor/”,“cluster:monitor/health”,“cluster:monitor/main”,“cluster:monitor/state”,“cluster:monitor/stats”]
    indices: [“log_index-dev-jenkinstestcases-*”]>
  • name: “workaround”
    actions: [ “indices:data/read/field_caps*”, “indices:data/read/msearch”, “indices:data/read/search” ]

My elastic search _search query:

http://xxx:9200/log_index-/_search?pretty=true&q=:*&size=1000

Thanks


(Simone Scarduzio) #13

Hi @sairamvla, despite making monitoring work will always be a workaround (as its requests provide no credentials) @ld57 made an extensive research on the topic not long ago, so he could share his results!


(Sai) #14

Thanks @sscarduzio.

Hi @ld57, please suggest if there is any work around for my case.


(Ld57) #15

Hi,

that I recommend to you, as structure :

  - name : "::KIBANA RW DEVELOPER::"
    auth_key: xx:xx
    kibana_access: rw
    kibana_index: ".kibana"
    indices : ["log_index-*", ".monitoring-*", ".kibana"]

  - name:  "::ES read only::"
    auth_key: xx:xx
    actions: ["cluster:monitor/*", "indices:data/read/*"]
    indices: ["log_index-dev-jenkinstestcases-*"]

  - name: "dummy field_caps because I use basic auth"
    actions: ["indices:data/read/field_caps"]
    hosts: ["IP_of_your_kibana_server"]

But it was a long time, and I switched to Enterprise version ( on my side).
Pro and entreprise resolves some behavior of kibana.

if you need a full config of RoR with xpack support etc, just tell, or else wait until I will post configs later in user’s guide, but tested with Pro and entreprise .

you can try to add this block, for monitoring :

  - name: "just that action from localhost where kibana is"
   type: allow
   actions: ["cluster:monitor/*", "cluster:admin/xpack/monitoring/*", "cluster:admin/xpack/license/*", "indices:data/read/*","indices:data/write/*", "indices:admin/create" ]
   hosts: ["IP_of_your_kibana_server"]
   indices: [".monitoring-*"]