Access control for results in trigger execution context by markdboyd · Pull Request #1991 · opensearch-project/alerting

markdboyd · 2025-11-21T17:20:38Z

Description

This PR includes a few changes:

Adds a NOTIFICATION_CONTEXT_RESULTS_ALLOWED_ROLES setting to specify which user roles should have access to results from a trigger execution context
Adds a getter for a templateResults property of the TriggerExecutionContext to conditionally make templateResults empty if NOTIFICATION_CONTEXT_RESULTS_ALLOWED_ROLES is set AND the allowed roles do not intersect with the monitor's user roles
Update the asTemplateArg() method for trigger execution contexts to return templateResults as the value for the results property in mustache templates
Adds tests for each type of execution context to ensure that the visibility of templateResults is correct for different scenarios
Refactors code as necessary for compatibility with changes

Related Issues

Resolves #1986

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.

cwperks · 2025-12-16T16:13:26Z

Thank you for this PR @markdboyd. I think it makes sense in the current paradigm to add a new cluster setting for this.

There is an ongoing effort to re-architect how plugins interface with security through a resource sharing framework based on ownership of a resource and access levels. This plugin has not been onboarded yet, but once targeted for onboarding I would also like to see if there is a convenient way to fit this into that model as well by provisioning different levels of access to the context to different users but that may involve introducing new transport actions.

Regardless, this change would work in both paradigms.

cwperks · 2025-12-16T16:18:21Z

@@ -103,8 +103,10 @@ class AnomalyDetectionUtilsTests : OpenSearchTestCase() {
        val searchSourceBuilder = SearchSourceBuilder()
        addUserBackendRolesFilter(
            User(
-                randomAlphaOfLength(5), null, listOf(randomAlphaOfLength(5)),
-                listOf(randomAlphaOfLength(5))


I'm surprised this test did not need to be updated earlier. Has this repo been having failing tests?

Thanks for updating this!

cwperks · 2025-12-16T16:22:21Z

+        Assert.assertTrue(templateResults.isEmpty())
+    }
+
+    fun `test results are excluded in document-level context even when allowed roles intersect monitor roles`() {


For my understanding, why is DocumentLevel context different from BucketLevel and QueryLevel?

For whatever reason, the DocumentLevelTriggerExecutionContext is coded to never pass along results when instantiating the context:

alerting/alerting/src/main/kotlin/org/opensearch/alerting/script/DocumentLevelTriggerExecutionContext.kt

Line 30 in 8a6bad3

monitor, trigger, emptyList(), Instant.now(), Instant.now(),

You can see the third parameter there for the results is an emptyList(). So this context will never have results regardless of this new setting for controlling access that we're adding.

For the QueryLevelTriggerExecutionContext, you can see that the actual monitor results are passed along when instantiating the context:

alerting/alerting/src/main/kotlin/org/opensearch/alerting/script/QueryLevelTriggerExecutionContext.kt

Line 31 in 8a6bad3

monitor, trigger, monitorRunResult.inputResults.results, monitorRunResult.periodStart, monitorRunResult.periodEnd,

This behavior is the same for the BucketLevelTriggerExecutionContext

Looks like that's because the doc level monitor fires when a doc meets certain criteria, whereas bucket level monitor and query level trigger based on query results.

Is there any sensitive info that is present on doc level monitor that ought to be excluded?

According to GPT-5.2 there is not:

You mostly get alert metadata and execution context, not query results or document contents.

I think it would have access to docId and index, but not _source

cwperks

@AWSHurneyt Could you also please review this? Thanks!