## Summary
Add a new telemetry task to the security solution plugin to collect
ingest pipeline stats. The new task runs once a day, calls the
`_nodes/stats/ingest` API, and sends an EBT event with the following
information:
```js
export interface NodeIngestPipelinesStats {
name: string;
totals: Totals;
pipelines: Pipeline[];
}
export interface Pipeline {
name: string;
totals: Totals;
processors: Processor[];
}
export interface Processor {
name: string;
totals: Totals;
}
export interface Totals {
count: number;
time_in_millis: number;
current: number;
failed: number;
}
```
### 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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ryland Herrick <ryalnd@gmail.com>
8.17 PR - https://github.com/elastic/kibana/pull/215474
Part of https://github.com/elastic/security-team/issues/12176
Unskiped:
### `use_list_artifact.test.tsx`
Path
`.../plugins/security_solution/public/management/hooks/artifacts/use_list_artifact.test.tsx`
Closes https://github.com/elastic/kibana/issues/196724
Commit 438553a1d1
Reason for unskipping: Couldn't recreate failure locally. Increased
timeout from 1000 to 5000 ms.
### `actions_log_users_filter.test.tsx`
Path
`.../plugins/security_solution/public/management/components/endpoint_response_actions_list/components/actions_log_users_filter.test.tsx`
Closes https://github.com/elastic/kibana/issues/193554https://github.com/elastic/kibana/issues/193092
Commit ca7b971683de03fd5448fb3910e738
Reason for unskipping: wrapped expects in waitFor since they are
awaiting for state change. Increased the delay between keystrokes when
typing. Increased the timeout of tests since locally they are bordering
5s executions.
### `bad_argument.test.tsx`
Path
`.../plugins/security_solution/public/management/components/console/components/bad_argument.test.tsx`
Closes https://github.com/elastic/kibana/issues/193093
Commit 6959cd2e3f
Reason for unskipping: wrapped expects in waitFor since they are
awaiting for state change. Increased timeout to 10s.
### `use_get_endpoint_details.test.ts`
Path
`.../plugins/security_solution/public/management/hooks/endpoint/use_get_endpoint_details.test.ts`
Closes https://github.com/elastic/kibana/issues/192435
Commit 3ba10029b6
Reason for unskipping: increased timeout of waitFor for
renderReactQueryHook to 5s since locally it was bordering 3 seconds
## Summary
Closes https://github.com/elastic/kibana/issues/210298
In this PR we are adding the initial structure for the
@kibana/scout-security package, note that this is not ready to be used
and any new test using this package, is not going to be executed as part
of the regular pipelines, meaning, you are not going to add coverage to
the application.
@kibana/scout-security package is a test package that extends @kbn/scout
with test helpers specifically designed to test Security Solution
functionalities in Kibana. All tests under Security plugins should only
import from @kbn/scout-security, not from @kbn/scout.
This PR is a POC to start testing development by providing custom
Playwright fixtures, page objects, and utilities tailored for
Security-related testing scenarios.
Things to follow-up:
- CustomQueryRule interface is already declared in
`x-pack/solutions/security/plugins/security_solution/common/api/detection_engine/model/rule_schema/rule_schemas.gen.ts`
as `QueryRuleCreateProps`
- DETECTION_ENGINE_RULES_URL and DETECTION_ENGINE_RULES_BULK_ACTION are
already declared in `@kbn/security-solution-plugin/common/constants`
It would be great if all of that is extracted from the plugin to a
package so it can be reused instead of having to duplicate the code.
Until the package is not ready to be used and has not been introduced to
the different teams, appex-qa and myself will be the owners of it to
make sure that best practices are followed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
The PR updates the implementation to fetch data from the Risk Engine
Saved Object instead of storing and reusing it from LocalStorage.
This change ensures that settings are applied globally rather than being
limited to the browser’s LocalStorage. Since the Saved Object holds the
most up-to-date information, it is now used to update the "Date" and the
toggle for "including closed alerts for risk scoring" across all web
browsers.
### Normal and Incognito Mode :
https://github.com/user-attachments/assets/7638c88b-ff9e-4d42-9944-e55b53e33518
### Default space vs custom space :
https://github.com/user-attachments/assets/46bb35c7-3cd9-4b97-9f1c-90ec4ef1241a
## Testing Steps
### Verify Initial Values
1. Open the Entity Risk Score web page where the settings are applied.
2. Ensure that the date picker and toggle for "including closed alerts"
reflect the values stored in the Risk Engine Saved Object rather than
LocalStorage.
3. Modify and Save changes,
- Change the date range in the date picker.
- Toggle the "Include Closed Alerts" switch.
### Page Refresh Test
- Refresh the page and confirm that the modified values persist, fetched
correctly from the Risk Engine Saved Object.
### Cross-Browser Test
- Open the same web page in a different browser or incognito mode.
- Verify that the settings are consistent and correctly loaded from the
Risk Engine Saved
Object.
### Expected Outcome
The settings should persist after a page refresh or across different
browsers.
The latest values should always be pulled from the Risk Engine Saved
Object.
### 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
Provides the Cases service to the detection engine alerts table. The
missing services caused the cases actions to disappear from the bulk
actions menu.
## Verification steps
1. Create Security rules that fire alerts
2. Visit the Security > Alerts page
3. Select one or more alert rows from the table
4. Open the `Selected X alerts` bulk action menu
5. Check that the cases bulk actions are available
## Release Notes
Fixes a regression that caused the cases actions to disappear from the
detections engine alerts table bulk actions menu.
### 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)
## Summary
This PR is the setting the foundations for the AI for SOC Alert summary
page. It has very little UI, instead it focuses on the following:
- add routing for the `alert_summary` page
- fetches the integrations, filters them to only keep the ones related
to AI for SOC, then decides what to render depending on if some AI for
SOC packages have been installed or not
The PR also makes a small change to the `SecurityRoutePageWrapper`
component, to allow us to redirect to the Security Solution HomePage
instead of the NoPrivilegesPage. While this might not be a long term
solution, it is the easiest path forward. In the future, AI for SOC will
most likely be its own plugin (leaving outside of Security Solution)
hence this will not be needed anymore.
Here's the basic behavior of the Alert summary page:
- The `Landing page` will be shown if none of the hardcoded AI for SOC
packages are installed (these values are hardcoded as we currently do
not have a way to filter integrations for the AI for SOC ones only):
- splunk // doesnt yet exist
- google_secops
- microsoft_sentinel
- sentinel_one
- crowdstrike
- The `Wrapper` component will only be shown if you have at least one of
the above AI for SOC packages installed.
### Very limited UI added in this PR
| Loading integrations | No installed packages | Some installed packages
|
| ------------- | ------------- | ------------- |
| 
| 
| 
|
### Notes
We need to remove the section at the top of the page that currently
shows the `Add integrations` button. A follow PR will take care of that.
[This](https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/security_solution/public/app/home/index.tsx#L54)
is where that bar is being added. We will have to find a way to not show
that for the AI for SOC tier.
## 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' },
]
```
The Alert summary navigation will NOT be shown for the following
Serverless users: `viewer`, `t1_analyst`.
and `t2_analyst`. For those, the navigation entry is not present, and
navigating to the url directly will automatically re-route to the
Security home page.
Currently, retrieving the integrations (via the `fleet/epm/packages`
endpoint) is also unauthorized for the following users: `editor`,
`t3_analyst`, `threat_intelligence_analyst`, `rule_author`,
`soc_manager` and `detections_admin`.
This means that the only users that can be currently used to test this
PR are:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### 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
Will help close https://github.com/elastic/security-team/issues/11954 as
well as https://github.com/elastic/security-team/issues/11979.
## Summary
Some of the text in the Synthetics README is 6+ years old, which is
older than Synthetics itself. We need to try to keep these instructions
up to date a bit more as they are intended to be useful to inexperienced
contributors.
## Summary
Fixes#215106
This PR removes `service.environment` as a required field for
`getTopDependencySpans` endpoint.
It was not used at all, so it can be safely removed without adapting the
UI.
## Summary
When the data view refresh API or task was executed, it was overwriting
the engine's additional `indexPattern`.
This PR updates the code to support `indexPattern` and ensures the user
has privileges for all indices.
I extracted the merge function to add deduplicate logic.
### How to reproduce it?
* Create an entity store using the indexPatterns param
* Call refresh dataview API (`POST
kbn:api/entity_store/engines/apply_dataview_indices`)
* It will apply the dataview and ignore the indexPatterns param
After the fix, we should be able to update the indexPatterns param, and
the task that refreshes the index pattern should pick up the change
properly.
### 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
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The code changes in this PR ensure that the transform ID is limited to
36 characters when creating or updating the transform for risk-score.
This adjustment aligns with ES constraint on transform ID length.
## Test Steps
1. Create a new namespace with a very long name. Ex :
`namespace_that_stretches_farther_than_the_universe_and_beyond_like_buzz`
🚀
2. Enable the Risk Score in the new namespace. It should successfully
get enabled.
3. Check the transform that was created (using dev tools)
```
GET _transform/risk_score_latest_transform_*?filter_path=transforms.id,transforms._meta.space_id
```
Output
### 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] 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] 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)
---------
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
# Purpose
This change introduces new validations that ensure no loss of data is
possible if a user accidentally sets the Security Entity Store enrich
policy execution interval to a value that “doesn’t play nicely” with the
lookback period value.
The specific logic (greater than or equal to half the value) was chosen
to not only ensure no loss of data, but also provide extra resiliency in
case of a failed enrich policy execution.
(Note that this is not considered a breaking change, as the parameters
are not yet available on any version of Elastic, including Serverless.)
# How to test
1. Load appropriate entity log data to your Kibana instance (for
example, using the
[security-documents-generator](https://github.com/elastic/security-documents-generator))
2. Navigate to the Developer console
3. Attempt to enable the Entity Store via the /enable or /init routes
(examples below), and pass in values that are expected to error. For
example, “lookbackPeriod”: “24h” and “enrichPolicyExecutionInterval”:
“24h” should fail, because of the validation logic
4. Expect results similar to those shown below, specifically a 400
error, or else a success message
<img width="1902" alt="Screenshot 2025-02-27 at 12 57 45 AM"
src="https://github.com/user-attachments/assets/a7f4b0fb-9899-4e00-a0ae-d172245bd506"
/>
<img width="1909" alt="Screenshot 2025-02-27 at 12 58 06 AM"
src="https://github.com/user-attachments/assets/372acde2-9d7b-4c75-8596-af8374088f79"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This pr fixes some odd issues with getBulkActions, which is really a
hook in disguise, as well as an issue with the useGetMutedAlertsQuery
hook, which was/is fetching data much more often than it should, exactly
why that is I'm not sure, perhaps something to do with how timeline
blocks focus to the underlying DOM when it's open, and this causes the
default to true refetchOnWindowFocus prop of useQuery to re-run the
query, or if there's an error with the queryKey.
Below are 2 GIFs comparing react performance profiles of simply opening
and then closing the timeline while on the alerts page with 50 alerts in
the table.
Before fix:
12 renders for a total of 950 ms, a large portion of which is coming
from the alert table cells.
After fix:
8 renders for a total of 380 ms, almost none of it coming from the alert
table.
Each of the alerts table and timeline/discover drive some of the more
stateful and complex workflows in kibana on their own, and on top of
that one is rendering within a flyout on top of the other, listening to
the same url changes/tens of context provider wrappers changing above
them in the tree/kibana services, etc, & so proper memoization is a
pre-requisite for a good ux.
### 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
### Fleet
- Exposed API route for bulk get package policies via the routes service
- Created and exposed type `BulkGetPackagePoliciesRequestBody`
<br/>
### Security Solution
The following changes were made to Endpoint Artifacts in support of
spaces:
> [!NOTE]
> Space awareness is currently behind feature flag:
`endpointManagementSpaceAwarenessEnabled`
- The policy assignment component, which is displayed on artifact's
Create and Update forms, now:
- Displays the count of policies (if any) that are associated with the
artifact, but not currently accessible in the active space (screen
capture 1️⃣ )
- When a user does NOT have the Global Artifact privilege, the `Global`
toggle selection will be disabled and a tooltip is displayed. This
change also applies to the create form where the default selection will
be per-policy and the global button will be disabled. (screen capture
2️⃣ )
- Artifact policy assignments that are not accessible in active space
are preserved when submitting an update to the artifact
- The component was also refactored a bit to simplify its list of props
- Artifact card policy assignment menu was adjusted to show any policy
that is not accessible to the user as "disabled" along with a tooltip
(screen capture 3️⃣ )
- The update artifact API was changed (via server-side extension point)
to not error when validating policies that are not accessible in active
space if they were already associated with the item being updated.
- Fixes a bug in the Find artifacts API (impact only when spaces was
enabled) where an invalid filter was created when there was no policies
currently shared with active space.
## Summary
While doing a POC trying to implement the grouping component with the
UnifiedDataTable, I discovered a rendering issue that caused some sort
of infinite loop rerendering after selecting a group.
This PR fixes that issue but making sure we do not have a new instance
of an empty array every time the component is rendered.
## Summary
This PR reworks how APM handles getting its sources data, elevating the
necessary code to a private shared plugin so that Discover for Traces
can access the data and handle user provided configuration. It also
removes the need for Discover for Traces to rely on the APM static data
view, so the Trace data source and document profile will work on any
compatible/configured index, even in ESQL mode.
Closes#211414
<img alt="ESQL Discover Traces Screenshot 2025-03-04 173032"
src="https://github.com/user-attachments/assets/f5bbb736-8b8b-45dc-ac23-4bf7083aa47e"
/>
## How to test
Test with olbt-cli instance for now, will post for doing with synthtrace
data. Ensure the following is added to your kibana.dev.yml:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
```
- Make sure your space has the Observability solution view configured
- Go to Discover page
- Select Data Views mode if required and create a view with a `traces`
specific index. Or use the APM static data view.
- The default columns on the page should show the summary column with
four of the following badges: `service.name`, `event.outcome`,
`transaction.name`, `transaction.duration.us`, `span.name`,
`span.duration.us`
- Go to ESQL mode with the query targetting a `traces` index
- The default columns should show the same as in Data View mode
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Irene Blanco <irene.blanco@elastic.co>
## Summary
The PR updates the code to extend the lookback period for Risk scoring
calculations from `now-30m` to `now-30d`.
This change impacts:
- Risk score UI (date picker)
- The preview API
- The enable API (for Risk Score Saved Object configuration)
### 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)
Screenshots :
## UI and Preview API payload
## Risk Engine configuration SO
## Testing Steps:
1. Navigate to the Entity Analytics management page (Entity Risk Score
webpage).
2. Ensure the default text in the date picker displays **"Last 30
days"**.
3. Open the **Network** tab in Developer Tools and verify that the
**"preview"** API request reflects a 30-day difference between the
`from` and `to` values.
4. If the **Risk Engine** is enabled, disable it and open a window
displaying Kibana logs.
5. Re-enable the **Risk Engine** and check the logs for the
configuration message: **"Risk engine running with configuration"**. The
expected range should be:
```json
"range": {
"start": "now/M",
"end": "now"
}
```
## Advanced Testing Steps
1. The date picker should default to **"Last 30 days"**. If you change
it to **"Yesterday"** without clicking **Save changes**, the **Preview
API** should reflect "Yesterday," but the **Saved Object (SO)** should
**not** update its range.
2. Upon refreshing the page without saving the changes, the date picker
should reset to its default value, **"Last 30 days"**.
Closes https://github.com/elastic/kibana/issues/208037
This change switches OTel K8S quickstart flow on Serverless to the
managed OTel collector as the ingest endpoint.
* Adds shared `useOtelIngestEndpointUrl` hook to be later re-used in
OTel Host flow as well
* Adds the logic to use APM API key on serverless to access the managed
service endpoint
* Modifies the code snipped with the new variables
## How to test
* Use the Serverless instance deployed from this PR, make sure OTel K8S
flow code snippet uses the managed service endpoint, ingest logs from
your computer (you can use [reference-stack
cluster](https://github.com/elastic/oblt-reference-stack) with minikube)
* Run the classic Kibana locally, and make sure the OTel K8S flow uses
the usual code snippet with ES ingest endpoint, ingest logs from your
computer
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves#212981
## Release Notes
Adds the ability to create an APM availability or latency SLO for all
services
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Kevin Delemme <kdelemme@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/214709#event-16799922233
The issue was caused by the rollover of the Knowledge Base Data stream
to use default inference endpoint.
During the rollover it first got to this branch
https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/elastic_assistant/server/ai_assistant_service/index.ts#L347-L369
where it went through all the steps and continued, but it didn't
override `this.knowledgeBaseStream`, so the next time someone hit API it
was going through this path calling `getInitializedResources` to make
sure all data streams were configured properly, but because we didn't
update `this.knowledgeBaseStream` it was failing, because the original
configuration that was created in service constructor was not called,
that's why it was returning an error
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
## Summary
Add a new privileges check before executing `applyDataViewIndices`.
This change impacts the API call `applyDataViewIndices` and the job.
`applyDataViewIndices` updates the transforms. Executing without
privileges generates a silence error because the transform can't run.
I also added some extra unit tests for `applyDataViewIndices`.
Required privileges
['read', 'view_index_metadata'] for all security solution dataview +
asset_criticality and risk_score indices.
### How to test it
1. **API call with unprivileged user scenario**
* Enable the entity store with a superuser
* Create an unprivileged user
* Call `POST kbn:api/entity_store/engines/apply_dataview_indices`
* It should return an error
* Add the required privileges
* It executes successfully
2. **Task execution with an unprivileged user scenario**
* Create a user and add privileges only for the required Entity Store
indices
* Login with the new user
* Enable the entity store
* Add a new index to the security data view (the new user shouldn't have
access to the new index)
* Wait for 30min for the job to run, or update the [source
code](8d0feb580f/x-pack/solutions/security/plugins/security_solution/server/lib/entity_analytics/entity_store/tasks/data_view_refresh/data_view_refresh_task.ts (L150))
to make it run more often
* The job execution should fail with an error message containing the new
index name.
### Checklist
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
Adds more coverage for FTRs to test Synonyms UI in serverless.
Adds test cases for synonyms set listing, synoyms set detail and adding
deleting rules.
Covers some happy paths.
### 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] 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)
## Summary
Resolves#212784
Ensure that when an SLO is created, the id is verified across all
spaces.
## Release Notes
Ensure that when an SLO is created, the id is verified across all
spaces.
## Testing
1. Create an SLO and save the id returned in the response in a space "A"
2. Create a second SLO with the id saved from the first SLO in the
request in a different space "B"
3. User should receive a 409 error from the SLO API.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Partially resolves https://github.com/elastic/kibana/issues/180709
Adds `context.grouping` action variable in the following rules:
- Custom threshold rule
- APM Latency threshold rule
- APM Failed transaction rate rule
- APM Error count rule
I will open a follow up PR to add `context.grouping` action variable in
the following rules:
- Elasticsearch query rule
- SLO burn rate rule
Excluded from scope:
- Metric threshold rule (already has `context.groupByKeys`)
- Log threshold rule (already has `context.groupByKeys`)
- Inventory threshold rule (already has `context.group` and this rule
doesn't have explicit group by fields)
### Testing
1. Create each rule with group by fields, and with "active" and
"recovered" actions
3. In "active" and "recovered" action message, use `context.grouping`
variable
4. Ensure that both "active" and "recovered" alert notifications contain
correct information
5. Ensure that the action variables UI in rule form shows
`context.grouping` action variable
Example of action message for APM Latency threshold rule with group by
on `transaction.name`:
```
{
"grouping": "{{context.grouping}}",
"service.name": "{{context.grouping.service.name}}",
"service.environment": "{{context.grouping.service.environment}}",
"transaction.type": "{{context.grouping.transaction.type}}",
"transaction.name": "{{context.grouping.transaction.name}}"
}
```
Example of action message for Custom threshold rule with group by on
`host.name` and `container.id`:
```
{
"grouping": "{{context.grouping}}",
"host.name": "{{context.grouping.host.name}}",
"container.id": "{{context.grouping.container.id}}"
}
```
---------
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
## Summary
**Requirement:**
In stack and when its search solution space, we need to update search
index details breadcrumbs, when navigated via Content -> Index
Management :
- Index management list page - `Content / Index Management / Indices`
- Index list page -` Content / Index Management / indices /
<index_name>`
- drop `Stack management` from the breadcrumb
In Classic nav, index management index details page breadcrumbs will
have no change in UI. But index management app is rendered from
search_indices plugin
### Solutions
Currently, Index management app is rendered from
[management_app](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/management/public/components/management_app/management_app.tsx).
The management app sets breadcrumbs for all the dependant apps. The
easiest way to implement is to set breadcrumbs based on active solution
type - `es` but this would alter breadcrumbs when index management app
is rendered from side nav footer ( management -> index management) and
other related management apps as well.
Other options is to modify setBreadcrumbs in
[ManagementAppMountParams](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/management/public/types.ts#L79)
but the setBreadcrumbs is used by multiple other apps.
In this PR, index management app is mounted via search indices plugin.
In this way we can customize breadcrumbs for index management when
rendered from search_indices plugin. When its search solution type,
index management app will work independently from management app.
### Screenshots
#### Search solution Nav - Changed breadcrumb ( dropped stack management
& added index name)
<img width="1727" alt="Screenshot 2025-02-04 at 1 29 08 PM"
src="https://github.com/user-attachments/assets/bc6f733f-62f4-44bc-8373-24d92719f5df"
/>
#### Serverless
**Note:** No change in functionality from this PR. Added for additional
info
index details page breadcrumbs should be `Data/ Index Management /
Indices/<index_name>`
index list page breadcrumbs should be `Data/ Index Management /
Indices/`
**Serverless Details page**
<img width="1727" alt="Screenshot 2025-02-04 at 1 23 14 PM"
src="https://github.com/user-attachments/assets/72bac7a8-d7d1-40fc-9c73-bbd0545dba1f"
/>
### 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Exposes an Inference (plugin) API client for scripts, that mimicks the
`chatComplete` and `output` APIs that are available on its start
contract. It depends on the KibanaClient that is exposed from the
`@kbn/kibana-api-cli` package. It automatically selects a connector if
available.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We decided to group `Kibana API helpers` under a single fixture:
`apiServices` instead of individual fixtures. It should simplify the
search of existing helpers and reduce a risk for Teams to create the
same helper like we see today with FTR.
Adding just `apiServices` in test context and adding dot will expand a
list of all available API helpers + it can be extended for individual
solution (e.g. @kbn/scout-oblt) and directly in plugin (if there is no
chance to re-use it in other plugins)
<img width="699" alt="image"
src="https://github.com/user-attachments/assets/34a76659-04af-48c4-ab69-abda0c950206"
/>
Before:
```
test('should create something', async ({
fleetApi,
onboardingApi,
alertingApi,
}) => {
await fleetApi.integration.install(integrationName);
await onboardingApi.updateInstallationStepStatus(
onboardingId,
'ea-download',
'complete'
);
await alertingApi.waitForAlert(alertId);
```
After:
```
test('should create something', async ({
apiServices,
}) => {
await apiServices.fleet.integration.install(integrationName);
await apiServices.onboarding.updateInstallationStepStatus(
onboardingId,
'ea-download',
'complete'
);
await apiServices.alerting.waitForAlert(alertId);
```
This PR introduces evaluation functionality to Defend Insights, enabling
us to trigger LangSmith experiments directly from Kibana.
Additionally, we’ve migrated to the new prompt storage system used in
Attack Discovery (see commit bcbb12b732).
## Summary
Closes#213074
This PR fixes the scenario where the entry waterfall transaction is
treated as an orphan, causing it to reparent itself and be duplicated
multiple times.
---------
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
Closes https://github.com/elastic/observability-dev/issues/4238🔒
Closes https://github.com/elastic/observability-dev/issues/3513🔒
This change add logic for triggering [the page rendering performance
metrics](https://docs.elastic.dev/kibana-dev-docs/tutorial/performance/adding_custom_performance_metrics#report-kibanaplugin_render_time-metric-event)
for:
* Onboarding home screen
* Host auto-detect flow
* Host OTel flow
* Host K8S flow
* K8S OTel flow
* Firehose flow
## How to test
1. Run Kibana locally
2. Open browser dev tools
3. Navigate to one of the above mentioned onboarding screens
4. Observe `kibana:plugin_render_time` EBT event emitted in the Network
tab of the dev tools
Events emitted from local Kibana end up in the Staging Telemetry
cluster, there is a [dedicated rendering performance
dashboard](f240fff6-fac9-491b-81d1-ac39006c5c94?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-24h%2Fh,to:now))),
onboarding events can be filtered using `observabilityOnboarding`
application ID. (note that it takes some time for events to be indexed
and they appear in the cluster with a significant delay)
