Match wrong index in forbid block

ES + KBN Version: 7.2.0
ROR VERSION: Enterprise 1.18.9_7.2.0
I have an issue with an forbid block that matches a wrong index meaning:

I have block

- name: "Forbidden for something index"
  groups: ["client_admin", "test"]
  type: "forbid"
  indices: ["testx"]
  methods: ["PUT", "POST", "DELETE"]

If I’m trying to create an ILM Policy from kibana ( http://localhost:5601/app/kibana#/management/elasticsearch/index_lifecycle_management/policies/edit)
and click save I receive

Error saving lifecycle policy asdsa

403: Not allowed for user. [undefined] forbidden, with { due_to={ 0="FORBIDDEN_BY_BLOCK" } }

After that I’ve tried to look into elasticsearch logs and I saw:

   "name":"Forbidden for .readonlyrest index",
   ]   "req="{
      LENGTH=122.0 B>,
         "Full Admin Users-> RULES":         [
         "RESOLVED":         [
         "Forbidden for .readonlyrest index-> RULES":         [
         "RESOLVED":         [

So from this elasticsearch log I understand that forbid block is matched because of my group method ( which is normal ) but index from block is not testx.

My entire ror config is:

  prompt_for_basic_auth: false
    - name: "Full Admin Users"
      groups: ["full-admin"]
    - name: "Forbidden for something index"
      groups: ["client_admin", "test"]
      type: "forbid"
      indices: ["testx"]
      methods: ["PUT", "POST", "DELETE"]
    - name: "Client Admin Group Kibana"
      groups: ["client_admin"]
      indices: ["*"]
      kibana_access: "admin"
      kibana_hide_apps: ["readonlyrest_kbn"]
    - name: "Client Admin Group"
      groups: ["client_admin"]

    - name: "px1"
      user_id_header: "x-forwarded-user"
    - username: "fulladmin"
      groups: ["full-admin"]
      auth_key: "fulladmin:password"
    - username: "cristian_user"
      groups: ["client_admin"]
        proxy_auth_config: "px1"
        users: ["cristian_user"]

The first problem I notice is that TYP field should provide more precise information about what class is being processed…

I think we are not handling lifecycle management requests well either. We don’t extract any indices information from the request.

@coutoPL wdyt?

This is xpack request, we don’t handle it explicitly. Seems that TYP for this kind of request should be fixed (creating a jira for it).

@cristianr I think this is a correct behaviour. ILM put request doesn’t involve indices. These kind of requests (without indices) matches any indices rule (always)

Maybe it is a correct behaviour that if an index is not specified to match all but it means that indices: [“testx”] is bypassed so forbid block is matched and since ror run in sync mode it will stop directly in forbid which causes a huge problem. We cannot remove forbidden block because we want to give possibilty to update .readonlyrest index only to full-admin groups and for rest we can leave only read access.
So in this moment I cannot think / find an workaround to this or ror should not match all indices if “indices” tag is present in block. It is not normal to match all indices since I specified a list of indices.

Also if you plan to fix that please take into consideration 7.6.2 also since we will migrate to this version in the near future

Creating a ILM policy involves no index, as you can create a policy and later, assign it to any index.

if you want admins to be able to create policies, maybe add an allow block with actions:[“cluster:admin/ilm/put”]

So you suggest to create something like

- name: "Full Admin Users"
    groups: ["full-admin"]
- Name: "Allow ilm": -> This group must be located before forbid in order to match it first ? I'm wright ? 
    groups: ["client_admin","test"]
    actions: [“cluster:admin/ilm/put”] 
- name: "Forbidden for something index"
    groups: ["client_admin", "test"]
    type: "forbid"
    indices: ["testx"]
    methods: ["PUT", "POST", "DELETE"]

yeah exactly (watch out those double quotes)