mirror of
https://github.com/elastic/kibana.git
synced 2025-04-21 16:29:04 -04:00
Your window into the Elastic Stack
8ee04937fe
## [Security Solution] [Attack discovery] Attack Discovery RBAC / Display an upgrade CTA for the serverless essentials product tier ### Summary This PR adds Role Based Access Control (RBAC) to Attack discovery. Security users may enable or disable the new `Attack Discovery` RBAC feature shown in the figure below:  _Above: The new `Attack discovery` RBAC feature_ It is possible to for example, configure a custom role that enables Attack discovery, but disables the assistant, as illustrated by the table below: | Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------| | `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ | | `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ | _Above: An example role that enables Attack discovery, but disables the assistant_ See the `Desk Testing` section of this PR for details. This PR also fixes an issue where Attack discovery does not display an upgrade call to action (CTA) for the serverless _essentials_ product tier, per the before and after screenshots below: #### Before  _Above: Before the fix, an upgrade CTA is NOT displayed for the serverless essentials product tier_ #### After  _Above: After the fix, an upgrade CTA is displayed for the serverless essentials product tier_ The fix above is implemented by adopting the upselling framework. ### New Feature ID This PR adds a new Feature ID for attack discovery: ```typescript export const ATTACK_DISCOVERY_FEATURE_ID = 'securitySolutionAttackDiscovery' as const; ``` in `x-pack/packages/security-solution/features/src/constants.ts` ### Upselling framework usage This PR updates the Attack discovery page to use the upselling framework via the following summarized steps: 1. Removed the branching logic from `x-pack/plugins/security_solution/public/attack_discovery/pages/upgrade/index.tsx`, and moved the component to an upselling `section` component in `x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx`, where the component was renamed to `AttackDiscoveryUpsellingSection`. This `section` component handles (just) the styling of the upselling message and actions (by itself, without the page wrapper), and receives the following props: ```typescript interface Props { actions?: React.ReactNode; availabilityMessage: string; upgradeMessage: string; } ``` The self managed and serverless-specific actions and `i18n` messages are passed down via the components described in the later steps below. 2. Removed all previous references to the `Upgrade` component (and references to `useProductTypes`) from the Attack discovery page in `x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx`, because the framework manages the upgrade case instead of the page itself. 3. Created an upselling `page` component `AttackDiscoveryUpsellingPage` in `x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx`. This component handles (just) the styling of the _page_ that wraps the Attack discovery `section`. It passes the same props to the previously described `AttackDiscoveryUpsellingSection` component. 4. Created a self-managed-specific `AttackDiscoveryUpsellingPageESS` component in `x-pack/plugins/security_solution_ess/public/upselling/pages/attack_discovery/index.tsx` This component passes self-managed-specific upgrade action buttons / links and `i18n` strings to the previously described `AttackDiscoveryUpsellingPage` 5. Also for self managed, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_ess/public/upselling/lazy_upselling.tsx` This component lazy loads the previously described `AttackDiscoveryUpsellingPageESS` component. 6. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `UpsellingPages` section in `x-pack/plugins/security_solution_ess/public/upselling/register_upsellings.tsx` with a `minimumLicenseRequired` of `enterprise`: ``` minimumLicenseRequired: 'enterprise', ``` 7. Created a serverless-specific `AttackDiscoveryUpsellingPageServerless` component in `x-pack/plugins/security_solution_serverless/public/upselling/pages/attack_discovery/index.tsx` This component passes serverless-specific `i18n` messages to the platform agnostic `AttackDiscoveryUpsellingPage` component. 8. Also for serverless, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_serverless/public/upselling/lazy_upselling.tsx` 9. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `upsellingPages` section in `x-pack/plugins/security_solution_serverless/public/upselling/upsellings.tsx` with the `assistant` PLI: ``` pli: ProductFeatureKey.assistant, ``` 10. Added the `${ASSISTANT_FEATURE_ID}.ai-assistant` capability as an OR condition (via nested array, per the [framework](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts#L11-L22)) to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts`. This addition enables the security route wrapper to check for upselling pages in serverless: ``` capabilities: [[`${SERVER_APP_ID}.show`, `${ASSISTANT_FEATURE_ID}.ai-assistant`]], ``` 11. Added `licenseType: 'enterprise'` to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts` to require an `enterprise` license for self managed ### Upgrade CTA gallery The screenshots in this section document the CTA (or Welcome message when the feature is licensed) displayed for various license levels after the fix: #### Users with the `None` privilege If users with the `None` privilege manually enter an Attack discovery URL, e.g. `http://localhost:5601/app/security/attack_discovery`, the framework will display the following error prompt:  #### Self managed BASIC  #### Self managed PLATINUM  #### Self managed TRIAL  #### Self managed ENTERPRISE  #### Serverless ESSENTIALS  #### Serverless COMPLETE  ## Desk Testing ### Severless: Desk testing (just) the upgrade CTA Reproduction steps: 1) Comment-out any preconfigured connectors in `config/kibana.dev.yml` 2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'security', product_tier: 'essentials' } ] ``` 3) Start Elasticsearch ```sh yarn es serverless --projectType security ``` 4) Start a development instance of Kibana ``` yarn start --serverless=security --no-base-path ``` 5) Navigate to Security > Attack discovery **Expected result** - An upgrade CTA is displayed, as illustrated by the _after_ screenshot below:  - The video tour is NOT displayed for serverless, as noted in the [original PR](https://github.com/elastic/kibana/pull/182605#issuecomment-2100607857) **Actual result** - An upgrade CTA is NOT displayed, as illustrated by the _before_ screenshot below:  ### Desk testing Self Managed To desk test self manged, we will: 1) Create (three) roles for testing 2) Create (three) users assigned to the roles 3) Test each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels to verify: - `Attack discovery` link visibility in the Security solution navigation - Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable - The upsell empty prompt includes the `Subscription plans` and `Manage license` actions - When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled / disabled, based on availability of the `AI Assistant` feature #### Creating (three) roles for testing In this section, we will start a new (development) self managed deployment, and create the following three roles via Kibana Dev Tools: - `has_attack_discovery_all_assistant_all` - `has_attack_discovery_all_assistant_none` - `has_attack_discovery_none_assistant_all` To start the deployment and create the roles: 1) Add a pre-configured GenAI connector to `config/kibana.dev.yml` 2) Start a new (development) instance of Elasticsearch: ```sh yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-07-31a ``` 3) Start a local (development) instance of Kibana: ``` yarn start --no-base-path ```` 4) Login to Kibana as the `elastic` user 5) Generate some alerts 6) Navigate to Dev Tools 7) Execute the following three API calls to create the roles: <details><summary>PUT /_security/role/has_attack_discovery_all_assistant_all</summary> <p> ``` ts PUT /_security/role/has_attack_discovery_all_assistant_all { "cluster": [ "all" ], "indices": [ { "names": [ "*" ], "privileges": [ "all" ], "field_security": { "grant": [ "*" ], "except": [] }, "allow_restricted_indices": false } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "feature_securitySolutionAssistant.minimal_all", "feature_securitySolutionAttackDiscovery.minimal_all", "feature_siem.all", "feature_securitySolutionCases.all", "feature_actions.all" ], "resources": [ "*" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } ``` </p> </details> <details><summary>PUT /_security/role/has_attack_discovery_all_assistant_none</summary> <p> ``` ts PUT /_security/role/has_attack_discovery_all_assistant_none { "cluster": [ "all" ], "indices": [ { "names": [ "*" ], "privileges": [ "all" ], "field_security": { "grant": [ "*" ], "except": [] }, "allow_restricted_indices": false } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "feature_securitySolutionAttackDiscovery.minimal_all", "feature_siem.all", "feature_securitySolutionCases.all", "feature_actions.all" ], "resources": [ "*" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } ``` </p> </details> <details><summary>PUT /_security/role/has_attack_discovery_none_assistant_all</summary> <p> ``` ts PUT /_security/role/has_attack_discovery_none_assistant_all { "cluster": [ "all" ], "indices": [ { "names": [ "*" ], "privileges": [ "all" ], "field_security": { "grant": [ "*" ], "except": [] }, "allow_restricted_indices": false } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "feature_securitySolutionAssistant.minimal_all", "feature_siem.all", "feature_securitySolutionCases.all", "feature_actions.all" ], "resources": [ "*" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } ``` </p> </details> #### Creating (three) users assigned to the roles In this section, we will create the following three users via Kibana Dev Tools using the API calls below (expand for details): - `attack_discovery_all_assistant_all` - `attack_discovery_all_assistant_none` - `attack_discovery_none_assistant_all` 1) Navigate to Dev Tools 2) Execute the following three API calls to create the users: <details><summary>POST /_security/user/attack_discovery_all_assistant_all</summary> <p> ``` ts POST /_security/user/attack_discovery_all_assistant_all { "username": "attack_discovery_all_assistant_all", "password": "changeme", "roles": [ "has_attack_discovery_all_assistant_all" ], "full_name": "Attack Discovery All Assistant All", "email": "user@example.com", "metadata": {}, "enabled": true } ``` </p> </details> <details><summary>POST /_security/user/attack_discovery_all_assistant_none</summary> <p> ``` ts POST /_security/user/attack_discovery_all_assistant_none { "username": "attack_discovery_all_assistant_none", "password": "changeme", "roles": [ "has_attack_discovery_all_assistant_none" ], "full_name": "Attack Discovery All Assistant None", "email": "user@example.com", "metadata": {}, "enabled": true } ``` </p> </details> <details><summary>POST /_security/user/attack_discovery_none_assistant_all</summary> <p> ``` ts POST /_security/user/attack_discovery_none_assistant_all { "username": "attack_discovery_none_assistant_all", "password": "changeme", "roles": [ "has_attack_discovery_none_assistant_all" ], "full_name": "Attack Discovery None Assistant All", "email": "user@example.com", "metadata": {}, "enabled": true } ``` </p> </details> #### Testing each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels In this section, we will test each of the self managed `Basic`, `Trial`, `Platinum`, and `Enterprise` license levels with the three roles we created for testing. ##### Testing the `has_attack_discovery_all_assistant_all` role 1) Login as the `attack_discovery_all_assistant_all` user 2) Navigate to the Security solution 3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below: | Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------| | `has_attack_discovery_all_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_all` | Trial | ✅ | ❌ | ❌ | ✅ | | `has_attack_discovery_all_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_all` | Enterprise | ✅ | ❌ | ❌ | ✅ | ##### Testing the `has_attack_discovery_all_assistant_none` role 1) Login as the `attack_discovery_all_assistant_none` user 2) Navigate to the Security solution 3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below: | Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------| | `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ | | `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ | ##### Testing the `has_attack_discovery_none_assistant_all` role 1) Login as the `attack_discovery_none_assistant_all` user 2) Navigate to the Security solution 3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below: | Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------| | `has_attack_discovery_none_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_none_assistant_all` | Trial | ❌ | ❌ | ❌ | ❌ | | `has_attack_discovery_none_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ | | `has_attack_discovery_none_assistant_all` | Enterprise | ❌ | ❌ | ❌ | ❌ | --------------------------------------------- ### Serverless Testing To desk test serverless, we will test the `essentials` and `complete` product tiers to verify: - `Attack discovery` link visibility in the Security project navigation - Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable - The upsell empty prompt does NOT include the `Subscription plans` and `Manage license` actions - When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled #### Essentials tier testing 1) Add a pre-configured GenAI connector to `config/kibana.dev.yml` 2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'security', product_tier: 'essentials' }, { product_line: 'endpoint', product_tier: 'essentials' }, ] ``` 2) Start a new (development) instance of Elasticsearch: ```sh yarn es serverless --clean --projectType security ``` 3) Start a local (development) instance of Kibana: ``` yarn start --serverless=security --no-base-path ```` 4) select the `admin` role 5) Generate some alerts 6) Verify your observations match the expected behavior in the table below: | Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |-------------------------------|------------|--------------------|-------------|--------------------|---------------------------| | `viewer` | essentials | ✅ | ✅ | ❌ | ❌ | | `editor` | essentials | ✅ | ✅ | ❌ | ❌ | | `t1_analyst` | essentials | ✅ | ✅ | ❌ | ❌ | | `t2_analyst` | essentials | ✅ | ✅ | ❌ | ❌ | | `t3_analyst` | essentials | ✅ | ✅ | ❌ | ❌ | | `threat_intelligence_analyst` | essentials | ✅ | ✅ | ❌ | ❌ | | `rule_author` | essentials | ✅ | ✅ | ❌ | ❌ | | `soc_manager` | essentials | ✅ | ✅ | ❌ | ❌ | | `detections_admin` | essentials | ✅ | ✅ | ❌ | ❌ | | `platform_engineer` | essentials | ✅ | ✅ | ❌ | ❌ | | `endpoint_operations_analyst` | essentials | ✅ | ✅ | ❌ | ❌ | | `endpoint_policy_manager` | essentials | ✅ | ✅ | ❌ | ❌ | | `admin` | essentials | ✅ | ✅ | ❌ | ❌ | | `system_indices_superuser` | essentials | ✅ | ✅ | ❌ | ❌ | ### Complete tier testing 1) Stop the running Kibana server (from the previous Essentials tier testing) 2) Edit the configuration of `config/serverless.security.yml` to enable the `complete` product tier: ```yaml xpack.securitySolutionServerless.productTypes: [ { product_line: 'security', product_tier: 'complete' }, { product_line: 'endpoint', product_tier: 'complete' }, ] ``` 3) Restart a local (development) instance of Kibana: ``` yarn start --serverless=security --no-base-path ```` 4) Verify your observations match the expected behavior in the table below: | Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled | |-------------------------------|----------|--------------------|-------------|--------------------|---------------------------| | `viewer` | complete | ✅ | ❌ | ❌ | ✅ | | `editor` | complete | ✅ | ❌ | ❌ | ✅ | | `t1_analyst` | complete | ✅ | ❌ | ❌ | ✅ | | `t2_analyst` | complete | ✅ | ❌ | ❌ | ✅ | | `t3_analyst` | complete | ✅ | ❌ | ❌ | ✅ | | `threat_intelligence_analyst` | complete | ✅ | ❌ | ❌ | ✅ | | `rule_author` | complete | ✅ | ❌ | ❌ | ✅ | | `soc_manager` | complete | ✅ | ❌ | ❌ | ✅ | | `detections_admin` | complete | ✅ | ❌ | ❌ | ✅ | | `platform_engineer` | complete | ✅ | ❌ | ❌ | ✅ | | `endpoint_operations_analyst` | complete | ✅ | ❌ | ❌ | ✅ | | `endpoint_policy_manager` | complete | ✅ | ❌ | ❌ | ✅ | | `admin` | complete | ✅ | ❌ | ❌ | ✅ | | `system_indices_superuser` | complete | ✅ | ❌ | ❌ | ✅ | |
||
|---|---|---|
| .buildkite | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| oas_docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| test | ||
| typings | ||
| x-pack | ||
| .backportrc.json | ||
| .bazelignore | ||
| .bazeliskversion | ||
| .bazelrc | ||
| .bazelrc.common | ||
| .bazelversion | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .puppeteerrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| catalog-info.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| nav-kibana-dev.docnav.json | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| run_fleet_setup_parallel.sh | ||
| SECURITY.md | ||
| sonar-project.properties | ||
| STYLEGUIDE.mdx | ||
| tsconfig.base.json | ||
| tsconfig.browser.json | ||
| tsconfig.browser_bazel.json | ||
| tsconfig.json | ||
| TYPESCRIPT.md | ||
| versions.json | ||
| WORKSPACE.bazel | ||
| yarn.lock | ||
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
| Situation | Example Kibana version | Example ES version | Outcome |
|---|---|---|---|
| Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
| ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
| ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
| ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
| ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
| ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
| ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.