Log REST target with 403

[elasticmachine]

Original comment by @PhaedrusTheGreek:

It's very common when debugging security to see a message like this:

[403] {\"error\":{\"root_cause\":[{\"type\":\"security_exception\",\"reason\":\"action [indices:data/write/bulk] is unauthorized for user [logstash4]\"}],\"type\":\"security_exception\",\"reason\":\"action [indices:data/write/bulk] is unauthorized for user [logstash4]\"},\"status\":403}

Without further exploration, it's not obvious which request has failed. We can see that it is a _bulk request, but on which index? Seeing the index and/or the full REST target with this error message would really be helpful!

[ashishguptak]

Is this being worked upon? I can pick it up if not. I am a newbie, any pointers are much appreciated.

[jucaleb4]

Hi, I'm a newbie and also am looking to start. @ashishguptak have you gotten far with this yet?

[jucaleb4]

@PhaedrusTheGreek which Java file can we get started with to fix this, and how can we reproduce this error

[adityasraghav]

anyone working on this ? If not I'd like to give it a go.

[TCalise]

@adityasraghav Will you be working on this? if not, I wouldn't mind taking it.

[biglandm]

Is this anybody currently working on this?

[minglinlu]

How to fix this problem? I wanna learn.

[elasticmachine]

Pinging @elastic/es-core-features

[fdartayre]

Reproduced in 7.3. The index actions (for instance [indices:data/write/bulk], [indices:admin/create], [indices:data/write/index] and [indices:admin/delete]) don't inform the name of the index in the response in case of failure, which can make debugging challenging.

Is there any update on this?

[fdartayre]

Related: the name of the index is not logged either, even under the DEBUG logging level. It is only under the TRACE level of the o.e.t.TaskManager logger, so not really usable.

[GNUDimarik]

Hi everyone.
Investigating this. I hope it will first my commit here :-)

[GNUDimarik]

This question for developers I think:
Am I on right track?
Seems it happens here:

elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authz/AuthorizationService.java

Line 454 in 777f4b3

for (BulkItemRequest item : request.items()) {

[getsaurabh02]

Hi,
I am going to take a stab at this one, in case no one is actively working on it.

[GNUDimarik]

I'll have a chance to back to this in next week.

[GNUDimarik]

@getsaurabh02 I have chance to do this. Are you working on it?

[auspicacious]

Hi, I'm fairly new to Elasticsearch but I've been looking at this issue, and I think it could use some clarification. Some use cases already seem to be covered.

For instance, working off of master right now, let's say I make a bulk update request to two indices, but the user only has permissions to write to one of them. The API provides some helpful feedback:

{
  "took" : 9,
  "errors" : true,
  "items" : [
    {
      "update" : {
        "_index" : "test1",
        "_id" : "1",
        "_version" : 13,
        "result" : "noop",
        "_shards" : {
          "total" : 2,
          "successful" : 1,
          "failed" : 0
        },
        "_seq_no" : 12,
        "_primary_term" : 1,
        "status" : 200
      }
    },
    {
      "update" : {
        "_index" : "test2",
        "_id" : "1",
        "status" : 403,
        "error" : {
          "type" : "security_exception",
          "reason" : "action [indices:data/write/bulk[s]] is unauthorized for user [noprivs]"
        }
      }
    }
  ]
}

On the other hand, if the user doesn't have permissions to write to either index, the error message is simpler:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "security_exception",
        "reason" : "action [indices:data/write/bulk] is unauthorized for user [noprivs]"
      }
    ],
    "type" : "security_exception",
    "reason" : "action [indices:data/write/bulk] is unauthorized for user [noprivs]"
  },
  "status" : 403
}

So it does seem to be doing the right thing in partial failure situations. Looking at the logs at level DEBUG, there isn't as much information, which isn't ideal, but is that what the original feature request is looking for? Also, I have not yet checked the audit logs, but judging from the code they might also do the right thing.

Is this feature request already taken care of?

[JohnCFerguson]

I am going to take a crack at this just in case no one has had time for it. This will be my first time so hopefully I'm able to help.

[khobey]

Is fix still needed for this one? I can work on this is still free. Thanks!

[GNUDimarik]

I don't work on that at the moment сб, 1 авг. 2020 г., 22:11 Ana Therese Taroy <[email protected]>:

…

Is fix still needed for this one? I can work on this is still free. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29714 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPDTI4J7IAQUTUOEM47TJTR6Q5CDANCNFSM4E5WBHEA> .

[khobey]

Thanks. I'll give this a go.

[JanBucko]

Hello, is anyone working on this issue actually ?

[rodrigo-sp17]

Hi guys! Just linked a PR that attempts to solve this issue. I'm new to Elasticsearch, so I'm might have overlooked some details that require a larger knowledge of the codebase.
I intend to follow up on this, so any feedback is very welcome!

[tvernum]

The was resolved in #60357