Wazuh Kibana App - Wazuh Configuration for .wazuh index FORBIDEN

1

We use Wazuh and when you try to update its settings in the Kibana, an error occurs.

[2018-01-29T15:40:26,659][INFO ][t.b.r.a.ACL ] FORBIDDEN by default req={ ID:1399485572-1397392720#9351, TYP:IndexRequest, CGR:N/A, USR:kuser, BRS:false, ACT:indices:data/write/index, OA:192.168.105.17, IDX:.wazuh, MET:POST, PTH:/.wazuh/wazuh-configuration/1517229627338/_create?refresh=true, CNT:<OMITTED, LENGTH=312>, HDR:authorization,Connection,Content-Length,content-type,Host, HIS:[LDAP admin users->[ldap_authorization->true, kibana_access->false]], [logstash->[hosts->false]], [::ADMIN::->[auth_key_sha256->false]], [::KIBANA-SRV::->[auth_key_sha256->false]], [LDAP common users->[ldap_authorization->false]] }

My user permission:

- name: "LDAP admin users"
  kibana_access: admin
  ldap_auth:
     name: "ipa_users"
    groups: ["kibana_admins"]
2

Hello @OlegK ,

Seems like the kibana_access: admin is not matching when operating on unknown indices (like the wazuh settings index), which is intentional. And since all the rules in a block are evaluated in logical AND, the whole block won’t match.

So, ROR is behaving as per design, but you can allow write operations to that index by adding another rules block with the same authentication policy, without the kibana_access, that allows access to that index.

So together with this block that you already have, add another one right under:

    - name: "LDAP admin users"
      kibana_access: admin
      actions: ["*"]
      ldap_auth:
         name: "ipa_users"
         groups: ["kibana_admins"]


    - name: "LDAP admin users extra Wazuh operations"
      indices: [".wazuh"]
      # actions: ["*"] # optionally limit this to read and write actions, and any other ops like delete (I don't know the specific requirement of the wazuh plugin)
      ldap_auth:
         name: "ipa_users"
         groups: ["kibana_admins"]

One more comment is that you could just remove all the action rule with star ( actions: ["*"]) as it’s always going to evaluate true and the rules in a block - as said before - are all evaluated in logical AND.