FORBIDDEN ACT:cluster:monitor/nodes/stats

Looks like this is the last one we are getting. Should I create a duplicate entry like this:

- name: "supertest"
  type: allow
  actions: ["indices:data/read/field_caps"]
  verbosity: error

FORBIDDEN by default req={ ID:961308083-352279695#10330, TYP:NodesStatsRequest, CGR:N/A, USR:[no basic auth header], BRS:true, ACT:cluster:monitor/nodes/stats, OA:127.0.0.1, IDX:<N/A>, MET:GET, PTH:/_nodes/_local/stats, CNT:<N/A>, HDR:Accept-Encoding,content-length,Host,User-Agent, HIS:[supertest->[actions->false]], [::Kibana-access-admin::->[groups->false]], [::KIBANA-SRV::->[auth_key_sha256->false]] }

I will give you tomorrow that I had to do for xpack too

Hi,

I gave you the full way in your previous post , FORBIDDEN ACT:indices:data/read/field_caps - #14 by ld57

It works nice on my side.

Here is what I added but still get the error

- name: "supertest2"
  type: allow
  actions: ["cluster:monitor/nodes/stats"]
  verbosity: error

Add hosts array with 127.0.0.1 , like in my example

how can you still get FORBIDDEN in ES logs with this rule in place? Please paste the log line which contains all the history of the request walking through the ACL.

Do you mean the output of the elasticsearch log?

[2018-03-13T16:44:49,621][INFO ][o.e.c.m.MetaDataMappingService] [es-01] [packetbeat-6.2.2-2018.03.13/n822sDCNTJebp7lsXdxr1A] update_mapping [doc]
[2018-03-13T16:44:58,435][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:1353496421-1325847419#3376506, TYP:NodesInfoRequest, CGR:N/A, USR:[no basic auth header], BRS:true, ACT:cluster:monitor/nodes/info, OA:127.0.0.1, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:Accept-Encoding,content-length,Host,User-Agent, HIS:[::KIBANA-SRV::->[auth_key_sha256->false]], [supertest->[actions->false]], [::Kibana-access-admin::->[groups->false]], [supertest2->[actions->false]] }
[2018-03-13T16:45:01,387][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:753743735-1151105080#3376868, TYP:MainRequest, CGR:N/A, USR:[no basic auth header], BRS:true, ACT:cluster:monitor/main, OA:127.0.0.1, IDX:<N/A>, MET:GET, PTH:/, CNT:<N/A>, HDR:Accept,Accept-Encoding,content-length,Host,User-Agent, HIS:[::Kibana-access-admin::->[groups->false]], [supertest2->[actions->false]], [::KIBANA-SRV::->[auth_key_sha256->false]], [supertest->[actions->false]] }
[2018-03-13T16:45:04,131][INFO ][o.e.c.m.MetaDataMappingService] [es-01] [packetbeat-6.2.2-2018.03.13/n822sDCNTJebp7lsXdxr1A] update_mapping [doc]
[2018-03-13T16:45:08,442][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:97841898-1947063659#3377539, TYP:NodesInfoRequest, CGR:N/A, USR:[no basic auth header], BRS:true, ACT:cluster:monitor/nodes/info, OA:127.0.0.1, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:Accept-Encoding,content-length,Host,User-Agent, HIS:[supertest2->[actions->false]], [::KIBANA-SRV::->[auth_key_sha256->false]], [::Kibana-access-admin::->[groups->false]], [supertest->[actions->false]] }
[2018-03-13T16:45:18,434][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:130278457-1653318712#3378189, TYP:NodesInfoRequest, CGR:N/A, USR:[no basic auth header], BRS:true, ACT:cluster:monitor/nodes/info, OA:127.0.0.1, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:Accept-Encoding,content-length,Host,User-Agent, HIS:[supertest->[actions->false]], [supertest2->[actions->false]], [::KIBANA-SRV::->[auth_key_sha256->false]], [::Kibana-access-admin::->[groups->false]] }
[2018-03-13T16:45:18,570][INFO ][o.e.c.m.MetaDataMappingService] [es-01] [packetbeat-6.2.2-2018.03.13/n822sDCNTJebp7lsXdxr1A] update_mapping [doc]
[2018-03-13T16:45:21,276][INFO ][o.e.c.m.MetaDataMappingService] [es-01] [packetbeat-6.2.2-2018.03.13/n822sDCNTJebp7lsXdxr1A] update_mapping [doc]

So these are another action, it’s normal that they gets forbidden, your rule only lets through “cluster:monitor/nodes/stats”

Sorry to be boring, but - for the future readers - I’d like remark that all these request are faulty because they don’t come with credentials due to a long standing Kibana bug and you are taking full responsibility to let them through. This bug is entirely bypassed via ROR PRO/Enterprise Kibana plugins.

Good to know exactly what is happening. ES has no intentions to resolve it probably.