[Feature Request] Rule Based request labeling to define multi-tenancy

[kaushalmahi12]

Author: Kaushal Kumar

Is your feature request related to a problem? Please describe

Currently there is no mechanism to label/classify the incoming requests into tenants. There is an RFC open for defining the multi-tenancy in OpenSearch. We should provide a way to translate request's implicit/explicit attributes into tenants. Currently we are working on query sandboxing which can leverage this but this is not limited to this feature only and can be easily leveraged for both the indexing as well as search workloads.

Describe the solution you'd like

Rule Based Labeling

We will enable admin users to define rules to translate requests into output tokens which can be interpreted as tenants for consuming features. These rules can leverage implicit|explicit attributes to define the tenants. The output tokens will be propagated via ThreadContext or can be consumed into the feature directly as return values.

Implicit attributes could be anything like

• LoggedIn entity
• Indices

Explicit Attributes

• custom tags

I am skipping over the authN/authZ part for explicit attributes since that is something which should be handled at the security layer as discussed in the parent RFC

What will a Rule look like ?

{
    "Input": {
        "attr1": ["val1", "val2*"],
        "attr2": ["xyz", "xyz*"]
        .....
    },
    "Output": {
        "field1": "value",
        "field2": "value",
        ....
    }
}

What if multiple rules matches for a request, how to resolve these conflicts ?
Only one Rule should apply for a request. To avoid such conflicts we will ensure that no two rules are overlapping. But doing this will not ensure that the rukes doesn't overlap. We still need to come up with precedence of attributes.

Now the precedence of attributes needs to be tackled for both the supported type of attributes.

• Implicit Attributes: For these attributes we can define the precedence based on the request type, if the request is co-ordinator level then give priority to loggedInEntity attribute and if the request is shard level we can give priority to index attribute.
• Explicit Attributes: For explicit attributes It will be hard to enforce precedence sicne the we don't know what all attributes could be used as explicit attributes for all the users beforehand. Since this will vary from user to user, It is more suitable for users to define such order. Now we can provide users with two ways of giving this input.

1. as part of request (QueryParam): something like _search?precedence="attr1>attr2"
2. define it as part of config to be stored somewhere else

Related component

Other

Describe alternatives you've considered

No response

Additional context

No response

[peternied]

[Triage - attendees 1 2 3 4 5]
@kaushalmahi12 Thanks for creating this issue