Don't understand this FORBIDDEN

With these rules

      access_control_rules:
        - name: svc-consul
          auth_key: elastic:elastic

        - name: svc-kibana
          auth_key: kibana:kibana

        - name: user-admin
          auth_key: admin:admin
          kibana_access: admin
          kibana_index: ".kibana"
          actions: ['*']
          indices: ['*']

I get this rejection, which I don’t understand why. Is it because there is no IDX?

[2018-12-23T04:48:52,434][INFO ][tech.beshu.ror.acl.ACL   ] [s-ror-es-1] FORBIDDEN by default req={ ID:1311038792-2104111661#220, TYP:GetIndexTemplatesRequest, CGR:N/A, USR:admin(?), BRS:false, KDX:null, ACT:indices:admin/template/get, OA:10.11.136.187, DA:0.0.0.0, IDX:<N/A>, MET:GET, PTH:/_template?pretty, CNT:<N/A>, HDR:{authorization=<OMITTED>, content-length=0, x-forwarded-host=s-ror-es-1.use1.systeminsights.com:5602, x-forwarded-proto=http, Connection=close, x-forwarded-port=51598, Host=10.11.136.187:9200, x-forwarded-for=10.0.192.247}, HIS:[svc-consul->[auth_key->false]], [svc-kibana->[auth_key->false]], [user-admin->[kibana_access->false, auth_key->true]], [user-plant--kibana-rw->[proxy_auth->false]], [user-plant--kibana-ro->[proxy_auth->false]], [user-plant--data->[proxy_auth->false]] }

As you can see, the authentication for user “admin” is correct (auth_key rule is matched), but kibana_access is not matching.

The kibana_access: admin macro rule does not allow the action “indices:admin/template/get” because in previous versions of Kibana this action was not part of a Kibana session.
I already discovered the need for allowing this extra action and fixed this issue two days ago. Will be in the next release.

In this case if I removed the kibana_acess and just left actions:* would that work around it?

Actions and kibana_access should never be seen in the same block. See how the kibana access macro works.

The most clever thing for now is to leave the double block, as blocks combine in “OR” logic, rather than “AND” like rules inside a block.