## Summary
Fixes https://github.com/elastic/kibana/issues/183607
Adds logic to fix the re-render performance issues caused by the related
integrations component on the rule edit and creation pages. This copies
a strategy used in https://github.com/elastic/kibana/pull/180682 to fix
a similar issue with required fields. Related integrations component now
doesn't re-render when there are updates to components that don't affect
it.
#### React Profile while typing in query field component
### 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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR applies some performance improvements to the newly created Alert
summary page (for AI for SOC).
Here are the multiple changes:
- instead of fetching all rules in multiple places (components and
hooks), we're now fetching all rules in the most top level
`alert_summary.tsx` pages component. We're then passing the result down
via props to the children components. Though some of the components
inside the `alerts_table` component for example cannot be passed via
props, so we're leveraging the `additionalContext` property to pass down
rules information. Also, for the components working within the
`grouping_alerts_table`, we had to wrap the whole component with a local
context.
- similarly, the packages were already fetched in the very top
`alert_summary.tsx` pages component and were passed via props to the
children components, but we applied the same logic for the
`alerts_table` and the `grouping_alerts_table` components.
The PR also improves the `integration_icon.tsx` component to make it
more generic, and reused in all places to avoid the previous code
duplication.
**No UI or behavior changes are introduced!**
https://github.com/user-attachments/assets/1fc1b6d0-290c-4b8e-b3e1-6ccb82f4f82b
## 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`)
- 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] [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
Closes#218063
This PR fixes the broken storybook stories we have for Infra.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
These changes revert accidentally removed attack discovery scheduling
routes registration by this PR
https://github.com/elastic/kibana/pull/218018/files#diff-fc08114e3940ca525cd8a2b7d746786ddabf8d27f8595438cdfc19371ee23831L44
Since the changes from that PR did not go into the `8.19`, we would not
need the backport to that branch.
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
**!!MAJORITY OF THE CHANGED FILES ARE MOVED OR COPIED!!**
### Vision
According to the product vision we will build a new simple UI/UX in the
future https://github.com/elastic/security-team/issues/11790
This PR is a first iteration on enabling Content Connectors Management
UI in Serverless Kibana Stack Management.
Elastic Managed content connectors will be available only for Security
and Observability projects.
### Current PR scope
1. Used initial search_connectors plugin and renamed it to
content_connectors + moved from `x-pack/solutions/search` to
`x-pack/platform/plugins/shared`
2. Copy relevant connectors UI and routes from enterprise_search plugin.
3. Introduce the new Stack Management card/navigation option under the
Data section.
4. Enabled this plugin only in Serverless for Security and Observability
projects.
5. For making PR smaller Pipelines tab was not moved. And according to
Search team vision this functionality should be dropped anyway soon.
6. Extended fleet package logic to include elastic_connectors for
security and o11y serverless projects
7. Added back `search:agentless-connectors-manager` task
In Stack Management navigation:
<img width="2062" alt="Screenshot 2025-04-15 at 3 51 43 PM"
src="https://github.com/user-attachments/assets/5c93ba01-9a6a-4eac-a21d-1370f03b8f35"
/>
Stack Management cards:
<img width="2081" alt="Screenshot 2025-04-10 at 8 41 43 PM"
src="https://github.com/user-attachments/assets/3def1c12-561b-4a84-8241-4dd61cd9313d"
/>
Create Elastic Managed Connector UI (on Agentless):
<img width="1822" alt="Screenshot 2025-04-15 at 3 55 29 PM"
src="https://github.com/user-attachments/assets/6e9fea48-85e7-43df-919d-0e5492d0e704"
/>
Create Self Managed Connector UI:
<img width="2064" alt="Screenshot 2025-04-15 at 3 55 49 PM"
src="https://github.com/user-attachments/assets/d5051898-c8fa-4e41-b9ea-b41d4ed4a0d5"
/>
### Next steps
- [ ] Remove duplicated code between content_connectors,
enterprise_search and serverless_search
- [ ] Extract [common server
libs](https://github.com/elastic/kibana/tree/main/x-pack/solutions/search/plugins/enterprise_search/server/lib)
to the shared package `kbn-search-connectors`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Artem Shelkovnikov <artem.shelkovnikov@elastic.co>
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
## Summary
Alert flyout for AI for the SOC.
<img width="600" alt="Screenshot 2025-04-11 at 12 15 22 PM"
src="https://github.com/user-attachments/assets/fea2f7fb-7424-46b5-b9c2-5cafa336b0a9"
/>
### The flyout sections include:
- New header highlighting the integration source
<img width="596" alt="Screenshot 2025-04-11 at 12 16 00 PM"
src="https://github.com/user-attachments/assets/13033225-9e41-431f-8061-5df96a981665"
/>
- AI generated alert summary generated by button (Generate or
Regenerate). Stored in a new data stream
(`.kibana-elastic-ai-assistant-alert-summary-*`)
<img width="595" alt="Screenshot 2025-04-11 at 12 15 55 PM"
src="https://github.com/user-attachments/assets/ac835db2-2cbb-4a59-9e71-f1a9616a777f"
/>
- Anonymization toggle for the alert summary is located in the flyout
gear settings menu
<img width="270" alt="Screenshot 2025-04-11 at 12 32 45 PM"
src="https://github.com/user-attachments/assets/952936b9-571b-48e5-bd57-ecfd33855df3"
/>
- Highlighted fields
<img width="600" alt="Screenshot 2025-04-11 at 12 15 52 PM"
src="https://github.com/user-attachments/assets/3fccfab2-3e8b-4edc-adaf-3f320d9a5d20"
/>
- Attack discovery `MiniAttackChain` (currently hardcoded to a
preconfigured connector, waiting for further work from @andrew-goldstein
to hook up to actual alert related AD)
<img width="597" alt="Screenshot 2025-04-11 at 12 15 36 PM"
src="https://github.com/user-attachments/assets/d181f68d-5b77-4df4-a316-54e84d655a4c"
/>
- Conversations dropdown that show any conversations this alert is
referenced
<img width="601" alt="Screenshot 2025-04-11 at 12 18 03 PM"
src="https://github.com/user-attachments/assets/71d533d3-99b4-49c4-b336-05152fd64ed4"
/>
- Suggested prompts that create a new conversation with the alert as
context (_copy pending_)
<img width="594" alt="Screenshot 2025-04-11 at 12 18 09 PM"
src="https://github.com/user-attachments/assets/bca58f5a-f05c-4cdf-a466-0926c99e0ad6"
/>
- The connector used in the alert summary generation is selected in
Stack Management > Advanced Settings > Security Solution > Default AI
Connector (_copy pending_)
<img width="1163" alt="Screenshot 2025-04-11 at 12 34 15 PM"
src="https://github.com/user-attachments/assets/d2128497-22e4-4c14-b08c-991dc8287391"
/>
### New prompts
This PR adds 2 new prompts under a new `promptGroupId.aiForSoc`:
- `promptDictionary.alertSummarySystemPrompt`
- `promptDictionary.alertSummary`
In order to access these prompts in the proper spots, the new find alert
summary route returns the "user" prompt
(`promptDictionary.alertSummary`). In order to get the system prompt in
place, we pass a `promptIds` object to the
`POST_ACTIONS_CONNECTOR_EXECUTE` which is appended to the main system
prompt
## Testing
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.yml` 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
With this alerts data, you should be able to test each section of the
flyout _except_ the attack discovery widget, instructions for that are
below.
#### Attack discovery widget
As I am waiting for updates from Andrew, currently the attack discovery
widget looks up attack discoveries from a particular preconfigured
connector. In order to test:
1. Add preconfigured connector to your `kibana.dev.yml`:
https://p.elstc.co/paste/J2qmGMeQ#GKSPhlggX4F93aUSKJsKpsqtCcyTepCkfJOEVxlZyfB
2. Generate attack discovery with this connector
3. Open the new flyout, you will see the attack discovery widget
## Outstanding TODOs
These are all noted in the code
1. Attack discovery widget is hardcoded to the preconfigured connector
id. The widget should instead look up discoveries by alert ID, pending
work from @andrew-goldstein
2. Update copy for suggested prompts
3. Update copy for ai connector UI setting
4. Update AI connector UI setting to default to Elastic Managed LLM once
it is fully available in serverless
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co>
Co-authored-by: Angela Chuang <yi-chun.chuang@elastic.co>
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12006))
These changes add Schedule Details and Editing workflows allowing users
to see schedule information in a separate flyout and/or update the
schedule parameters within it.
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR performs some very minor performance improvements to the
`expandable-flyout` package:
- prevent unnecessary re-renders by extracting styles to const
- better use of `useCallback`
No UI or behavior changes are introduced.
https://github.com/user-attachments/assets/c7f55a4e-7f98-4c18-bb22-f8b81a11e626
## Summary
- Fix https://github.com/elastic/kibana/issues/216044
- Add a new EBT event collecting index template info
```typescript
export interface IndexTemplateInfo {
template_name: string;
index_mode: Nullable<string>;
datastream: boolean;
package_name: Nullable<string>;
managed_by: Nullable<string>;
beat: Nullable<string>;
is_managed: Nullable<boolean>;
composed_of: string[];
source_enabled: Nullable<boolean>;
source_includes: string[];
source_excludes: string[];
}
```
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
**Resolves: https://github.com/elastic/kibana/issues/209000**
**Related PR: https://github.com/elastic/kibana/pull/213750**
## Summary
This PR updates the code to show a promo banner in the rules table. With
this change, this banner will be shown in both ESS (8.18+) and
Serverless. Previously it was shown only in ESS. In both ESS and
Serverless the blog link is the same – this is expected and correct.
We couldn't add a banner for Serverless earlier, because the blog post
was published on the 8.18/9.0 release day. If we would have added it
earlier, Serverless users would click on a link at get a 404 page.
Expected behaviour for both ESS and Serverless:
- Banner is visible above the rules table
- The link leads to
https://www.elastic.co/blog/security-prebuilt-rules-editing
<img width="1006" alt="Schermafbeelding 2025-03-11 om 12 25 45"
src="https://github.com/user-attachments/assets/41d83db9-4bc4-433e-a7e2-c5ef1049a20c"
/>
**Changes:**
- Adds a rule management table banner to promote prebuilt rule
customization in Serverless. Previously this banner was only shown in
ESS. Banner is dismissible. Its state is stored in localStorage.
- Tweaks banner wording a bit as per docs suggestion
([comment](https://github.com/elastic/kibana/pull/213750/files#r1989313701))
For the embeddable waterfall to be successful, we want to remove
unnecessary information and be able to select which records should be
displayed.
We need to remove:
- Accordions
- Services Legend
We want to display (or hide anything that isn't):
- root,
- direct parent,
- current span or transaction (highlighted)
- up to 2 children.
- Errors will be represented with an icon in the embeddable form of the
waterfall and the badge in the regular form
https://github.com/user-attachments/assets/bf8d34d7-173c-4a1a-8ccf-2f98f43fc625
## Using the embeddable:
1: Loads standard trace waterfall (like the one on APM UI)
```
<ReactEmbeddableRenderer
type="APM_TRACE_WATERFALL_EMBEDDABLE"
getParentApi={() => ({
getSerializedStateForChild: () => ({
rawState: {
serviceName: 'foo',
traceId: 'e7b9d541fae0e25106291f7ac0947acd',
entryTransactionId: '2d94d9d4fda31c18',
rangeFrom: '2025-03-26T00:00:00.513Z',
rangeTo: '2025-03-26T20:52:42.513Z',
displayLimit: 5, //optional param when omitted it renders the entire waterfall
},
}),
})}
hidePanelChrome={true}
/>
```
2: Loads focused trace waterfall (some trace events are hidden and a
summary is available)
```
<ReactEmbeddableRenderer
type="APM_TRACE_WATERFALL_EMBEDDABLE"
getParentApi={() => ({
getSerializedStateForChild: () => ({
rawState: {
traceId: 'e7b9d541fae0e25106291f7ac0947acd',
rangeFrom: '2025-03-26T00:00:00.513Z',
rangeTo: '2025-03-26T20:52:42.513Z',
docId: SPAN_OR_TRANSACTION_ID
},
}),
})}
hidePanelChrome={true}
/>
```
## Summary
After #217202 and #217034 this the another attempt with `lodash` and
`lodash/fp`.
In short:
`lodash` and `lodash/fp` have a special webpack treatment as they are
imported within the shared bundle.
Now webpack is not smart enough to understand that `import camelCase
from 'lodash/camelCase';` is still pointing to `lodash` and it thinks
that `lodash/camelCase` is a different package, de-optimizing the
bundling caching system.
So I’ve tweaked the import to make it point to the shared bundle and
save few kbs here and there
## Summary
Pre-requisite for https://github.com/elastic/kibana/pull/216088, as the
`AI Assistant Management` configuration settings should be available for
Search too.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Hides security sub-privileges for ai4soc/search_ai_lake tier.
### Reasoning for changes added to `x-pack/packages/security`:
Currently, the feature description of Security feature is tied to the
fact that it has a list of sub-privileges. This is true on ESS and
`essentials/complete` serverless tiers.
With the introduction of the lower `search_ai_lake` tier, security
feature would not have any sub-privileges available and thus it does not
make sense to show that description.
The ideal way to handle this would be to load feature privileges config
settings at the plugin level
(security_solution/security_solution_serverless) and set `description`
to `null | undefined` based on the tier, as currently the feature
privileges settings live in [kibana_features file
(v2_features)](795094d8c6/x-pack/solutions/security/packages/features/src/security/v2_features/kibana_features.ts (L72))
(also another set in v1_features) and the plugins only select a set of
those based on the [feature keys
available](d4a33a2b61/x-pack/solutions/security/plugins/security_solution_serverless/common/pli/pli_config.ts)
on each tier. The refactoring to pass in feature configs at the plugin
level (instead of just feature keys) is not in the scope of the work cut
out for RSA conf.
Thus the other simpler approach in this PR is to allow overriding the
description field on the tier specific config file.
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` category and verify that `Security` feature is
listed in the list of features.
6. Also verify that there is neither an accordion icon beside `Security`
feature nor a description text under it about sub-privileges.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] 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)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
## Summary
Just had some fun and made fp-ts available in the shared bundle, with
support for partial imports.
Changes in this PR:
* aligned `fp-ts` direct imports to the format: `fp-ts/<module>`
* Mapped the direct imports into the shared bundle re-using the same
`fp-ts` module under the hood
Closes#213943
## Summary
This PR ensures the service name is always encoded in the APM UIs. It's
a follow-up of https://github.com/elastic/kibana/pull/215031 and aims to
find a better solution to the problem:
- Add the encoding directly to `formatRequest` as suggested there
- I saw that there are many places where we use legacy Url builders, so
I will try to replace them where possible and use
apm router link method where the path is encoded
([ref](7158e0201b/src/platform/packages/shared/kbn-typed-react-router-config/src/create_router.ts (L184-L185)))
- The PR includes the changes to address the issue above:
- Replaced and removed `LegacyAPMLink`
- Refactored `useAPMHref` to support encoding (and extracted and test
the encoding logic)
- Example usage:
- Before:
```js
useAPMHref({
path: `/services/${serviceName}/.....`,
persistedFilters,
});
```
- After:
```js
useAPMHref({
path: '/services/{serviceName}/.......}',
pathParams: { serviceName },
persistedFilters,
});
```
- Used the APM router link method as much as possible
## Testing
- Run `node scripts/synthtrace trace_with_service_names_with_slashes.ts
--clean --live --uniqueIds --live`
- Go to service inventory and click the links:
https://github.com/user-attachments/assets/fcd4fbfc-4125-4cc8-9b00-53c5f375423f
## Summary
Redo of https://github.com/elastic/kibana/pull/193471
Closes https://github.com/elastic/security-team/issues/8644
> Fixes a bug where importing a rule fails with a connector into a space
where (1) the connector already exists, and (2) the existing connector
was exported and re-imported from another space. The import logic in
this scenario effectively tries to convert the action ID on the rule
import twice. The second conversion attempt tries to use the old action
ID to look up the correct new action ID in a map, however, in this test
scenario the action ID has already been updated by legacy SO ID
migration logic and there is no map entry with the new ID as a key. The
result is that the second attempt sets the action ID to undefined,
resulting in an import failure.
The root cause of the bug is that we have two different places in the
rule import logic where action IDs are migrated. The first ID migration
was done by `migrateLegacyActionsIds` prior to importing rule actions,
and the second migration was done by `importRuleActionConnectors` after
importing the actions. `importRuleActionConnectors` used a lookup table
to convert old IDs to new IDs, but if the connector already existed and
had an `originId` then the rule action would already be migrated by
`migrateLegacyActionsIds`. The lookup table used by
`importRuleActionConnectors` does not have entries for migrated IDs,
only the original IDs, so in that case the result of the lookup is
`undefined` which we assign to the action ID.
This PR reworks the logic to create a clean separation between action
and rule import. We now import the connectors first, ignoring the rules,
then migrate action IDs on the rules afterwards. This handles connectors
changing IDs in any way, either through the 7.x->8.0 migration long ago
or IDs changing on import if there are ID conflicts. Only after the
connectors are imported and rule actions are migrated do we then verify
if each rule action references a connector ID that actually exists with
the new `checkRuleActions` function, replacing
`checkIfActionsHaveMissingConnectors` and related functions that were
also buggy.
Finally, as a nice side effect this rework removes "rule action
connector missing" errors out of the `action_connector_errors` part of
the response. `action_connector_errors` is reserved for errors importing
connectors specifically. If a rule action is missing a connector and
therefore we don't import the rule, that's a rule error and it's
represented in the `errors` part of the response. Since the shape of the
response is not changing, I don't consider this a breaking change but
rather a bug fix.
## Repro Steps
Repro Steps
1. Download the export file below and change the extension back to
.ndjson from .json (github does not allow .ndjson files
[rules_export.json](https://github.com/user-attachments/files/17065272/rules_export.json)
2. Import the rule and connector into a space (default is fine)
3. Create a new space
4. Import the rule and connector into the new space
5. Import the rule and connector into the new space again, but check the
`Overwrite existing connectors with conflicting action "id"` box.
Observe the failure.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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"
/>
