## Summary
Just naming things, the goal is to highlight the fact the hook returns
the spec and not the DataView instance.
No testing is required as the change does not alter the logic.
## Summary
- addresses https://github.com/elastic/security-team/issues/12000
- adds telemetry for rules in spaces:
- number of spaces, detection rules added
- number of rules in each space
---------
Co-authored-by: Dan Dillinger <ddillinger@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/192154
In the Fleet agent details view the last activity row shows the relative
time since the last report from an agent. This value is not as useful if
a user needs to debug why an agent is no longer reporting. Additionally,
the text content in the integration inputs are not selectable and
copyable.
* Changes the agent details last activity value to show the formatted
datetime.
* The text for integration inputs in agent details is now selectable and
copyable.
**Resolves: https://github.com/elastic/security-docs/issues/3545**
## Summary
I am fixing documentation for the version and revision fields.
I used this page as the base documentation:
https://docs.elastic.dev/security-solution/dev-docs/detections/rule-versions
The changes:
- by marking the RuleVersion as read-only I am making sure we are
properly documenting that this field is not to be used in the request.
It is only returned in the response.
- by introducing RuleRevision type and marking it as read-only, I am
doing the same for this field, saying that this field is not supposed to
be used in the request.
- I am not changing any code in the app, as the ticket says we shouldn't
do any breaking changes and the update of the version should not cause
400 error. Basically current behavior is kept: users can still update
the version to whatever value they want, including going backwards, and
the changes to revision field is completely ignored.
- I am adding a condensed description of these fields.
I wanted to introduce an internal link between these two fields, but I
couldn't make it work in Bump.sh (even though this should work, normal
Markdown links) so I abandoned this idea.
You can also use this [link](https://bump.sh/jkelas2/doc/kibana_wip2)
where I deployed the generated bundled doc.
Screenshots:
<img width="664" alt="image"
src="https://github.com/user-attachments/assets/34d82eb2-f7f0-4369-ad8e-2fd3c1f35447"
/>
<img width="660" alt="image"
src="https://github.com/user-attachments/assets/dc7772af-0185-4850-816e-60be003775d6"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/202092
Depends on:
- https://github.com/elastic/kibana/pull/213212
- https://github.com/elastic/kibana/pull/215963
- https://github.com/elastic/kibana/pull/216354
Add a "Group by" menu dropdown on the right side of the data grid to
render rows grouped recursively with a maximum of 3 group levels i.e.
entities grouped by type (1), category (2), risk(3). It supports
grouping by custom fields as in Findings.
Pagination state of each recursive group is kept locally, while the
top-level group's pagination is kept in the URL query-string. This is to
preserve consistency with the data-table's pagination state which is
also kept in the URL.
### Component hierarchy
<img width="1389" alt="Screenshot 2025-03-28 at 16 00 31"
src="https://github.com/user-attachments/assets/d4c30849-5d76-4589-867f-718847e11e8b"
/>
### Screenshots
<details><summary>TBD Menu Dropdown</summary>
</details>
<details><summary>Group by none</summary>
<img width="1374" alt="Screenshot 2025-03-26 at 17 00 58"
src="https://github.com/user-attachments/assets/5b319f7b-d63a-4bce-bf24-15549cda254d"
/>
</details>
<details><summary>TBD Group by entity type</summary>
</details>
<details><summary>TBD Group by source</summary>
</details>
<details><summary>TBD Group by entity type, then source</summary>
</details>
<details><summary>TBD Group by source, then entity type</summary>
</details>
<details><summary>TBD Group by cloud account</summary>
</details>
<details><summary>Group by custom field (entity.id)</summary>
<img width="1348" alt="Screenshot 2025-03-26 at 17 02 45"
src="https://github.com/user-attachments/assets/46dc1f25-2bd4-4571-888d-5becf011b7c6"
/>
</details>
> [!IMPORTANT]
> We can't group by asset criticality at the moment because the field is
not present in the current dataset.
<details><summary>TBD Group by asset criticality</summary>
</details>
### Definition of done
- [x] Add a toggle to switch between **DataGrid** and **Group by View**
visualizations.
- [x] Implement the **Group by View** using the `@kbn/grouping` package
for consistency and reusability.
- [x] Provide a dropdown menu to select grouping fields, including:
(updated as per [this
epic](https://github.com/elastic/security-team/issues/10344))
- ~~**Asset type (asset.type)**~~ -> **Asset criticality
(asset.criticality)**
- ~~**Asset category (asset.category)**~~ -> **Entity type
(entity.category)**
- ~~**Risk (host.risk.calculated_level)**~~ -> **Cloud account
(cloud.account.id)**
- ~~**Criticality (asset.criticality)**~~ -> **Source (entity.type)**
- **Custom field**: Allow users to input/select a custom field for
grouping.
- [x] Display the following information for each group row:
- The grouped term value.
- The count of assets in that group.
- A button to expand the group and view the assets in a filtered
**DataGrid**.
- [x] Ensure group expansion dynamically displays assets in a DataGrid
filtered by the selected grouping field.
- [x] **Pagination**: Display 10 groups per page by default, with
pagination controls to navigate between pages.
- [x] **Rows per page dropdown**: Allow users to adjust the number of
groups displayed per page (options: 10, 25, 50, 100).
### 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)
- [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.
- [ ] [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)
### Risks
No risk since code is still hidden behind the *Enable Asset Inventory*
advanced setting and the beta *Cloud Asset* integration must be
installed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/194984
This PR uses the `EuiScreenReaderOnly` component to spell out trace per
minute instead of its abbreviation for screen readers
---------
Co-authored-by: jennypavlova <jennypavlova94@gmail.com>
## Summary
During upgrade of ES client in
https://github.com/elastic/kibana/pull/208776, preview logged requests
started to show `index` property in request body.
This PR fixes issue
Closes#214562
## Summary
This PR fixes the issue with the service icons overridden by the merge
of the service stats
## Testing
As this is a bit tricky to test - it needs a bit of refreshing /
changing the time range, etc. to reproduce
The way to verify the fix is to check the service overview - every
service that has an icon there should have an icon in the service
inventory:
https://github.com/user-attachments/assets/e401554b-6a39-440b-a52b-a126e42eacd5
# Unified Data View Picker: Phase 1 Implementation
Part of https://github.com/elastic/security-team/issues/11959
## What This PR Does
This PR represents the first step in our transition from the current
Sourcerer component to the new unified Data View Picker. Specifically,
this implementation:
- Creates a new Data View Picker component
- Implements feature flag protection for all changes
- Handles asynchronous effects through Redux listener middleware
- Establishes a new Redux store architecture to support ad hoc data
views infrastructure
- Utilizes ad hoc data views to handle legacy patterns from series 7
(replacing the previous upgrade data view flow)
See the readme for more info:
```x-pack/solutions/security/plugins/security_solution/public/data_view_manager/readme.md```
## What This PR Does NOT Cover
- Does not affect screens other than Timelines
- Does not modify the existing Sourcerer component in any way
- Does not fully support all URL/local storage patterns
## Implementation Notes
We've made several accommodations to support both Sourcerer and the new Data View Picker simultaneously during this transition period, including:
- Some interfaces might look odd, especially the hooks that return the data view or patterns - this is intentional to support existing use cases
- There are feature flag-based conditional statements throughout the code that will be removed once the transition is complete
## Testing Instructions
1. Add the following feature flag to your configuration:
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
2. Navigate to the Timelines interface
3. Test interactions with the new Data View Picker
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds the KPI charts section to the alert summary page. The 3
charts are similar to the ones in the alerts page, but there are some
subtle differences, which lead to one of them being a separate
component, while the other 2 I was able to reuse the existing components
and just add a property to handle the different logic.
Here are the differences:
- in the AI for SOC we do not (currently) have cell actions, so a
property was added to the charts to be able to hide the cell actions
entirely
- the title of the right chart as well as the fact that it does not have
a dropdown to select the field to group the alerts by meant that a new
component (still using existing child components) was created
The charts react to changes to the KQL bar:
https://github.com/user-attachments/assets/ed0e8f14-ba66-46ae-94df-6c8064c7a648
### Notes
Compared to the mocks (link at the end of the PR description), it was
decided to not add the icons to the left of the next for the middle and
right chart of the KPI section. These might be added in the future, but
there is some complexity related to fetching them (especially for the
alert by host) and more thoughts need to be had to make sure we're
handling all the possible cases.
## 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' },
]
```
And this to generate data: `yarn test:generate:serverless-dev`
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### Notes
You'll need to either have some AI for SOC integrations installed, or
more easily you can:
- change the `alert_summary.tsx` line `38` from `if
(installedPackages.length === 0) {` to `if (installedPackages.length >
0) {` to force the wrapper component to render
- update `42` of the same `alert_summary.tsx` file from `return <Wrapper
packages={installedPackages} />;` to `return <Wrapper
packages={availablePackages} />;` to be able to see some packages
### 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] [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
Mocks:
https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-70999&m=dev
Ticket: https://github.com/elastic/security-team/issues/11958
`100.0.0` ⏩ `101.0.1`
[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)
## Package updates
### `@elastic/eui`
[`v101.0.1`](https://github.com/elastic/eui/releases/v101.0.1)
- Updated `EuiProvider` and `EuiThemeProvider` with a new
`highContrastMode` ([#8444](https://github.com/elastic/eui/pull/8444))
- This prop allows toggling a higher contrast visual style that
primarily affects borders and shadows
- On `EuiProvider`, if the `highContrastMode` prop is not passed, this
setting will inherit from the user's OS/system settings
- If the user is using a forced colors mode (e.g. Windows' high contrast
themes), this system setting will take precedence over any
`highContrastMode` or `colorMode` props passed
- Added `highContrastModeStyles` and `preventForcedColors` styling utils
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated `EuiRangeTooltip` to be easier to see in dark mode
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated some deprecated color token usages that have direct
substitutes ([#8444](https://github.com/elastic/eui/pull/8444))
- `text` -> `textParagraph`
- `title` -> `textHeading`
- `subduedText` -> `textSubdued`
- `disabledText` -> `textDisabled`
- `accentText` -> `textAccent`
- `dangerText` -> `textDanger`
- `warningText` -> `textWarning`
- `useEuiShadow()` now accepts a second `options` argument
([#8234](https://github.com/elastic/eui/pull/8234))
- `useEuiShadowFlat()` now accepts an `options` object instead of only a
color ([#8234](https://github.com/elastic/eui/pull/8234))
- Updated `EuiPopover` and `EuiToolTip` to be easier to see in dark
mode. ([#8174](https://github.com/elastic/eui/pull/8174))
**Bug fixes**
- Fixed a visual bug where a transparent border would create visible
empty space (`LIGHT` mode only) for the components:
([#8427](https://github.com/elastic/eui/pull/8427))
- `EuiPanel`
- `EuiPopover`
- `EuiToolTip`
- `EuiToast`
- `EuiTour`
---
### `@elastic/eui-theme-common`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Removed type `EuiShadowCustomColor`
([#8444](https://github.com/elastic/eui/pull/8444))
- Added types: ([#8444](https://github.com/elastic/eui/pull/8444))
- `EuiShadowOptions`
- `EuiThemeHighContrastModeProp`
- `EuiThemeHighContrastMode`
- Updated shadow utils to accepts a second `options` argument and return
borders in high contrast mode:
([#8444](https://github.com/elastic/eui/pull/8444))
- `euiShadow`
- `euiShadowXSmall`
- `euiShadowSmall`
- `euiShadowMedium`
- `euiShadowLarge`
- `euiSlightShadowHover`
- `euiShadowFlat`
---
### `@elastic/eui-theme-borealis`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Added new component level tokens:
([#8444](https://github.com/elastic/eui/pull/8444))
- `buttonGroupBackgroundDisabledSelected`
- `overlayMaskBackground`
- `overlayMaskBackgroundHighContrast`
- `skeletonBackgroundSkeletonMiddleHighContrast`
## Additional changes
The latest `@elastic/eui` package introduces high contrast mode support.
This PR sets all usages of `EuiProvider` to use
`highContrastMode={false}` to introduce it in disabled state (this
reflects the current functionality in Kibana). This is because the UI
for the high contrast mode functionality (and style adjustments) need to
first be implemented on Kibana side (by shared-ux).
## QA
Adding high contrast mode in disabled state should result in no visual
changes in Kibana. Please ensure your product view remain unchanged.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Another small refactor follow up to
https://github.com/elastic/kibana/pull/212694. Overall, the goal here is
to increase consistency in how security rule executors receive common
parameters. `CreateRuleOptions` contained parameters that were passed in
to every security rule type and sometimes used in the `executor` -
bypassing the executor function's parameters. With this PR, params that
are used across multiple security rule type executors like `licensing`,
`experimentalFeatures`, `scheduleNotificationResponseActionsService`,
etc are all passed through the executor options from the shared security
rule type wrapper.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Enabled @typescript-eslint/consistent-type-imports eslint rule for
ResponseOps packages and plugins:
- this rule ensures that imports used only for type declarations are
consistently written using import type syntax
- fixed type imports in:
- x-pack/platform/plugins/shared/event_log
- x-pack/platform/plugins/shared/rule_registry
- x-pack/platform/plugins/shared/task_manager
- x-pack/solutions/observability/packages/kbn-alerts-grouping
- src/platform/packages/shared/kbn-alerts-ui-shared
- src/platform/packages/shared/kbn-alerting-types
- src/platform/packages/shared/kbn-cases-components
- src/platform/packages/shared/kbn-actions-types
- src/platform/packages/shared/kbn-alerts-as-data-utils
- src/platform/packages/shared/kbn-grouping
- src/platform/packages/shared/kbn-rrule
- src/platform/packages/shared/kbn-rule-data-utils
- src/platform/packages/shared/kbn-triggers-actions-ui-types
- x-pack/platform/packages/shared/kbn-alerting-comparators
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The Risk Summary in the Entity Flyout was displaying an incorrect risk
score due to the space name not being accounted for in the risk score
index query.
This update ensures that the namespace is properly considered while
querying the risk score, providing accurate results across different
spaces.
Screen recording :
https://github.com/user-attachments/assets/91df526c-1c22-4d53-aa0c-d74abb54920a
Testing Steps :
1. Navigate to Entity Risk Score page.
2. Add data in the `default` space
3. Check for Risk score in the Risk Summary for any of the entities in
the Entity Flyout.
4. The Risk score in the Entities table and the flyout should be same
5. Create a new space
6. Add data in the new space
7. Check for Risk score in the Risk Summary for any of the entities in
the Entity Flyout.
8. The Risk score in the Entities table and the flyout should be same
### 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
- [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)
## Summary
This PR adds the SiemSearchBar to the alert summary page. The search bar
is pretty basic: it hides the query menu and the filter buttons to the
left of the query input. Instead, the PR builds a new filter button.
That button lists all the sources available. Sources are basically
equivalent to integrations, or their corresponding rules. It is a
friendly UI name to abstract the concept or a rule.
In the AI for SOC effort, each integration is bundled with a single
rule. This means that deselecting a source from the Source filter button
is equivalent to adding a filter to the search bar to exclude all alerts
with the `kibana.alert.rule.name` property having the value of that
integration.
### Example:
There are following 2 integrations installed:
```typescript
[
{
id: 'splunk',
name: 'splunk',
status: installationStatuses.Installed,
title: 'Splunk',
version: '',
},
{
id: 'google_secops',
name: 'google_secops',
status: installationStatuses.Installed,
title: 'Google SecOps',
version: '',
},
]
```
This means that - in theory - there are the following 2 rules installed
and running:
```typescript
[
{
related_integrations: [{ package: 'splunk' }],
name: 'Splunk Rule',
},
{
related_integrations: [{ package: 'google_secops' }],
name: 'Google SecOps Rule',
},
]
```
In this case, the `Sources` button would show 2 entries, as follow:
```typescript
[
{
checked: 'on',
key: 'Splunk Rule',
label: 'Splunk',
},
{
checked: 'on',
key: 'Google SecOps Rule',
label: 'Splunk',
},
]
```
By default, the `checked` property should be set to `on`. It would be
`off` if a filter for the corresponding `label` existed.
https://github.com/user-attachments/assets/059815d2-9181-4bf1-bd78-e0e5bfa7439dhttps://github.com/user-attachments/assets/126606c7-b4e0-4d0b-82c1-b531c6490de3
## 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' },
]
```
And this to generate data: `yarn test:generate:serverless-dev`
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### Notes
You'll need to either have some AI for SOC integrations installed, or
more easily you can:
- change the `alert_summary.tsx` line `38` from `if
(installedPackages.length === 0) {` to `if (installedPackages.length >
0) {` to force the wrapper component to render
- update `42` of the same `alert_summary.tsx` file from `return <Wrapper
packages={installedPackages} />;` to `return <Wrapper
packages={availablePackages} />;` to be able to see some packages
- comment out line the if condition line `66` of `use_integrations.ts`
file to make sure that values are added even if there is no
`matchingRule`
- replace `const ruleName = changedOption.key;` with `const ruleName =
changedOption.label;` on line `78` of the
`integrations_filter_button.tsx` file
### 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
### Links
Ticket https://github.com/elastic/security-team/issues/11956
Mocks
https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-70999&m=dev
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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
- [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)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR partially solves issue #214346 by adding the KQL Filter when
creating a TLS Alerting Rule.
Because of [the intermediate release
process](https://docs.google.com/document/d/1mU5jlIfCKyXdDPtEzAz1xTpFXFCWxqdO5ldYRVO_hgM/edit?tab=t.0#heading=h.2b1v1tr0ep8m)
the UI to add the new filters is not shown, another PR will enable it
after the next serverless release.
In details:
BE:
- Extended `tlsRuleParamsSchema` to accept `monitorIds`, `locations`,
`tags`, `monitorTypes`, `projects`, `kqlQuery`
- Extended `TLSRuleExecutor` functionality, added tests
- Added new `/internal/synthetics/inspect_tls_rule` endpoint
FE:
- Added `AlertSearchBar`, `FieldFilters` and `TLSRuleViz` to the
`TLSRuleComponent`, making sure that only `http` and `tcp` monitors are
considered
Final result:
https://github.com/user-attachments/assets/613cdb73-2184-4b10-8dd5-549868b7672d
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Closes https://github.com/elastic/kibana/issues/208040
This change adds a new option to ingest APM data using the new managed
OTLP service.
| Classic APM | OTLP |
| --- | --- |
| 
| 
|
## How to test
1. Open Kibana deployed from this PR
2. Go to "Add Data" screen → Application → Open Telemetry
3. Make sure you're redirected to the Open Telemetry instructions in APM
4. Switch to the Managed OTLP option in the second step
5. Make sure `OTEL_EXPORTER_OTLP_ENDPOINT` variable has the new managed
service URL (it should contain `.ingest` subdomain, e.g.
`https://c045db.ingest.us-east-1.aws.elastic.cloud:443`)
6. In order to test the flow end-to-end you need to instrument a sample
application and configure EDOT Collector. As a shortcut, you can use
[this guide](https://github.com/elastic/opentelemetry-dev/issues/557) to
setup sample applications inside Kubernetes pods and then use the
quickstart K8S OTel flow in Kibana to run the EDOT collector but
replacing the endpoint and API key within the snippet to ones provided
by the APM OTel guide.
closes https://github.com/elastic/kibana/issues/215756
Using the new embeddable:
```
<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}
/>
```
**This video is just an example, I did NOT add the embeddable to
Discover in this PR**
https://github.com/user-attachments/assets/c162d47e-a0bc-4327-8f9f-921d07a022fa
## Summary
Main ticket ([internal
link](https://github.com/elastic/security-team/issues/12006))
Filgma link: ([internal
link](https://www.figma.com/design/1AEgYCsQjCsWxAKoErYfL3/9.1-%5BAttack-Discovery%5D-Scheduling-%26-notifications?node-id=3421-195207&t=Y9ejBkDCojHD95qw-4))
With these changes we add create attack discovery schedule flyout.
## Recording
https://github.com/user-attachments/assets/6a1226f2-c45d-4b79-a67d-0e10fac71060
## NOTES
The feature is hidden behind the feature flag:
> xpack.securitySolution.enableExperimental:
['assistantAttackDiscoverySchedulingEnabled']
There is no logic to create actual schedule yet. This will be connected
once https://github.com/elastic/security-team/issues/12003 is done.
For now to see the data returned from the flyout which we gonna use to
create schedule later, you can add console log in
`x-pack/solutions/security/plugins/security_solution/public/attack_discovery/pages/settings_flyout/schedule/hooks/use_edit_form.tsx`
file within the `handleFormSubmit` function to print the `formData`. The
form data from the recording above looks like this:
```json
{
"name": "Schedule 1",
"connectorId": "gemini-1-5-pro",
"alertsSelectionSettings": {
"query": {
"language": "kuery",
"query": ""
},
"filters": [],
"size": 350,
"start": "now-7d",
"end": "now"
},
"interval": "24h",
"actions": [
{
"id": "bb9a46e0-46c1-42c7-b186-ddf3ea6fdf84",
"actionTypeId": ".email",
"group": "default",
"params": {
"message": "Rule {{context.rule.name}} generated {{state.signals_count}} alerts",
"to": [
"test@elastic.co"
],
"subject": "Test email 1"
},
"frequency": {
"notifyWhen": "onActiveAlert",
"throttle": null,
"summary": true
},
"uuid": "78f888f2-aff1-4d34-9ba5-683a6c0d2b5e"
}
]
}
```
### 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] [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
Fixes#210262
This PR adds an `aria-label` to solve the "Select element must have an
accessible name" A11y critical issue.
## How to test
1. Download the [axe
devtools](https://chromewebstore.google.com/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd)
2. Go into a service overview and run the scanner from axe devtools
3. You should see a critical error
4. Checkout this branch
5. Error should be solved
PR reduces unifiedSearch chunks into ui chunk, action chunk, and a
autocomplete chunk.
### Before
<img width="350" alt="Screenshot 2025-03-14 at 8 47 10 AM"
src="https://github.com/user-attachments/assets/f54fe21e-7548-48a1-8874-e36377826701"
/>
### After
The second chunk request is because search bar loads KQL suggestions.
This will be addressed in a follow up PR and the search bar will lazy
load suggestions only when interacted with.
<img width="350" alt="Screenshot 2025-03-14 at 12 56 28 PM"
src="https://github.com/user-attachments/assets/8f23ee56-a57a-489b-aeab-caa30f739d03"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updated fleet custom navigation logic to be more generic and consistent
between security and observability onboarding flows.
## Details
When attempting to start using the custom logic for routing back to
onboarding pages for another project, I noticed inconsistencies in how
we were linking back to the onboarding pages for the `Back to selection`
button on the Integrations overview page and the `Cancel` and `Save and
continue` on the Add integration page. Due to these inconsistencies,
both custom routing mechanisms couldn't both work at the same time. I
re-worked the implementation of the back button to match the cancel/save
buttons and utilize `navigateToApp` to fix.
Now instead of observability utilizing the `observabilityOnboardingLink`
query param, and security utilizing both `observabilityOnboardingLink`
and `onboardingAppId`, both solutions will use `returnAppId` and
`returnPath` (or different names if we don't love these) to route back
to their sourcing locations.
Note: Observability onboarding will also now inherit logic the security
onboarding team added where the same query parameters route back to the
source when a user cancels or saves from the Add integration page (item
3 from [this PR](https://github.com/elastic/kibana/pull/194028))
## Screen recordings
Regular integrations page
https://github.com/user-attachments/assets/0f306bec-657f-4a7a-b2da-25557899b629
Security onboarding
https://github.com/user-attachments/assets/d2a161a0-62ee-40b1-9dd9-5165aea6a65a
Observability onboarding
https://github.com/user-attachments/assets/89f6b9a3-a348-4488-8688-1d5c96716185
Relates:
- https://github.com/elastic/kibana/issues/181520
- https://github.com/elastic/security-team/issues/11789
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/212687
This PR changes the notes behavior so that the maximum allowed count it
100 per document for unassigned notes (notes that do not belong to a
timeline).
## Testing
Just play around with the notes, adding them directly to the alerts in
the alerts table. You can use the script below to add like 99 to observe
the validation behavior that I have changed.
### Performance
This script adds the maximum notes (100) for all the alerts it will find
in the default index. You can modify it freely.
Make sure you have some alerts setup, then use this script to populate
notes for them:
```https://gist.github.com/lgestc/85e8ce315fbd53dd9c87fad715e1cb9e```
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
## Summary
Issue and steps to reproduce:
https://github.com/elastic/kibana/issues/214114https://github.com/user-attachments/assets/881fb082-a879-4816-b251-da3f2af77661
The best approach to fix this is to make local storage keys space aware.
In this use case, the current key is
`elasticAssistantDefault.lastSelectedConversation`.
Ideally it should be e.g.:
`elasticAssistantDefault.lastSelectedConversation.{spaceId}`
To retrieve spaceId properly, we have to make sure spaceId has been
available when reading the local storage. In other words, the spaceId
cannot be null, undefined, or a fallback value when accessing it.
To achieve that, we have to only render the assistant overlay after
spaceId is available and remove existing spaceId from the
AssistantContext. The reason I removed spaceId from AssistantContext is
because it is at the top of the rendering tree and can block the entire
app if waiting for the spaceId becomes available there.
`useAssistantSpaceId` comes from `SpaceIdContext` which should be render
only when spaceId is available, should be safe to access the exact
spaceId inside Assistant overly.
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/208035
> [!IMPORTANT]
> [One of the
changes](https://github.com/elastic/elastic-agent/pull/7063) needed for
the flow to function is not in the Elastic Agent v18.7.3 that is
currently used by Serverless. We need to wait for the next EA release
before merging this PR.
> As a workaround for testing, after running the first code snipped from
the flow, you can modify the generated `./otel.yml` file to add `ApiKey`
in front of the API key and then start the collector.
This change switches OTel Host quickstart flow on Serverless to the
managed OTel collector as the ingest endpoint. Specifically it:
* Uses a modified APM managed service URL as the endpoint. Later the
OTel endpoint will be exposed separately through the Cloud plugin (ref:
https://github.com/elastic/cloud/issues/137354).
* Uses API key generated by APM to access the managed service. This
later will also should be decoupled from APM (ref:
https://github.com/elastic/kibana/issues/208035#issuecomment-2654482081)
* Modifies the code snipped with the new variables
## How to test
* Use the Serverless instance deployed from this PR, make sure OTel Host
flow code snippet uses the managed service endpoint, ingest logs from
your computer
* Run the classic Kibana locally, and make sure the OTel Host flow uses
the usual code snippet with ES ingest endpoint, ingest logs from your
computer
