## Summary
Removes unused code from the Investigate and Investigate app plugin.
Removes all references to those plugins in storybook, i18n, types, etc.
Removes codeowner requirements for those plugins
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> [!CAUTION]
> Do not merge yet!
> This PR is mergeable based on the assumption that we do not allow
downgrading to `search_ai_lake` tier from `essentials`/`complete` or
`trial` `complete/essentals`.
## Summary
On serverless with following sets of product types/lines timelines and
notes are not available to the user.
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' }
]
```
or
```json5
[
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
or with
```json5
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
{ product_line: 'security', product_tier: 'search_ai_lake' }
]
```
This applies to custom role creation flyout where timelines/notes
privileges are not available for RBAC.
### Screenshots (where timeline and notes are not available)
#### Custom role creation
Also on alerts page notes and timelines is not available action items.
Trying to access these via URL does not show them either.
#### Current alerts page (with timelines and notes not available)
#### Alert details via URL (without notes on the expanded flyout)
## 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` privileges and verify that only 4
sub-privileges are seen and that Timelines and Notes are not among them.
### 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
~**DO NOT MERGE:** depends on
https://github.com/elastic/kibana/issues/213468~
This PR reintegrates the work from the `workchat_m1` branch into `main`:
- introduces a 4th solution type, `chat`, that will be used for the
*WorkChat* project type.
- edit things in various platform code to introduce/handle that new
project type
- add plugins and packages for the workchat app.
### To AppEx reviewers:
File change count is scary, but you can safely ignore anything from
`xpack/solutions/chat` (given it's solution code), and focus on your
owned changes, which are way more reasonable
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe McElroy <joseph.mcelroy@elastic.co>
Co-authored-by: Rodney Norris <rodney.norris@elastic.co>
Co-authored-by: Jedr Blaszyk <jedrazb@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Meghan Murphy <meghan.murphy@elastic.co>
Removes the "disabled" flag for Security's Entity Store feature from the
Security Solution's serverless configuration (i.e., effectively enabling
the feature in Serverless).
This feature has already been tested in ECH.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In https://github.com/elastic/kibana/pull/170234, we added validation on
the security solution settings in serverless that is enabled through the
`xpack.securitySolution.enableUiSettingsValidations` config setting. In
this PR, we move this setting to `config/serverless.security.yml` so
that it follows the sustainable architecture principles.
## Summary
Enables the SIEM Migrations feature in serverless. The experimental flag
will be cleaned later.
> [!NOTE]
To release this feature as planned (Friday 28th March 2025), this PR
needs to merge between Monday **24** and Thursday **27**
### Screenshot
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## 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>
Towards https://github.com/elastic/response-ops-team/issues/248
In this PR, I'm setting the default `xpack.task_manager.capacity` value
to `20` for security serverless projects. We've incremented this setting
gradually via gitops over the past few months and now it's set to `20`
across all environments. Before we cleanup the gitops repo, we need to
roll this out to all environments for the setting to remain in place.
# Release note
Legacy OpenSSL algorithms have been disabled by default. Further
information on which algorithms can be found at
https://docs.openssl.org/3.0/man7/OSSL_PROVIDER-legacy. These can be
re-enabled by adding `--openssl-legacy-provider` to
`$KBN_PATH_CONF/node.options`
## Summary
Update Preconfigured connector name to `Elastic LLM`.
<img width="1504" alt="Screenshot 2025-02-20 at 11 29 02 AM"
src="https://github.com/user-attachments/assets/aa0a32f7-f1b2-4496-8c2e-7773f017c153"
/>
### ES3 Testing instruction
No additional config needed. Once run in local machine, the changes
should reflect automatically.
### ESS instructions
In `kibana.dev.yml` file, add
```
# xpack.actions.preconfigured:
Elastic-LLM:
name: Elastic LLM
actionTypeId: .inference
exposeConfig: true
config:
provider: 'elastic'
taskType: 'chat_completion'
inferenceId: '.rainbow-sprinkles-elastic'
providerConfig:
model_id: 'rainbow-sprinkles'
```
and the preconfigured endpoint with updated name should be visible.
### 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
Resolves https://github.com/elastic/eui-private/issues/169
## Summary
This PR makes Borealis the default theme in Serverless (traditional
kibana flavor already uses Borealis as the default) and adds a
`coreRendering.defaultThemeName` LD feature flag to allow a graceful
switch when this code gets deployed next week.
To switch back to Amsterdam when developing locally, set
`feature_flags.overrides.coreRendering.defaultThemeName: amsterdam` in
`kibana.dev.yml`
Please note that `DEFAULT_THEME_TAGS` still includes both Amsterdam and
Borealis. We've decided to keep Amsterdam bundled in case of any
unexpected errors. We'll make Amsterdam opt-in and reduce the bundle
size within the next two weeks (target date Feb 21st).
For the sake of a straightforward review of this PR, I will remove the
previously defined `theme:name` UI setting and `themeSwitcherEnabled`
logic in a follow-up PR.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
fixes https://github.com/elastic/search-team/issues/9171
## Summary
The connectors integration should be GA in ECH, but shouldn't be
available in serverless right now.
~~Prettier also triggered on these files based on our `.prettierrc`
rules, it looks like. Let me know if I should revert all the formatting
changes. There were mixed quotes in a few places, and some indentation
stuff in others.~~
I removed the prettier changes because they invited substantial
conflicts with all the whitespace changes.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [x] Changes serverless behavior, so I'm deploying a serverless search
project to smoke test
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This updates the Search notebooks config path to fix a config conflict,
now that the main search plugin owns `xpack.search`. This config should
only have been used in Serverless and was never pushed to other users,
but I've added a rename and deprecation warning just in case anyone used
it..
This PR is adding the Serverless Kibana preconfigured `.inference`
connector for Elastic Rainbow Rainbow Sprinkles LLM.
Instead of adding within kibana-controller
## Summary
This PR renames the `enterprise_search` config path from
`enterpriseSearch` to `xpack.search`. This is to migrate away from
customer facing usage of enterprise search and align with other search
plugin config paths like `xpack.serverless.search`.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
As titled. The Project Switcher was created in #155582 as a means of
allowing a developer to switch between project types without having to
restart Kibana. Since that first PR, Kibana *must* be started with a
particular project configuration in mind-- the switcher now does
nothing. This PR removes it and deprecates the config keys.
## Summary
Remove the implicit grant of the `savedQueryManagement` feature with the
Security Solution basic feature (ID: `siemV2`) in Serverless.
This is a follow-up of https://github.com/elastic/kibana/pull/202863
### Feature `siemV2`
This change only affects new roles created with the `siemV2` feature,
introduced recently
[here](https://github.com/elastic/kibana/pull/201780).
This change will align the Roles UI in Serverless and ESS, both
requiring the `savedQueryManagement` feature to be explicitly granted to
be able to manage saved queries.
### Feature `siem`
Roles using the deprecated `siem` feature will still implicitly receive
the `savedQueryManagement` feature (via an implicit grant of `discover`,
`dashboard`, `visualize`, and `maps`) + migration to their `*v2`
features which include `savedQueryManagement`. So there's no behavior
change for existing roles using the old `siem` feature (no breaking
change).
## Screenshots
The siem/siemV2 feature toggle:
<img width="774" alt="siem feature"
src="https://github.com/user-attachments/assets/2759988a-3cf8-4e1f-9431-16c09cf9d95c"
/>
The savedQueryManagement feature toggle:
<img width="774" alt="Saved query feature"
src="https://github.com/user-attachments/assets/d0145244-f4b8-4577-b91f-93f4dd1f758b"
/>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### 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/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] 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)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
This PR enables the SIEM migrations experimental flag by default in
ESS/on-prem.
We keep the experimental flag disabled in serverless (using
`config/serverless.security.yml`) since we don't want to release it yet.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/eui-private/issues/171
Resolves https://github.com/elastic/eui-private/issues/177
## Summary
This PR addresses a prior PR review
[comment](https://github.com/elastic/kibana/pull/203840/files#diff-bb850523655bac7adb30995553acabae9705435fa51e5b8bf13c483152db694a)
by removing `isServerless` from the logic determining what theme should
be used at runtime with a simple YML configuration setting instead.
I added a non-public `uiSettings.experimental.defaultTheme` config
property that defaults to `borealis` and is set to `amsterdam` in
`serverless.yml`. Since the default theme is now (and should be) set to
Borealis, I also updated `DEFAULT_THEME_NAME` and `FALLBACK_THEME_NAME`
to reflect that. This doesn't have any impact on Serverless; it will
keep using Amsterdam.
Additionally, while making these changes, I wanted to simultaneously
improve types and address earlier PR
[comment](https://github.com/elastic/kibana/pull/199748#discussion_r1840402343).
Now `SUPPORTED_THEME_NAMES` array is declared as `const` making the
`ThemeName` type strict instead of resolving a generic `string` type.
Usages were updated to use `ThemeName` instead of `string`, too.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Epic: https://github.com/elastic/security-team/issues/7998
In this PR we're breaking out the `timeline` and `notes` features into
their own feature privilege definition. Previously, access to both
features was granted implicitly through the `siem` feature. However, we
found that this level of access control is not sufficient for all
clients who wanted a more fine-grained way to grant access to parts of
security solution.
In order to break out `timeline` and `notes` from `siem`, we had to
deprecate it feature privilege definition for. That is why you'll find
plenty of changes of `siem` to `siemV2` in this PR. We're making use of
the feature privilege's `replacedBy` functionality, allowing for a
seamless migration of deprecated roles.
This means that roles that previously granted `siem.all` are now granted
`siemV2.all`, `timeline.all` and `notes.all` (same for `*.read`).
Existing users are not impacted and should all still have the correct
access. We added tests to make sure this is working as expected.
Alongside the `ui` privileges, this PR also adds dedicated API tags.
Those tags haven been added to the new and previous version of the
privilege definitions to allow for a clean migration:
```mermaid
flowchart LR
subgraph v1
A(siem) --> Y(all)
A --> X(read)
Y -->|api| W(timeline_write / timeline_read / notes_read / notes_write)
X -->|api| V(timeline_read /notes_read)
end
subgraph v2
A-->|replacedBy| C[siemV2]
A-->|replacedBy| E[timeline]
A-->|replacedBy| G[notes]
E --> L(all)
E --> M(read)
L -->|api| N(timeline_write / timeline_read)
M -->|api| P(timeline_read)
G --> Q(all)
G --> I(read)
Q -->|api| R(notes_write / notes_read)
I -->|api| S(notes_read)
end
```
### Visual changes
#### Hidden/disabled elements
Most of the changes are happening "under" the hood and are only
expressed in case a user has a role with `timeline.none` or
`notes.none`. This would hide and/or disable elements that would usually
allow them to interact with either timeline or the notes feature (within
timeline or the event flyout currently).
As an example, this is how the hover actions look for a user with and
without timeline access:
| With timeline access | Without timeline access |
| --- | --- |
| <img width="616" alt="Screenshot 2024-12-18 at 17 22 49"
src="https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042"
/> | <img width="724" alt="Screenshot 2024-12-18 at 17 23 29"
src="https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47"
/> |
#### Roles
Another visible change of this PR is the addition of `Timeline` and
`Notes` in the edit-role screen:
| Before | After |
| ------- | ------ |
| <img width="746" alt="Screenshot 2024-12-12 at 16 31 43"
src="https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43"
/> | <img width="738" alt="Screenshot 2024-12-12 at 16 32 53"
src="https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd"
/> |
We made sure that for migrated roles that hard `security.all` selected,
this screen correctly shows `security.all`, `timeline.all` and
`notes.all` after the privilege migration.
#### Timeline toast
There are tons of places in security solution where `Investigate / Add
to timeline` are shown. We did our best to disable all of these actions
but there is no guarantee that this PR catches all the places where we
link to timeline (actions). One layer of extra protection is that the
API endpoints don't give access to timelines to users without the
correct privileges. Another one is a Redux middleware that makes sure
timelines cannot be shown in missed cases. The following toast will be
shown instead of the timeline:
<img width="354" alt="Screenshot 2024-12-19 at 10 34 23"
src="https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3"
/>
### Changes to predefined security roles
All predefined security roles have been updated to grant the new
privileges (in ESS and serverless). In accordance with the migration,
all roles with `siem.all` have been assigned `siemV2.all`,
`timeline.all` and `notes.all` (and `*.read` respectively).
### 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/packages/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] 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.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
## Summary
This PR removes rendering of the Inference Endpoints UI from
`enterprise_search` for stack and instead utilizes the
`search_inference_endpoints` plugin to render the UI for both serverless
and stack. This can be done by utilizing the `search_navigation` plugin
for rendering the classic navigation for stack.
To support this change the `xpack.searchInferenceEndpoints.ui.enabled`
was updated to default to `true` instead of only being set for
serverless search. To account for this change I have added
`xpack.searchInferenceEndpoints.enabled: false` to the serverless
configs for both security and observability to ensure the
`search_inference_endpoints` plugin is disabled in both of those
projects.
### 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/packages/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
- [ ] 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This adds exclusions for deprecated "rsa2elk" integration packages to Serverless projects.
The following packages should be excluded from Serverless.
- bluecoat
- cylance
- f5
- fortinet_forticlient
- juniper_junos
- juniper_netscreen
- netscout
- radware
- tomcat
---------
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
## Summary
This PR discontinues Reporting from having dual models for determining
the privilege to generate a report, and uses Kibana feature privileges
as the single model that controls those privileges.
### Changes
1. Removes all logic that is based on following settings:
* `xpack.reporting.roles.enabled`
* `xpack.reporting.roles.allow`
The settings are still supported, but any features that use the settings
are removed.
2. Removes the detection of the settings from the Upgrade Assistant
integration
### Release note
The default system of granting users the privilege to generate reports
has changed. Rather than assigning users the `reporting_user` role,
administrators should create a custom role that grants report-creation
privileges using Kibana application privileges.
### 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
- [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.
Correlates with https://elasticco.atlassian.net/browse/ES-9856: assign
the built-in `reporting_user` role the necessary Kibana application
privileges, and make the role not marked as deprecated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This enables the knowledge base for the Serverless Search AI assistant.
It also renames a few options to align naming, including a rename for
the settings page in Observability's Serverless deployment to remove a
reference to Search.
This PR enables data_usage plugin for Serverless environment for all 3
solutions.
To manage feature availability added feature flag, which is turning Data
Usage off by default.
## Summary
This PR:
- Enables Inference Management in ES3
- Fixes small issues to make sure it works in ES3.
- Added FTR tests.
### 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.
- [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_node:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
