[Failure Store] Has Privileges API

[n1v0lg]

This PR adds support for checking access to the failure store via the Has Privileges API.

To check access for a data stream logs, a request must query for a concrete named privilege, read_failure_store or manage_failure_store, e.g., a request to the HasPrivileges API by a user with read_failure_store over logs:

POST /_security/user/_has_privileges
{
    "index": [
        {
            "names": ["logs"],
            "privileges": ["read_failure_store", "read", "indices:data/read/*"]
        }
    ]
}

Returns:

{
    "username": "<...>",
    "has_all_requested": false,
    "cluster": {},
    "index": {
        "logs": {
            "read_failure_store": true,
            "read": false, <1>
            "indices:data/read/*": false <2>
        }
    },
    "application": {}
}

Note that <1> and <2> are both false since read is not covered by read_failure_store and neither are any raw actions like indices:data/read/* since these implicitly correspond to data access.

Selectors are not allowed in the index patterns of HasPrivileges requests to avoid ambiguities such as checking read on logs::failures as well as the ambiguity of index patterns that are regular expressions.

[slobodanadamovic]

one optimization to consider: we could wrap getIndexPrivilegesAutomaton calls into CachedSupplier and make allowedPrivilegesAutomatonForFailuresSelector and allowedPrivilegesAutomatonForDataSelector be computed lazily when checkWithDataSelector or checkWithFailuresSelector is true - respectively

[n1v0lg]

I was thinking about this too but CachedSupplier involves a synchronized block and might be a little too heavy for the context here (since we don't need synchronization here, I don't think) -- at least I can't immediately say if it would provide an actual gain or not. My thinking here is:

1. Most calls will be checking for data selectors privileges (there are more of them, and it's the "normal" workflow to access regular data)
2. This means we'll need the data selectors automata most of the time, which is why I added short-circuiting failures-only selector computation via containsPrivilegesForFailuresSelector. We could do the same for data selectors but that's another pass over the privileges with another set of Map look-ups, or something slightly more complicated

Let me know if you have a stronger intuition here. I'd love to benchmark this and get some real performance numbers but would not want to block on that.

[slobodanadamovic]

Good point - we don't want synchronization here. FWIW We could implement a non-blocking version of cached supplier, but I don't feel this is something we should block on. My intuition is the same, we would be mostly checking data selectors and the optimization you already have could be sufficient.

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[slobodanadamovic]

LGTM 👍

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.x	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 125329

[slobodanadamovic]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Questions ?

Please refer to the Backport tool documentation