Create parent-linked sharing entries for child resources written without a user - #6373
Conversation
|
Companion reporting PR: opensearch-project/reporting# |
Workflow state documents track the provisioning/execution state of a workflow template and have no independent access semantics, yet they were registered as a standalone resource type: access to them did not follow the parent workflow's shares, and state documents written without an authenticated user in the thread context (provisioning steps executed under system context) receive no sharing records at all. Declaring parentType/parentIdField on the workflow_state provider makes state documents inherit access from their workflow via the already-mapped workflow_id field. Requires opensearch-project/security#6373 for state documents written under system context to receive parent-linked sharing entries. Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
…out a user ResourceIndexListener.postIndex previously required an authenticated user in the thread context to create a resource-sharing entry, and skipped silently (debug log, or NPE on a null subject) when one was absent. Writes performed under a plugin or system subject — e.g. reporting's on-demand report instances indexed via PluginClient, or scheduled jobs running under job-scheduler — therefore never received sharing entries, leaving those resources permanently invisible to the resource-sharing APIs, including to their creators. With this change: - The user subject is extracted null-safely. - When no user is present and the resource's provider declares a parent (parentType/parentIdField), the sharing entry is created by inheriting tenant and created_by from the parent's sharing record, linked via parentType/parentId so access evaluation delegates to the parent. - When no user is present and no parent is declared, the skip is now logged at WARN instead of silently at debug, making this failure mode visible to operators. - Failures to index sharing entries are also logged at WARN instead of debug. Companion change: opensearch-project/reporting declares report-instance as a child of report-definition to use this path. Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Verifies via the sample plugin hierarchy that resources indexed without an authenticated user in the thread context (internal node client, mirroring plugin-subject writes): - child resources receive a parent-linked sharing entry inheriting the parent owner, and parent-level shares grant access to them - parent-less resources are skipped (no entry created) - children referencing a missing parent record are skipped Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
72c9f2d to
a34fb50
Compare
PR Reviewer Guide 🔍(Review updated until commit 9d27c4f)Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Latest suggestions up to 9d27c4f Explore these optional code suggestions:
Previous suggestionsSuggestions up to commit 8dfd22f
Suggestions up to commit a34fb50
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6373 +/- ##
==========================================
+ Coverage 75.40% 75.43% +0.03%
==========================================
Files 456 456
Lines 30255 30280 +25
Branches 4575 4580 +5
==========================================
+ Hits 22815 22843 +28
+ Misses 5304 5302 -2
+ Partials 2136 2135 -1
🚀 New features to boost your workflow:
|
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
PR Code Analyzer ❗AI-powered 'Code-Diff-Analyzer' found issues on commit 9d27c4f. ⛔ Hard block: Issues at High severity or above will block this PR from merging.
The table above displays the top 10 most important findings. Pull Requests Author(s): Please update your Pull Request according to the report above. Repository Maintainer(s): You can Thanks. |
|
Persistent review updated to latest commit 8dfd22f |
…r-less The SystemContextChildResourceTests class comment cited reporting's on-demand report instances as an example of a user-less write. They actually stash-then- restore the caller's context (PluginBaseAction), so the authenticated user is present when the instance is indexed and postIndex attributes it normally -- matching this PR's investigation-note correction. Update the doc to cite genuinely user-less writes (scheduled jobs under job-scheduler, system/ provisioning-context) and note the on-demand distinction. Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
|
Persistent review updated to latest commit 9d27c4f |
bb55e64
into
opensearch-project:main
…, comments stash Review feedback on opensearch-project#2180 (riysaxen-amzn): - Super-admin visibility: the RSC filter branch preceded the `user == null` (super-admin) branch in the alerts/workflow-alerts/comment-search/destinations read paths, so a super-admin got filtered to only shared resources. Check `user == null` first so super-admin (and the security-disabled case) sees everything even under resource sharing. - Bug: getAccessibleAlertIDs (and the legacy getFilteredAlertIDs) never set a search size, capping alert resolution at the default 10 and silently dropping comments for alerts beyond the first 10. Set size to MAX_SEARCH_SIZE. - rbac_roles hardening: validation was skipped under RSC. Since the feature flag is dynamic, validate caller-supplied rbac_roles regardless of RSC so a non-admin can't persist roles they don't hold that would gate access if RSC is later disabled. - Comments-history index bootstrap now runs on the plugin subject (stashed in the comment index action's start()); previously a non-admin caller's indices().exists() threw under RSC and the request hung. - Destinations: super-admin now runs a direct (non-DLS) search so it isn't filtered by the resource-sharing DLS path. - Document the index.max_terms_count bound at the monitor/workflow-id term filters; derive the sharing index name from the config index constant in test helpers rather than hardcoding. Subordinate-resource alert/comment access tests remain @ignore'd pending the child-resource sharing model in opensearch-project/security#6373 (updated the FIXMEs to reference it). Verified SecureResourceSharingMonitorRestApiIT: 31 tests, 3 skipped, 0 failures under the resource-sharing variant. Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Description
ResourceIndexListener.postIndexrequires an authenticated user in the thread context to create a resource-sharing entry. When none is present, it fails with an uncaught NPE (null user subject) or skips silently at debug level. Resources written in a genuinely user-less context — scheduled jobs running under job-scheduler (e.g. scheduled report instances), provisioning steps executed under system context — therefore never receive sharing entries and stay permanently invisible to the resource-sharing APIs, including to the owner of the parent resource that triggered them.Changes
parentType/parentIdField): the sharing entry is created by inheritingtenant/created_byfrom the parent's sharing record, linked viaparentType/parentIdsoResourceAccessHandlerdelegates evaluation to the parentTesting
New integration tests (
SystemContextChildResourceTests, sample plugin hierarchy, all passing) index resource documents through the internal node client — no user in context, mirroring plugin/system-subject writes:Investigation note (correction)
This PR was initially motivated by on-demand report instances missing sharing records on a 3.8.0 snapshot. Deeper investigation showed that case was actually caused by listener-attachment timing on that build: the listener attaches per-index in
onIndexModulefiltered byprotected_types, so a type added to the dynamic setting after its index was already open never got a listener until restart (current main attaches based on the unfiltered registered set, so main appears immune). On-demand instance writes do carry the authenticated user and work once the listener is attached. The user-less gap addressed by this PR remains real for scheduled/system-context writes, as covered by the new tests.Companion PRs
Category
Bug fix
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.