## Summary
Epic: https://github.com/elastic/kibana-team/issues/1435
Closes https://github.com/elastic/kibana/issues/205413
Closes https://github.com/elastic/kibana/issues/205411
This PR creates a new way to expose stateful service dependencies needed
for rendering React elements in Kibana. The concept of the changes is
that `KibanaRenderContextProvider` should not be a shared module, but
should be wrapped by a core service (the `RenderContextService` name is
TBD). The next steps in this direction would be to coordinate teams to
migrate away from directly using `KibanaRenderContextProvider`.
### Background
Today, the dependencies for `KibanaRenderContextProvider` are declared
as separate services which can be found in the `CoreStart` context. This
has created a situation where enhancing the module with more
dependencies creates widespread changes needed for the UI codebase.
The @elastic/appex-sharedux team is looking to solve this situation by
defining a less impactful way to make future enhancements. The solution
is one that can be gradually migrated towards, so the SharedUX team can
ask Kibana contributors to migrate towards in their own code. This PR
offers a POC for that solution.
### Details of this POC
The driving goal for this refactor is to lessen the impact across the
Kibana codebase whenever the `KibanaRenderContext` module needs to
require additional services from the `CoreStart` context.
#### Rendering a React Element with `ReactDOM.render`: Before
```tsx
const renderApp = ({ core, targetDomElement }: { core: CoreStart; targetDomElement: HTMLElement; }) => {
// If `KibanaRenderContextProvider` needs to expand its scope, more services could be needed here,
// updating all the places throughout the code to pass those is a ton of work 👎🏻
const { i18n, theme, analytics, userProfile, executionContext } = core;
ReactDOM.render(
<KibanaRenderContextProvider {...{ i18n, theme, analytics, userProfile, executionContext }}>
<MyApplication />
</KibanaRenderContextProvider>,
targetDomElement
);
return () => ReactDOM.unmountComponentAtNode(targetDomElement);
};
```
#### Rendering a React Element with `ReactDOM.render`: After
```tsx
const renderApp = ({ core, targetDomElement }: { core: CoreStart; targetDomElement: HTMLElement; }) => {
// So much less code, so much more future-proof 👍🏻
ReactDOM.render(core.rendering.addContext(<MyApplication />), targetDomElement);
return () => ReactDOM.unmountComponentAtNode(targetDomElement);
};
```
### Alternatives considered
See https://github.com/elastic/kibana/pull/209161
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### FAQ
1. **Q**: This is React-centric. Does this give Kibana more commitment
towards React?
**A:** For now, yes. But if we want to Kibana to remain
framework-agnostic we may be able to add more extensions to the
RenderContextService that support other frameworks.
1. **Q:** Why not have a service that wraps `ReactDOM.render`?
**A:** As we steer towards upgrading to React 18 in Kibana, staying
agnostic of how React is rendered benefits us. React 18 has different
ergonomics based on whether you want to update an existing tree or mount
a new one.
1. **Q:** Does the API have to be named `rendering.addContext`?
**A:** No, it does not. Please suggest a better name if you have one in
mind.
1. **Q:** What are the next steps?
**A:** Refer to the
[Epic](https://github.com/elastic/kibana-team/issues/1435). This PR
started as a POC but became ready for merge. After it is delivered to
the codebase, the next steps are to improve documentation and engage in
"sheparding." That is, socialize the new way of injecting dependencies
into the context, support teams in their migration, and track the
progress of migration.
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [x] Care is needed to ensure this doesn't not negatively impact
performance with unnecessary re-renders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Only merge this if you want streams to go public
This PR changes the logic for the client side "status$" observable for
streams to look for whether it's on serverless in an observability
project (because this is where we want to launch first).
Later on, this logic can be adjusted as necessary for on-prem launches
etc.
To make this work locally, you need to add
`xpack.cloud.serverless.project_id: "project_id"` to your
`config/kibana.dev.yml`
It still shows the streams app if wired streams are enabled (basically
it keeps the old behavior plus always defaulting to `enabled` if it's an
observability serverless project.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/215335
Currently, when an agent policy is duplicated, shared integration
policies are also duplicated. This PR adds logic where the duplicated
agent policy also shares these integration policies.
### Testing
* Run ES with an [Entreprise
license](https://www.elastic.co/subscriptions) to avail of reusable
integration policies.
* Create an agent policy with a shared integration policy and a
non-shared integration policy.
* Duplicate the agent policy: the duplicated policy should only
duplicate the non-shared integration policy and the shared integration
policy should be reused.
### 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
- [ ] 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
Incorrect package policies in duplicated agent policies.
## Summary
This PR introduces the first building blocks for the [Entity Analytics
Privileged
Monitoring](https://github.com/elastic/security-team/issues/9971).
We follow the approach used in the Entity Store and add a new "Engine",
which consists of the following components:
* Public API
* INIT and HEALTH routes
* Kibana task
* Privilege Monitoring Data Client
* Engine Saved Object
* API key manager
* Related storage indices
* Feature Flag: `privilegeMonitoringEnabled` set to `false` by default.
* API integration test configuration
* only tests that the health endpoint is available
* Auditing and Telemetry
## Testing steps
1. Make sure to add `privilegeMonitoringEnabled` to your
`kibana.dev.yaml`
2. In devtools, ensure the API is working with `GET
kbn:/api/entity_analytics/monitoring/privileges/health`
3. Start the engine with: `POST
kbn:/api/entity_analytics/monitoring/engine/init`
4. Look for `DEBUG` logs mentioning the
`entity_analytics:monitoring:privileges:engine` task
---------
Co-authored-by: CAWilson94 <charlotte.wilson@elastic.co>
Co-authored-by: Charlotte Alexandra Wilson <CAWilson94@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[Preconfigured
connectors](https://www.elastic.co/guide/en/kibana/current/pre-configured-connectors.html)
are those that are specified via the `kibana.yml` config, and thus they
can't be deleted. In tests, we've hardcoded their ids to skip deleting
them when we need to clean up the tests' state.
Sometimes, the id of a preconfigured connector gets changed by somebody,
which breaks tests of multiple teams in MKI pipelines, such as the
periodic pipeline or the release quality gates. The problem is that it
doesn't happen on CI where Kibana doesn't have any preconfigured
connectors, so this feedback loop is too long. When tests in an MKI
pipeline break, it's not immediately clear what happened and who should
fix it. Eventually it gets fixed by someone [like
this](https://github.com/elastic/kibana/pull/217570/files).
Instead of hardcoding the ids, we should dynamically determine if a
connector is preconfigured and if it should be deleted by a test or not.
This is possible to do as each connector has the corresponding
`is_preconfigured` property.
<img width="1073" alt="Screenshot 2025-04-10 at 14 16 15"
src="https://github.com/user-attachments/assets/e330cd5f-c9f0-43da-b4b4-f2a0a2fd10a5"
/>
### 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
- [ ] [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
Fixes https://github.com/elastic/kibana/issues/217935 (in the quickest
way possible for now).
## Possible followups
- We could potentially move these advanced parameters to a sub object.
However, the idea was that `FieldDefinitionConfig` utilises a union of
`MappingProperty` (from ES) so that this wasn't needed 🤔
- The types can definitely be improved (`getAdvancedParameters` takes in
`fieldConfig: FieldDefinitionConfig` and this missed the possibility of
`InheritedFieldDefinitionConfig`, for example). We could also make the
stripping schema driven.
## 📓 Summary
Fixes a link targeting the overview page while it should have gone to
the management section.
Also fixes broken redirect when targeting `/{key}/management`
## Summary
- Fix a bug that was causing failing tool invocations to not being
persisted to the conversation history, corrupting the conversation for
following rounds.
- Optimize the researcher's prompts (leading to ~50% latency cut, mostly
on the summarization step)
Closes https://github.com/elastic/kibana/issues/210979
## Summary
- This PR updates the rules list and rules details pages to hide actions
for the users with read-only access. Previously, these actions were
disabled, but now they are completely hidden. Specifically:
- on the `Rules List` page, the snooze bell icon and the table row
actions are now hidden for the users with read-only access
- on the `Rule Details` page, the actions button is now hidden
(previously, the users could click on it, but the options were disabled)
<img width="1899" alt="Screenshot 2025-04-02 at 14 06 53"
src="https://github.com/user-attachments/assets/712297bf-b807-4ecc-87da-a32cd67d169f"
/>
<img width="1899" alt="Screenshot 2025-04-02 at 14 07 06"
src="https://github.com/user-attachments/assets/a88762fa-feeb-4117-9dc4-31744c752d82"
/>
## Summary
Renaming types and files as well as moving providers around to make
implmentating saved playground routes more straightforward. Naming
updates to reduce future confusion from generic names that didn't fit
when there are multiple providers etc.
## Summary
Changes the DashboardStart server api to provide a getContentClient
function.
In https://github.com/elastic/kibana/pull/214788, we set the
`contentClient` returned from the content management register method
after start lifecycle of all plugins. This means the `contentClient`
returned from the `DashboardStart` contract was undefined. This PR
changes the start contract to provide a getContentClient function
instead.
Only one consumer was using the contentClient from DashboardStart and
this PR also updates that consumer.
## Summary
Closes https://github.com/elastic/kibana/issues/206556
This PR adds a setting to remote ES outputs for also uninstalling
integrations on remote clusters when integrations sync is enabled.
This new setting can be toggled in the UI with a new switch:
<img width="1728" alt="Screenshot 2025-04-09 at 11 53 43"
src="https://github.com/user-attachments/assets/34544aa9-28fd-4360-a32f-5031e3d4293f"
/>
### Testing
* Follow the steps in
https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/local_setup/remote_clusters_ccr.md
to set up two clusters with integrations syncing.
* Add some integrations in your main cluster and check that they are
also installed in the remote cluster.
* Disable uninstalling integrations on remote.
* Remove an integration in your main cluster and check that it is NOT
removed from the remote cluster.
* Enable uninstalling integrations on remote.
* Remove an integration in your main cluster and check that it is also
removed from the remote cluster.
* In your remote cluster, enroll an agent onto a policy that points to
at least 1 package policy of the installed integrations (cf. Docker
commands below if using dockerized fleet-server/agent).
* In your main cluster, uninstall the integration that is used by the
agent policy in the remote. This should cause the uninstall to fail into
the remote cluster.
* In your remote cluster, inspect the package SO of that integration
with `GET .kibana_ingest/_search?q=type:epm-packages`: the
`latest_uninstall_failed_attempts` field should be populated.
Docker command for running a fleet-server in your remote cluster:
```
docker run \
-e ELASTICSEARCH_HOST=http://host.docker.internal:9500 \
-e KIBANA_HOST=http://host.docker.internal:5701/<path> \
-e KIBANA_USERNAME=elastic \
-e KIBANA_PASSWORD=changeme \
-e KIBANA_FLEET_SETUP=1 \
-e FLEET_INSECURE=1 \
-e FLEET_SERVER_ENABLE=1 \
-e FLEET_SERVER_POLICY_ID=fleet-server-policy \
-p 8220:8220 \
--rm docker.elastic.co/beats/elastic-agent:9.0.0-SNAPSHOT
```
Docker command for enrolling an agent in your remote cluster:
```
docker run \
-e ELASTICSEARCH_HOST=http://host.docker.internal:9500 \
-e KIBANA_HOST=http://host.docker.internal:5701/<path> \
-e FLEET_URL=https://host.docker.internal:8220 \
-e FLEET_ENROLL=1 \
-e FLEET_ENROLLMENT_TOKEN=<token> \
-e FLEET_INSECURE=1 \
--rm docker.elastic.co/beats/elastic-agent:9.0.0-SNAPSHOT
```
### Checklist
- [ ] 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
- [ ] 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
This feature is currently in development and behind the
`enableSyncIntegrationsOnRemote` feature flag.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Implements the m1 design for the chat page and components
*Note: only covers the parts that are functionally present in the app
atm*
### Design demo
https://github.com/user-attachments/assets/16f64a51-16ad-45c5-9d4b-77c31598427a
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
By feedback from @LucaWintergerst we shouldn't sort the component
templates in the "advanced" tab since their order matters when applied.
This PR removes the sorting that's set on the table.
## 📓 Summary
This work addresses the following issues on some stream management
pages:
- privileges...
- a user should still be able to reorder processors during a simulation,
even if doesn't have `manage` permissions to save it then.
- a user should be able to read an existing processor configuration,
even if doesn't have `manage` permissions to save it then.
- the "only simulate" routing tooltip was shown always, even when
creating a child stream is possible.
- a toast error was shown on streams re-ordering even if everything was
saved correctly:
<img width="2090" alt="Screenshot 2025-04-10 at 11 07 02"
src="https://github.com/user-attachments/assets/9838b2dd-3c0d-406f-a989-337a832d7131"
/>
## Summary
Closes https://github.com/elastic/kibana/issues/194975
This PR improves the `aria-label` attributes in the latency correlations
page to add more context about the selected field.
This PR introduces a new event type,
`endpoint_workflow_insights_remediated_event`, and extends some of the
existing ones. The goal is to enable better monitoring of the **Defend
Insights** feature usage.
### Event Types
- **`defend_insight_success`** – Sent when the Scan button triggers an
API call and an insight is successfully created. This carries most of
the valuable data, such as result contents, duration, etc.
- **`endpoint_workflow_insights_remediated_event`** – Sent when a
Trusted App is added as a result of an insight, and that insight is
marked as remediated.
- **`defend_insight_error`** – Sent when insight generation fails and no
results are returned.
### Data sent to telemetry
**`defend_insight_error`**
```
actionTypeId – Kibana connector type
errorMessage – Error message from ES/LLM
model – LLM model
provider – Model provider
```
**`endpoint_workflow_insights_remediated_event`**
```
insightId – The ID of the action that was sent to the endpoint (currently unused)
```
**`defend_insight_success`**
```
actionTypeId – Kibana connector type
eventsContextCount – Number of events sent as context to the LLM
insightsGenerated – Number of Defend insights generated
durationMs – Duration of the request in milliseconds
model – LLM model
provider – Model provider
insightType – Type of Defend insight (e.g., incompatible-antivirus)
insightsDetails – Details of the generated insights (e.g., ["ClamAV", "Avast"])
```
