Field Level Security and aggregations

1

Hello,

I’ve question about FLS and aggregations, I’m not sure response is proper as it do not pass our security requirements.

curl -s -u test:test -H 'Content-Type: application/json'      "http://localhost:9200/some-index/_search" -POST -d '{"aggs":{"2":{"terms":{"field":"fieldname.header_HTTP","order":{"_count":"desc"},"size":1}}}}'

  "aggregations": {
    "2": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 397,
      "buckets": [
        {
          "key": "XXXXXXXXXXX",
          "doc_count": 2
        }
      ]
    }
  }
}

In response, there is no fieldname.header_HTTP, which is fine. At the same time values are visible as key. My RoR configuration is like below.
I do not get why when we us aggs values are visible in response.
{ “query”: { “term”: { “fieldname.header_HTTP”: { “value”: “something” }}}} :white_check_mark:
{“aggs”:{“2”:{“terms”:{“field”:“fieldname.header_HTTP”,“order”:{"_count":“desc”},“size”:5}}}}’ :x:

What is difference for RoR nad FLS ?
Is there any other way to restrict aggs ?

ElasticSearch 7.16.1 
RoR 1.39.0

readonlyrest:
  fls_engine: "es"

  access_control_rules:

  - name: "allow  access"
    type: allow
    verbosity: error
    kibana_access: rw
    fields: ["~fieldname*"]
    auth_key: "user:password"
    indices: [".kibana*", "index_name*"]

Thanks in advance!

2

Hi Tomasz,

I will check it and let you know.

3

Hi Mateusz,
Have you had a chance to reproduce issue ?

Regards,
Tomasz

4

Hi Tomasz,
not yet :frowning: Please give me some more time

5

Hi Tomasz,

Sorry for the late response.
I was able to reproduce and analyze your case. Sadly, it doesn’t look like it’s easy to improve.

But I think I have a workaround. You can use fields_response rule to remove the “key” field from the response. It can be done like that:

readonlyrest:
  fls_engine: "es"

  access_control_rules:

  - name: "allow  access"
    type: allow
    verbosity: error
    kibana_access: rw
    fields: ["~fieldname*"]
    response_fields: ["~aggregations.*.buckets.key"]
    auth_key: "user:password"
    indices: [".kibana*", "index_name*"]

The response should be similar to this one:

  [...]
  "aggregations": {
    "2": {
      "doc_count_error_upper_bound": 0,
      "sum_other_doc_count": 397,
      "buckets": [
        {
          "doc_count": 2
        }
      ]
    }
  }

Obviously, it doesn’t solve the problem in general. Because still, you see the aggregated results. The information leaks.

But AFAIU your objections were due to the key value. So, maybe the workaround is satisfying for you ATM?

6

Good workaround in general, but wouldn’t it break Kibana not to have the aggregation key in the response entirely?

Ideally we could have a rule to intercept by JSON path, and hash or completly obfuscate fields, rather than just removing them?

Not sure if leaking the count of distinct values would represent a leak in this case, but at least the customer could choose.

@gintek what do you think?

7

yeah, from Kibana perspective this workaround may not work.
I will obviously try to solve it much more sophisticated way.

@sscarduzio this is a great idea for the new rule. response_fields removes fields (or paths) from responses. The new rule could (as you proposed) hash the values under specified fields.

1 Like
8

Yeah! Let’s have this in Jira for current sprint, later we will prioritise it and move it to the right place?

1 Like
9

@gintek the issue has been fixed. It’ll be released with ROR 1.45.0. If you want to test it, here is the pre-build (ROR 1.45.0-pre3 for ES 7.16.1)