## Summary
This pr fixes a bug with the RouteCapture component, used at a high
level in the security solution component tree, to reflect url changes
into redux. The code previously used the full result of
'react-router-dom' 's useLocation hook as the payload, which contains 4
parameters, pathname, search, hash that we make use of, and a 4th that
was added sometime later by the library that is essentially a random id
generated every time the hook is called, called key. We have never used
this, and it was being inadvertently copied into the redux state, and
also causing some other actions or hooks based listeners to run I think
as well.
Below is the contrived example of going from the home page to an empty
alerts page, and you can see 4 actions in the after, and 5 in the
before, with 1 updating only the key. May reduce more unneeded actions
with more going on in the page, but exactly how many is not known.
Before:
After:
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
New event created for the video selectors inside rules, dashboards and
alerts cards.
```
export interface OnboardingHubSelectorCardClickedParams {
originStepId: string;
selectorId: string;
}
```
To verify:
Add these lines to kibana.dev.yml
```
logging.browser.root.level: debug
telemetry.optIn: true
```
1. In the onboarding hub, expand the rules card
2. It should log `Report event "Onboarding Hub Step Selector Clicked"`.
https://github.com/user-attachments/assets/c1b1084e-4917-4412-93ed-984a74b6b6b4
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds support for disabling experimental features using the
existing `xpack.securitySolution.enableExperimental` configuration.
This solves the problem of not being able to disable a feature by config
once the feature has been enabled by default.
### The Challenge
When we start developing a feature under an experimental flag we always
follow the same steps:
1 - Create the experimental flag disabled by default + enable it via
config for testing
2 - Implement the feature
3 - Enable the experimental flag by default when we want to release the
feature.
4 - Deployments can disable the feature via config (as a safety
measure).
5 - Remove the experimental flag after some time.
We start by creating the flag disabled by default while we implement it.
In `experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureEnabled: false,
[...]
```
And enable it via config with:
```yml
xpack.securitySolution.enableExperimental:
- myFeatureEnabled
```
Once the implementation is done and the experimental flag can be enabled
by default, we have to do a trick:
Since the `xpack.securitySolution.enableExperimental` config can only
turn flags to _true_, instead of setting `myFeatureEnabled: true`, what
we have to do is rename the flag to `myFeatureDisabled` and keep the
value as _false_:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureDisabled: false,
[...]
```
Then we also need to do a code refactor to update all the places in the
code where the flag was checked: `if (myFeatureEnabled)` -> `if
(!myFeatureDisabled)`
This way, we have the option of disabling the feature via config (in
case something goes wrong):
```yml
xpack.securitySolution.enableExperimental:
- myFeatureDisabled
```
### A solution
This PR introduces the possibility to turn a flag to _false_ using the
same `xpack.securitySolution.enableExperimental` config. This was
preferable to introducing a new config since this one is already
whitelisted in Cloud UI, can be easily overritten in deployments, and
also because people are used to it.
With these changes, the first two steps would be the same, with the
difference that we won't need to have the _Enabled_ or _Disabled_ word
at the end of the flag name. It could be just the feature name, in
`experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: false,
[...]
```
And when we need to enable the feature by default, we can just turn it
to `true`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: true,
[...]
```
No tedious refactor or confusing naming would be required.
Then, in case we need to disable the feature in a production deployment
for some reason, we could just do this via config :
```yml
xpack.securitySolution.enableExperimental:
- disable:myFeature
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/208025
This change deleted the "Stream log files" onboarding flow which is now
replaced by the Auto Detect flow.
| Before | After |
| --- | --- |
| 
| 
|
Changes made:
* Deleted UI components responsible for rendering the Custom Logs flow
* Deleted the definition for a custom card in the onboarding search
results
* Deleted API endpoints and supporting files used only by the Custom
Logs flow
* `/internal/observability_onboarding/logs/setup/environment` endpoint
was still used by the OTel Host flow, so it was moved to a dedicated
OTel route and pathname changed to
`/internal/observability_onboarding/otel_host/setup`
* Functionality of the `/internal/observability_onboarding/otel/api_key`
endpoint was merged into the above mentioned OTel route, so UI has to
make a single API request to get all the necessary information from the
server
* Deleted Scout UI tests for the Custom Logs flow
* Deleted API integration tests for the deleted endpoints
* API tests that we previously testing
`/internal/observability_onboarding/logs/flow` were converted to test
`/internal/observability_onboarding/flow'` used by the Auto Detect flow
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes the issue with the error summary missing items using edot.
It includes e2e tests with synthtrace for both edot and otel services.
TODO
- [x] Test with serverless (waiting for the PR to be deployed)
Tested on serverless works as expected:
<img width="2560" alt="image"
src="https://github.com/user-attachments/assets/8dd7962e-7d66-482d-97fb-0b08882bd04f"
/>
Allow group by for ip fields !!
---------
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/217923
Investigations in https://github.com/elastic/kibana/issues/217368 showed
that there was basically no performance impact to passing the AST across
a thread boundary. But we also didn't detect a pressing reason to remove
the worker.
Since then, however, we noticed another cost associated with the worker:
it's a hefty Javascript file, even in production builds. In addition, we
are doing parsing on the main thread _and_ the worker, so the
`kbn-esql-ast` package is actually being loaded and parsed twice by the
browser, once for the main thread and once for the worker.
This PR removes our worker. Our parsing associated with validation and
autocomplete will still be done asynchronously, but on the main thread.
I do not see any regression in perceived performance.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
This PR closes#215668.
The global parameters are synched in the endpoints where they are
created, edited or deleted.
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12007))
These changes add the attack discovery schedules management table.
https://github.com/user-attachments/assets/619ad1d6-d919-4a8d-b743-6a73fbfbf318
## Key changes
* UI side API handlers
* Create schedule workflow
* Schedules table
* Enable schedule from the table
* Disable schedule from the table
* Delete schedule from the table
* Pagination and sorting in find schedules API
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
## Summary
This PR better separates the request building logic in the detection
engine from query building logic, removes outdated error checking logic,
updates the `singleSearchAfter` `search` call to no longer use the
legacy `meta: true` param, and improves search response type inference.
## Summary
This PR makes sure a buggy `security_detection_engine` package doesn't affect a preview installation endpoint. Older security detection rules package versions contain saved object rule duplicates affecting the endpoint.
Having `security_detection_engine` v`8.17.1` package installed `/internal/detection_engine/prebuilt_rules/status` and `/internal/detection_engine/prebuilt_rules/installation/_review` endpoints return a different number of rules available to install.
## Details
Older `security_detection_engine` package versions contain rule saved objects duplicates representing the latest version. For example, `8.17.1` version has a rule `Microsoft 365 User Restricted from Sending Email` with `rule_id` = `0136b315-b566-482f-866c-1d8e2477ba16` and the latest version `206`. Since a package may contain multiple historical rule versions it sticks to the following format `<rule_id>_<version>` where `<rule_id>` is the unique rule's UUID and `<version>` it's version. Some older package versions omit `<version>` for the latest rule version. `Microsoft 365 User Restricted from Sending Email` rule mentioned above has two equal assets corresponding to the latest version with the only difference in the saved object id `0136b315-b566-482f-866c-1d8e2477ba16` and `0136b315-b566-482f-866c-1d8e2477ba16_206`.
Prebuilt rules preview endpoint was designed to handle `<rule_id>_<version>` format only. Consequently, it improperly handles older prebuilt rules package version.
This bug manifested in https://github.com/elastic/kibana/pull/217544 where `security_detection_engine` version has been bumped to `8.18.1`. It resulted in a failed integration test. Further investigation has shown that the test installs an older package version `8.17.1` to assert prebuilt rules upgrade workflow works correctly.
The fix is implemented in `PrebuiltRuleAssetsClient.fetchAssetsByVersion()` by using `Map` to deduplicate prebuilt rule assets.
## Summary
Follow-up to #217153
### Problem Description
In UI tests, there was no reliable way to determine when the Alerts
table content had fully loaded before interacting with it. This could
lead to flaky tests where interactions occurred before the data was
available (rows are not present yet), causing failures or inconsistent
results (checking for row with specific content to exist)
Quite often we see tests waiting for global indicator (spinner in the
top left corner) to be hidden as a condition for page loading is
complete. This is quite unreliable approach and testing tools have no
consistent built-in solution: FTR, Cypress or even Playwright - network
idle wait is officially marked as
[discouraged](https://playwright.dev/docs/api/class-page)).
We need to help testing tool to interact with UI components in ready
state only.
### Solution
To address this issue, I modified a `data-test-subj` property in the
`<EuiDataGrid>` component. The property dynamically switches between
`alertsTableIsLoading` when data is still loading and
`alertsTableIsLoaded `once the content is available. This allows UI
tests to wait for precisely `alertsTableIsLoaded` to be in in the DOM
before interacting with the table, ensuring more reliable and stable
test execution.
Passed 10/10
<img width="538" alt="image"
src="https://github.com/user-attachments/assets/e44bae5f-4094-4ed2-89f3-74a52cb2be53"
/>
fixes [#189213](https://github.com/elastic/kibana/issues/189213)
## Summary
Checks whether the user has permission to ML before triggering requests
to fetch ML data
### How to test
- Create a user whose role doesn't have permission to ML, but has
permission to O11y apps
- Run `node scripts/synthtrace infra_hosts_with_apm_hosts --live
--clean`
- Navigate to Inventory Infrastructure / Hosts View
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Introduce a new Entity Engine Definition called Generic. The larger
context on why we are introducing a new entity definition is described
on this [private github
issue](https://github.com/elastic/security-team/issues/11857).
The tldr; is that we would like to have an entity store with all the
entities described by the [entity ecs
field](https://github.com/elastic/security-team/issues/11857). The
decision to call `generic` entity definition comes from the fact that
any entity can be described with the `entity` field - user, host,
service, database, queue, subscription and so on. Therefore it makes
sense to have the concept called `generic` entity, meanwhile the
existent entity definitions will be called concrete entities, because
they describe a very concrete type of entity (currently user, host,
service).
Other changes included on this PR:
- Don't override `entity.name` with `entity.id`, only set if no value is
found
- Migrate the usage of `entity.type` as the entity definition type to
`entity.EngineMetadata.Type`
- Changes touching Entity Analytics code around
`getRiskEngineEntityTypes` and `getAssetCriticalityEntityTypes`. There
was a somewhat unnecessary and duplicated logic in these functions which
essentially described the concrete entity definitions to be used by
entity analytics flows. A new function called
`getEntityAnalyticsEntityTypes` was introduced which unifies this logic
and returns the entity types that Entity Analytics care about.
Video of a scroll through the entities processed by the generic entity
store, source of the data is cloudbeat asset management integration.
https://github.com/user-attachments/assets/450afd05-dee0-4449-aaec-2cd69645d6ec
#### How to test:
- In Advanced Settings (`/app/management/kibana/settings`), enable
`securitySolution:enableAssetInventory`
<img width="883" alt="image"
src="https://github.com/user-attachments/assets/c342abb2-efb3-40a8-b945-d9558f085f34"
/>
- In Entity Store management (`/security/entity_analytics_entity_store`)
enable entity store
<img width="1251" alt="image"
src="https://github.com/user-attachments/assets/41f709e1-0aea-47dc-9c98-ffaebf18fdb1"
/>
- Verify Generic Engine Status
<img width="1203" alt="image"
src="https://github.com/user-attachments/assets/d26b764a-4695-436e-85f7-e3ed7df5a3be"
/>
- Ingest documents with `entity.id` and `entity.*` fields. Personally I
run `cloudbeat` asset discovery locally
- Verify ingested documents in
`.entities.v1.latest.security_generic_default`
<img width="1496" alt="image"
src="https://github.com/user-attachments/assets/88286cb9-38c1-4f9d-83a7-57ba33811c60"
/>
--
**OBS: Also test enabling the store without the uiSetting enabled, so
you can make sure that it doesn't enable**
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [x] I see risk on performance, given the amount of aggregations the
generated transform does
- tested, although we see a higher spike in CPU than before, it's behind
a feature flag and it's going to be used in controlled data sets (entity
centric logs that contain `entity.id` field) we decided it's good enough
to go.
- [ ] Enablement/disablement of entity store in a different uiSetting
configuration.
- [ ] Enable entity store with `securitySolution:enableAssetInventory`
disabled. Then enable `securitySolution:enableAssetInventory` ==> No
generic entity definition installed. You can manually install it in the
EntityStore status page
- [ ] Enable entity store with `securitySolution:enableAssetInventory`
enabled. Then disable `securitySolution:enableAssetInventory` definition
==> hanging assets of generic entity store that can be deleted manually
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds some alert actions to the AI for SOC alert summary page:
- table row action via a more actions icon button, to allow users to add
the alert to a new case, an existing case, or to apply tags to the
current alert
- a take action in the footer of the flyout, to allow the user to
perform the same actions
Table row actions:
https://github.com/user-attachments/assets/a5991ec0-a1c1-4c8f-821a-5adedd3d68a7
Flyout footer actions:
https://github.com/user-attachments/assets/f5d853d3-8b5e-47f8-ba30-33cdf440651b
### Notes
The code is extremely similar between the 2 components added in this PR.
The difference between the 2 is the type of button that is used to open
the popover.
I debated 2 others approaches, but was not happy with either:
- create a hook that would return the items and panels for cases and
tags, then use that hook to limit the amount of duplicated code in both
components. I decided against this as I hate having hooks that return
components (in this case `EuiContextMenuItems`...
- create a shared component that would do the logic and have some props
to conditionally decide how the button is being displayed. Here also, I
decided against this approach because I feel like components that allow
these sort of UI customization quickly end up hard to maintain, because
we want to change the text, then the color of the button, then the type
of icon...
If you feel strongly about the choice I made here, let me know and I'll
reconsider the approach! 😄
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
Then:
- generate data: `yarn test:generate:serverless-dev`
- create 4 catch all rules, each with a name of a AI for SOC integration
(`google_secops`, `microsoft_sentinel`,, `sentinel_one` and
`crowdstrike`) => to do that you'll need to temporary comment the
`serverless.security.dev.yaml` config changes as the rules page is not
accessible in AI for SOC.
- change [this
line](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/detections/hooks/alert_summary/use_fetch_integrations.ts#L73)
to `installedPackages: availablePackages` to force having some packages
installed
- change [this
line](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/detections/hooks/alert_summary/use_integrations.ts#L63)
to `r.name === p.name` to make sure there will be matches between
integrations and rules
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
https://github.com/elastic/security-team/issues/11973
**Resolves: https://github.com/elastic/security-team/issues/7216**
## Summary
This PR updates the Endpoint policy callback to:
- **Install only the Elastic Defend rule if it's missing**, without
upgrading it to the latest version. Previously, the rule was both
installed and updated whenever an Endpoint policy was created, which
conflicted with rule customization. Automatic upgrades could erase
existing user customizations.
- **Avoid triggering the installation or upgrade of any other prebuilt
rules** as part of this flow. The Endpoint package policy creation
callback
([source](f7d8bc3c25/x-pack/solutions/security/plugins/security_solution/server/fleet_integration/fleet_integration.ts (L181-L187)))
previously installed and upgraded **all** prebuilt detection rules to
their target versions whenever an Endpoint policy was created.
This logic relied on the legacy rule upgrade method, which has a known
issue that causes all configured rule actions and exceptions to be lost.
By removing the upgrade logic, this PR eliminates that incorrect
behavior.
## Summary
This PR fixes the existing usage of the chart themes by using the
provided `useElasticChartsTheme` hook that is color mode aware and theme
adaptive (borealis/amsterdam)
Some charts where using just the Light theme version or the legacy (aka
amsterdam theme), and I've applied the hook to pick up the correct
theme.
TO REVIEWERS: Please pull down the PR and check if the actual changed
charts looks correct with the new theme configuration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
## Summary
Discover Data View picker has the ability to indicate whether or not the
DV is "managed", meaning - owned by the app,
where modifications done by the user are preceeded with a warning (when
changing the index pattern).
This PR filters some of the data views we know should be managed
(currently the default security one), and passes them to the Data View
Picker in a way that renders the following label next to the data view
in the dropdown:
<img width="1134" alt="Screenshot 2025-04-03 at 09 42 42"
src="https://github.com/user-attachments/assets/825dd98b-b54b-4ba5-9f2c-014ad35357be"
/>
## Testing
Add the following feature flag to your configuration:
`xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']`
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
Partially address https://github.com/elastic/kibana/issues/216459
This PR adds `@emotion/babel-preset-css-prop` to jest config to improve
jest and emotion integration. There are some tradeoffs: this is a better
setup for emotion + testing library, but there are some seemingly
regressions for enzyme. We think these are right tradeoffs to make,
since we optimize for emotion+testing library.
### Main upsides are 😄
#### 🟢 Fixes snapshots with css prop
`You have tried to stringify object returned from \`css\` function. It
isn't supposed to be used directly (e.g. as value of the \`className\`
prop), but rather handed to emotion so it can handle it (e.g. as value
of \`css\` prop).` is replaced with proper emotion css classname.
#### 🟢 We will be able to use jest style matchers for emotion
`toHaveStyleRule`
https://emotion.sh/docs/@emotion/jest#tohavestylerule
_they can be used locally now, but we plan to follow up with global
extend_
### Considerations 🫤
#### 🟡 jsx doesn't work inside jest.mock function
Example:
```
jest.mock('./components/alert_header_title', () => ({
> 27 | AlertHeaderTitle: jest.fn().mockReturnValue(<div></div>),
| ^
28 | }));
```
Fails with an error. `can't read jsx of undefined`.
This is because babel compiles this into:
```
import { jsx as ___EmotionJSX } from '@emotion/react'
jest.mock('./components/alert_header_title', () => ({
> 27 | AlertHeaderTitle: jest.fn().mockReturnValue(___EmotionJSX.jsx(….)),
| ^
28 | }));
```
And, apparently, due to how jest imports work, __EmotionJSX is not yet
in the scope.
The applied workaround is to rewrite to:
```
jest.mock('./components/alert_header_title', () => ({
AlertHeaderTitle: jest.fn(() => <div></div>),
}));
```
#### 🟡 euiTheme needs to be available when euiTheme is accessed inside
`css` function
Example:
```
DashboardGrid removes panel when removed from container
TypeError: Cannot read properties of undefined (reading 'size')
42 | margin: '-2px',
43 | position: 'absolute',
> 44 | width: euiTheme.size.l,
```
The fix was to wrap failing tests with `<EuiProvider/>`
### Drawbacks 😢
Mostly related to Enzyme
#### 🔴 Enzyme shallow snapshot no longer include `css` prop
Since `css` prop is compiled away there are bunch of snapshots that
looks like a regression:
Example:
This is unfortunate. We've tried `@emotion/jest/enzyme-serializer` but
it didn't work (likely because enzyme ecosystem no longer supported?)
If it is important that the snapshot captures css, we recommend to use
mount or rtl
#### 🔴 Asserting against `css` prop with shallow render also doesn't
work
Possible solution is to use
```
import { matchers } from '@emotion/jest';
expect.extend(matchers);
```
(We plan to add these matches globally in a follow up)
and
```
expect(button).toHaveStyleRule('background-color', '#FFFFFF');
```
#### 🔴 Some shallow Enzyme tests `find()` breaks because of code
transformations of emotion
Example:
```
const component = shallow(
<MetricVisValue />
)
component.find('button') // fails because instead of <button/> there is <EmotionInternalCss/> element now
```
Solutions:
- Use full mount or react testing library
- Or target by data-test-subj
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Karen Grigoryan <karen.grigoryan@elastic.co>
## Summary
Bootstrap the initial page structure for Privileges User Monitoring
Onboarding Workflow
### What's included
* Create Entity Analytics Page
* Create Privileged User Monitoring Page
* Add the pages to the SecuritySolution and the global menu
* Hide the page when the experimental flag is disabled
`privilegeMonitoringEnabled`
### What's not included
* The content of the Entity Analytics and Privileged User Monitoring
pages
### Answered Questions
* The path `entity_analytics` has already been taken. I chose
`entity_analytics_landing`
* Should the link show up on the global EA page? Yes
* Navigation Menu for ESS? Good for now
* Which permission/capabilities are required? Same as risk engine
### How to test it?
* You only need to run Kibana and check if the navigation item is in the
menu
* The page should show up on the global nav
* The page should show up on the global search bar
* Visibility constraints
* It should be hidden when `privilegeMonitoringEnabled` is not enabled
* It should be visible when the user has access to the entity analytics
feature
* It should be visible for platinum users
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
This PR introduces the first building blocks for the [Entity Analytics
Privileged
Monitoring](https://github.com/elastic/security-team/issues/9971).
We follow the approach used in the Entity Store and add a new "Engine",
which consists of the following components:
* Public API
* INIT and HEALTH routes
* Kibana task
* Privilege Monitoring Data Client
* Engine Saved Object
* API key manager
* Related storage indices
* Feature Flag: `privilegeMonitoringEnabled` set to `false` by default.
* API integration test configuration
* only tests that the health endpoint is available
* Auditing and Telemetry
## Testing steps
1. Make sure to add `privilegeMonitoringEnabled` to your
`kibana.dev.yaml`
2. In devtools, ensure the API is working with `GET
kbn:/api/entity_analytics/monitoring/privileges/health`
3. Start the engine with: `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Look for `DEBUG` logs mentioning the
`entity_analytics:monitoring:privileges:engine` task
---------
Co-authored-by: CAWilson94 <charlotte.wilson@elastic.co>
Co-authored-by: Charlotte Alexandra Wilson <CAWilson94@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Fix a bug that was causing failing tool invocations to not being
persisted to the conversation history, corrupting the conversation for
following rounds.
- Optimize the researcher's prompts (leading to ~50% latency cut, mostly
on the summarization step)
## Summary
Renaming types and files as well as moving providers around to make
implmentating saved playground routes more straightforward. Naming
updates to reduce future confusion from generic names that didn't fit
when there are multiple providers etc.
## Summary
Changes the DashboardStart server api to provide a getContentClient
function.
In https://github.com/elastic/kibana/pull/214788, we set the
`contentClient` returned from the content management register method
after start lifecycle of all plugins. This means the `contentClient`
returned from the `DashboardStart` contract was undefined. This PR
changes the start contract to provide a getContentClient function
instead.
Only one consumer was using the contentClient from DashboardStart and
this PR also updates that consumer.
## Summary
Implements the m1 design for the chat page and components
*Note: only covers the parts that are functionally present in the app
atm*
### Design demo
https://github.com/user-attachments/assets/16f64a51-16ad-45c5-9d4b-77c31598427a
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
