[Serverless][Security] Allow Dashboard and Discover privileges on Security projects - #289904
[Serverless][Security] Allow Dashboard and Discover privileges on Security projects#289904bhapas wants to merge 17 commits into
Conversation
…urity projects Register standalone Dashboard and Discover feature privileges so custom roles can grant those apps without the Security solution. Co-authored-by: Cursor <cursoragent@cursor.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the config, navigation, and test changes. The feature-privilege registration approach looks sound — visualize_v2/maps_v2 remain hidden via serverless.yml, so only dashboard_v2/discover_v2 become assignable under the Security category as intended. Two concrete items left inline: a stale inline snapshot that will fail after narrowing compositeFeatureIds, and a duplicate "Dashboards" nav label.
Generated by Claude Reviewer for #289904 · claude · opus · 224.6 AIC · ⌖ 46.9 AIC · ⊞ 5.5K
bhapas
added
backport:skip
…Security projects Unhide Dashboard and Discover feature privileges on Security serverless and recategorize them under Security. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Reviewed the config change against the platform-wide serverless.yml. One concrete concern: removing the hidden overrides also un-hides the deprecated v1 visualize/maps features, which (unlike their v2 variants) are not hidden by serverless.yml, so they would newly appear in Security role management. Details inline. The dashboard_v2/discover_v2 category moves and reliance on serverless.yml to keep the v2 Visualize/Maps hidden look correct.
Generated by Claude Reviewer for #289904 · claude · opus · 139.7 AIC · ⌖ 50.4 AIC · ⊞ 5.5K
…tests Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
… to Dashboards Co-authored-by: Cursor <cursoragent@cursor.com>
…ng tests Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Note
Copilot was unable to run its full agentic suite in this review.
Pull request overview
Registers Dashboard/Discover feature privileges for Serverless Security projects and updates UI/navigation behavior so users with only those privileges can access the appropriate apps without granting full Security solution access.
Changes:
- Adds API integration coverage to verify Dashboard/Discover privilege registration, action grants, and feature categorization under Security.
- Introduces a client-side redirect from Security “Get started” to Dashboards for dashboard-only users, with unit + UI coverage.
- Updates serverless Security feature overrides to place Dashboard/Discover in the Security role-management category.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| x-pack/solutions/security/test/serverless/api_integration/test_suites/platform_security/authorization.ts | Adds/adjusts privilege + feature-category assertions for Dashboard/Discover on Serverless Security. |
| x-pack/solutions/security/plugins/security_solution_serverless/test/scout/ui/parallel_tests/dashboard_only_landing.spec.ts | Adds UI regression coverage for dashboard-only landing/redirect behavior. |
| x-pack/solutions/security/plugins/security_solution_serverless/public/navigation/redirect_dashboard_only_landing.ts | Adds redirect logic for users lacking Security app access but having Dashboards access. |
| x-pack/solutions/security/plugins/security_solution_serverless/public/navigation/redirect_dashboard_only_landing.test.ts | Adds unit tests for redirect predicate + navigation behavior. |
| x-pack/solutions/security/plugins/security_solution_serverless/public/navigation/index.ts | Wires the redirect into navigation startup. |
| config/serverless.security.yml | Re-categorizes Dashboard/Discover features and adjusts hidden feature overrides. |
Suppressed comments (1)
x-pack/solutions/security/test/serverless/api_integration/test_suites/platform_security/authorization.ts:1
- These new tests repeatedly call
/api/security/privileges(and again withincludeActions=true). In large serverless API integration suites, repeated requests can noticeably increase runtime and flakiness. Consider fetching privileges once in abeforehook (and once forincludeActions=true) and reusing the response bodies across the relatedit(...)blocks.
/*
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…Scout test Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Unhiding Dashboard and Discover made the predefined viewer role's latent `.all` grants effective, so Scout 403 tests started passing writes. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
One privilege-escalation concern in the serverless role definitions: the viewer fix (.all → .read) was not applied to t1_analyst/t2_analyst, which share the same read-tier SIEM pattern. Details inline.
Generated by Claude Reviewer for #289904 · claude · opus · 154.7 AIC · ⌖ 22.5 AIC · ⊞ 5.5K
…-only Those roles use SIEM read, so unhiding Dashboard/Discover must not activate their latent `.all` grants. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…pabilities Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Reviewed the feature-privilege config, predefined role changes, the new dashboard-only landing redirect, and the added tests. The redirect logic and its unit coverage look solid, and the category/unhide changes are consistent with how deprecated v1 features resolve. Left one inline comment about a landing gap for the newly-assignable Discover-only role.
Generated by Claude Reviewer for #289904 · claude · opus · 213.4 AIC · ⌖ 23.1 AIC · ⊞ 5.5K
| capabilities[CASES_FEATURE_ID]?.read_cases | ||
| ); | ||
|
|
||
| export const canAccessDashboardsApp = (capabilities: Capabilities): boolean => |
There was a problem hiding this comment.
This PR also makes discover_v2 independently assignable (the config unhides it), so a Discover-only custom role (discover_v2: ['read'], no dashboard, no siem*) is now possible — but the landing redirect only handles users who can reach the Dashboards app.
For such a user: canAccessSecurityLanding is false (no siem/rules/alerts/cases/attack-discovery), and canAccessDashboardsApp is false (no dashboard_v2.show), so shouldRedirectDashboardOnlyLanding returns false. They land on the default route /app/security/get_started, which they can't access — and as the comment on subscribeDashboardOnlyLanding notes, an inaccessible Security app yields "App Not Found" with no currentAppId$ emission. There's no redirect to Discover, leaving them stranded with no working landing.
Consider routing Discover-only users to /app/discover (e.g. fall back to a discover_v2.show check when dashboards aren't accessible), or confirm this case is intentionally out of scope for now.
💛 Build succeeded, but was flaky
Failed CI Steps
Metrics [docs]Page load bundle
Test Failures
History
cc @bhapas |
Summary
On Security serverless projects, Dashboard and Discover were hidden from role management and were not registered as standalone feature privileges. A custom role that granted only those features could be saved, but the privileges did not take effect.
This change:
/app/dashboards(SecuritydefaultRoutestays/app/security/get_startedfor users who can open it)Visualize v2 and Maps v2 stay hidden. They continue to be granted through Dashboard.
This PR does not add a second Dashboards item to the Security side nav. The existing “Dashboards” entry is Security
/app/security/dashboardsand still needssiem. A nav label for/app/dashboardsis waiting on Product.Dashboard-only landing
After chrome starts (and on
currentAppId$), if the path is/,/app/security, or/app/security/get_started, the user cannot access Get started (navLinks.securitySolutionUIis false), and they can access dashboards (navLinks.dashboards === trueorcapabilities.dashboard_v2.show), they are sent toapplication.navigateToApp('dashboards', { replace: true }). Editors stay on Get started.There is no nav item back to
/app/dashboards. Discover remains reachable from chrome. The acceptance signal for this redirect is the URL (/app/dashboards), not listing chrome.Scout: assert the redirect by URL only
x-pack/solutions/security/plugins/security_solution_serverless/test/scout/ui/parallel_tests/dashboard_only_landing.spec.tslogs in a customdashboard_v2+discover_v2readrole, opens Get started, and asserts:It does not assert
#dashboardListingHeading, the empty-list prompt, orchrome.pageTitle === 'Dashboards'. Those locators only hold on an empty listing or specific chrome titles. This suite shares the space (spaces: ['*']) with other parallel Scout tests that leave dashboards behind, so listing chrome flakes even when the redirect succeeded.The privileged-user case still asserts the user stays on Get started.
Predefined roles (CI / kbn-es)
Unhiding Dashboard and Discover made existing
.allgrants on Security predefined roles live. Those grants were inert while the features were hidden; SIEMreadonly composedOfread. After unhide,viewer(andt1_analyst/t2_analystfor dashboard/discover) could write, which broke platform Scout 403 tests.This PR changes the kbn-es Security project roles copy (
src/platform/packages/shared/kbn-es/src/serverless_resources/project_roles/security/roles.yml):viewer:dashboard_v2/discover_v2/maps_v2/visualize_v2.all→.readt1_analystandt2_analyst:dashboard_v2/discover_v2.all→.readonly (maps/visualize stay.all; those features remain hidden)siemV5.all(editor,t3_analyst, and similar) are unchangedCI uses this kbn-es file. MKI / production still serve the elasticsearch-controller copy. Do not treat this file as the production source of truth; the controller must be updated separately or viewer/t1/t2 will keep
.allin real projects.Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesbackport:*labels.Identify risks
Existing custom roles on Security projects that already include Dashboard or Discover privileges will start granting that access after upgrade. This is additive only. Existing Security (
siem*) roles are unchanged.Unhiding also activates stored
.allgrants on predefined Security roles. The kbn-es copy is tightened to.readfor the roles above so CI matches intended viewer/analyst write access. Production still follows elasticsearch-controller until that repo is updated.Test plan
GET /api/security/privilegeson a Security project includesdashboard,dashboard_v2,discover, anddiscover_v2GET /api/featuresshowsdashboard_v2anddiscover_v2in the Security categoryreadonly. That user can open Dashboards and Discover and does not get Security solution accessreadstill has Dashboard and Discover access/,/app/security, and/app/security/get_startedredirect to/app/dashboards. An editor stays on Get starteddashboard_only_landing.spec.tspasses by URL (/app/dashboards). Do not require listing heading / empty-state locators; other parallel suites share the space and may leave dashboardssiem*action sets. The large inline snapshot is not regenerated unless that leftover test still fails in CIRelease note
On Elastic Cloud Serverless Security projects, Dashboard and Discover can be assigned as feature privileges. Custom roles can grant access to those apps without granting the full Security solution. Roles that already included these privileges will now receive that access.