Match wrong index in forbid block

1

Hello,
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",
   "policy":"FORBID",
   "rules":[
      "groups",
      "methods",
      "indices"
   ]   "req="{
      "ID":1434536037--1833203081#1306,
      "TYP":"Request",
      "CGR":"client_admin",
      "USR":cristian_user,
      "BRS":false,
      "KDX":null,
      "ACT":"cluster":"admin/ilm/put",
      "OA":172.21.0.4/32,
      "XFF":null,
      "DA":172.21.0.2/32,
      "IDX":"<N/A>",
      "MET":"PUT",
      "PTH":"/_ilm/policy/asdsada",
      "CNT":"<OMITTED",
      LENGTH=122.0 B>,
      "HDR":"Connection=keep-alive",
      Content-Length=122,
      "Host=elasticsearch":9200,
      "content-type=application/json",
      x-forwarded-user=cristian_user,
      "x-ror-current-group=client_admin",
      "x-ror-kibana-request-method=post",
      "x-ror-kibana-request-path=/api/index_lifecycle_management/policies",
      "HIS":[
         "Full Admin Users-> RULES":         [
            "groups->false"
         ],
         "RESOLVED":         [
            "group=client_admin"
         ]
      ],
[
         "Forbidden for .readonlyrest index-> RULES":         [
            "groups->true",
            "methods->true",
            "indices->true"
         ],
         "RESOLVED":         [
            user=cristian_user;group=client_admin;av_groups=client_admin
         ]
      ]
   }

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:

readonlyrest:
  prompt_for_basic_auth: false
  access_control_rules:
    - 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"]

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

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?

3

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)

4

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

5

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”]

6

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"]
7

yeah exactly (watch out those double quotes)