Add filter by backend roles setting by markdboyd · Pull Request #2034 · opensearch-project/alerting

markdboyd · 2026-03-06T22:50:30Z

Description

This PR adds a new plugin setting, plugins.alerting.filter_by_backend_roles_access_strategy, which allows users to control how filtering by backend roles works to determine access to alerting objects (monitors). The options for this setting are:

exact - Users have access to alerting objects if they have exactly the same (with no additional) backend roles as the user who created the object
intersect - Users have access to alerting objects if they share at least one backend role with the user who created the object
all - Users have access to alerting objects if their backend roles contain all of the backend roles of the user who created the object

Related Issues

Resolves #1940

Check List

New functionality includes testing.
New functionality has been documented.
API changes companion pull request created.
Commits are signed per the DCO using --signoff.
Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

AWSHurneyt · 2026-03-20T17:32:42Z

alerting/src/main/kotlin/org/opensearch/alerting/transport/SecureTransportAction.kt

+    fun doUserBackendRolesMatchResource(userBackendRoles: List<String>, resourceBackendRoles: List<String>): Boolean {
+        if (filterByAccessStrategy == FilterByBackendRolesAccessStrategy.INTERSECT.strategy) {
+            return resourceBackendRoles.any { it in userBackendRoles }
+        } else if (filterByAccessStrategy == FilterByBackendRolesAccessStrategy.ALL.strategy) {


@markdboyd with the ALL strategy, what is the intended behavior when a user has all of the same backend roles but also some additional roles? With this implementation, it looks like a user with more roles would not match the resource.

If I'm understanding the use case correctly, are the below behaviors the intention?

user roles = [role1, role2, role3] and resource roles = [role1, role2, role3] should match

user roles = [role1, role2, role3, role4, role5] and resource roles = [role1, role2, role3] should match

user roles = [role1, role2, role3] and resource roles = [role1, role2, role3, role4, role5] should not match

@AWSHurneyt

what is the intended behavior when a user has all of the same backend roles but also some additional roles

In this case with the ALL strategy, the user would not have access.

If I'm understanding the use case correctly, are the below behaviors the intention?

user roles = [role1, role2, role3] and resource roles = [role1, role2, role3] should match

user roles = [role1, role2, role3, role4, role5] and resource roles = [role1, role2, role3] should match

user roles = [role1, role2, role3] and resource roles = [role1, role2, role3, role4, role5] should not match

For scenario 2, the behavior would also be not match and the user would not have access

Perhaps ALL would be better named MATCH_EXACTLY to specify this behavior?

Ah thanks for clarifying. Yeah, EXACT makes sense in my mind given that additional context.

However, that intended behavior seems odd to me. Could you help me understand the use case for not permitting access to the resource when a user has more roles than are necessary?

@AWSHurneyt - I thought more about this and I agree: ALL should provide access if the user roles contain all of the object backend roles, even if the user has additional roles. So for ALL, the user would have access in scenarios 1 and 2.

I added new logic to handle the ALL strategy. And I added EXACT as a separate strategy where the roles must match exactly with no additional roles