USR:admin(?) , what does it mean

(Daniel Mota Leite) #1


i’m getting a error using elasticsearc HQ plugin (inside a docker now), when trying to list the indexes it gives "500 internal server error"
Looking to the HQ logs, it reports auth denied by the Elasticsearch and looking to the ES logs i get this:

May 02 19:08:11 elk-a01 sh[22623]: [15928116.215392] elasticsearch[7]: [2018-05-02T19:08:11,942][INFO ][t.b.r.a.ACL ] FORBIDDEN by { name: ‘Deny rlogstash-* indices’, policy: FORBID} req={ ID:1873156814-1495312531#109413, TYP:IndicesStatsRequest, CGR:N/A, USR:admin(?), BRS:false, ACT:indices:monitor/stats, OA:, IDX:rlogstash-2018.04.21-passwords,rlogstash-2018.05.02-passwords,rlogstash-2018.04.13-passwords,rlogstash-2018.04.26-passwords,rlogstash-2018.04.18-passwords,rlogstash-2018.04.24-passwords, MET:GET, PTH:/_stats, CNT:<N/A>, HDR:Accept-Encoding,authorization,connection,content-length,content-type,Host, HIS:[Accept admin user rlogstash->[auth_key->false]], [Accept localhost requests for rlogstash-->[hosts->false]], [Accept Beats user->[auth_key->false]], [Accept kibana user->[auth_key->false]], [Accept admin user->[auth_key->false]], [Accept grafana user->[auth_key->false]], [Accept icinga user->[auth_key->false]], [Accept Logstash user->[auth_key->false]], [Deny rlogstash- indices->[indices->true]], [Accept cluster monitor->[actions->false]] }

I have this config (removed unused parts):

- name: "Accept admin user"
  type: allow
  auth_key: (removed)

- name: "Deny rlogstash-* indices"
  type: forbid
  indices: [rlogstash-*]

Those rlogstash indexes are logs with the word password, mostly as a safeguard to some dev outputing any password (user or service) as plain text in the logs and they are now mostly empty

Anyway, the HQ config is using the admin password, so it should be able to access those indexes, yet it is being rejected… the only difference i see from a valid request is the “USR:admin(?)”, where that “(?)” is missing in the accepted requests

So, what does that extra “(?)” field mean? Depending of that, this could be a bug in the HQ or in the readlonlyrest plugin.

Thanks in advance for the help

(Simone Scarduzio) #2

The question mark beside the USR means no authentication rule has yet successfully validated the credentials at the moment of logging, but the “user” part of the credentials in the request shows “admin”

(Daniel Mota Leite) #3

But the user admin is “verified” or is just “trying to use” ?
if it is a “verified” admin, it should have match the previous rule … but if it is just “trying to use” admin, that might mean that the auth is probably wrong (ie: HQ is messing up the password or not sending it)

(Simone Scarduzio) #4

You don’t need to guess, there is the HIS field in the logs to see what happened in the ACL evaluation

(Daniel Mota Leite) #5

Yep, you are right, didn’t really think about it! need more sleep! :smiley:

Thank you for the help!!

(Daniel Mota Leite) #6

by the way, this is really a HQ bug, it is encoding a “=” in the password as %3D, so the password do not match.

Open bug here: