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>
The cloud-defend (Defend for Containers) integration is not supported with serverless. This excludes the integration package from the security serverless config, so it won't be available for users to install.
## Summary
This PR removes
`xpack.fleet.internal.registry.kibanaVersionCheckEnabled: false` from
`kibana.yml` in favor of changing the default value that Fleet
populates, so that we do not apply the Kibana version constraint to EPR
requests for >= 9.0 deployments.
Prior to this change, this setting was not applied to ESS deployments as
`kibana.yml` is overridden there.
I updated the related task in
https://github.com/elastic/kibana/issues/192624 to reflect this change.
## Summary
This adds the AI assistant to Serverless Elasticsearch. It also disables
the knowledge base, and disables a few config values we don't want users
to be able to set in that context.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elena Shostak <165678770+elena-shostak@users.noreply.github.com>
## Summary
Semantic text feature was disabled by default due to ML node unable to
scale down. With the relevant
[PR](https://github.com/elastic/elasticsearch/pull/114323) & subsequent
[fix](https://github.com/elastic/elasticsearch/pull/115189) merged, ML
node now auto scales when there is no activity. Therefore enabling
semantic_text feature in es3.
### Testing instructions
* start serverless instance
* visit index management index details page -> mappings
* Click Add field
* Confirm `semantic_text` is shown in the field type form
Closes#194933Closes#192282
## Summary
This PR updates the serverless project yml files to
- enable custom roles for Elasticsearch and Security projects
- enable multiple spaces (max 100) for all serverless project types
### Tests
Additionally, this PR adjust the serverless test suites. Originally,
testing of roles and spaces endpoints was achieved from the feature flag
test config. Now that these features are enabled by default, the tests
have been migrated to the standard serverless test configs.
Affected tests:
-
x-pack/test_serverless/api_integration/test_suites/common/management/spaces.ts
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/authorization.ts
-
x-pack/test_serverless/functional/test_suites/common/platform_security/navigation/management_nav_cards.ts
-
x-pack/test_serverless/functional/test_suites/common/platform_security/roles.ts
-
x-pack/test_serverless/functional/test_suites/common/spaces/spaces_management.ts
-
x-pack/test_serverless/functional/test_suites/common/spaces/spaces_selection.ts
- Feature flag configs/indices
- Project specific configs/indices
- Base serverless config
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
Enable Fleet UI for serverless search projects. This is needed to enable
upcoming agentless features.
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Julien Lind <julien.lind@elastic.co>
Fixes https://github.com/elastic/kibana/issues/190818
## Summary
Elasticsearch has added support for GeoIP, enabling the use of paid
GeoIP databases from MaxMind/IPInfo for more accurate and granular
geolocation data. As such we should add support to ingest pipelines UI
for making this available to the user.
* If the user doesn't have enough privileges, the "Manage Pipelines"
link and UI won't show.
* Users can add two types of databases through the UI: MaxMind and
IPinfo. Database names are predefined by ES, and the user cannot enter
their own.
* Certain types of databases (local and web) can be configured through
ES, and these will appear in the UI, but they cannot be deleted as they
are read-only.
* When configuring a `IP location` processor, the database field will
display a list of available and configured databases that the user can
select. It also allows for free-text input if the user wants to
configure a database that does not yet exist.
* The new IP location processor is essentially a clone of the GeoIP
processor, which we are moving away from due to copyright issues.
However, it was decided that GeoIP will remain as is for backward
compatibility, and all new work will only be added to IP location going
forward.
* I left a few mocks in the `server/routes/api/geoip_database/list.ts `
to try `local/web` types
## Release note
The Ingest Pipelines app now supports adding and managing databases for
the GeoIP processor. Additionally, the pipeline creation flow now
includes support for the IP Location processor.
<details>
<summary>Screenshots</summary>
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ignacio Rivas <rivasign@gmail.com>
Co-authored-by: Elena Stoeva <elenastoeva99@gmail.com>
Co-authored-by: Elena Stoeva <59341489+ElenaStoeva@users.noreply.github.com>
Co-authored-by: Matthew Kime <matt@mattki.me>
In this PR, I'm modifying the `config/serverless.yml` file to contain
`xpack.task_manager.claim_strategy: mget`. We've rolled out the mget
task claimer in phases using the kibana-controller, now that all
projects are using the mget task claiming strategy, we can move the
config here and cleanup all the places in the kibana-controller that set
this flag.
Once this commit rolls out to all serverless projects, I'll be able to
start cleaning up the kibana-controller.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
The Security Solution Entity Store feature will now be available by
default. However, there will be a flag that can be switched on, if
desired, to **disable** that feature entirely.
Regardless of whether this flag is enabled or not, Security's Entity
Store is still only fully enabled through an enablement workflow. In
other words, a Security Solution customer must turn on the feature
through an onboarding workflow in order to enable its features.
Additionally, we are disabling this feature in Serverless at first, to
perform proper Serverless load/performance testing. (We do not expect it
to be significantly different than ESS/ECH, but are doing so out of an
abundance of caution).
---------
Co-authored-by: Pablo Machado <pablo.nevesmachado@elastic.co>
## Summary
#### Different vCPUs ranges and enabling support for static allocations
based on the serverless project type
- Each serverless config yml, e.g.
[search.es.yml](84b3b79a15/config/serverless.es.yml (L61))
now contains parameters required for start model deployment:
```yml
xpack.ml.nlp:
enabled: true
modelDeployment:
allowStaticAllocations: true
vCPURange:
low:
min: 0
max: 2
static: 2
medium:
min: 1
max: 32
static: 32
high:
min: 1
max: 512
static: 512
```
Note: _There will be no static allocations option for serverless O11y
and serverless Security._
#### The minimum values of vCPUs
- 0 for the Low usage level on both serverless and ESS.
- 1 for the Medium and High usage levels on both serverless and ESS.
#### The default vCPUs usage levels
- Low in serverless.
- Medium in ESS and on-prem
### 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
This PR enables the `search_indices` plugin in serverless search. But
then gates it with a UI settings feature flag until we are ready to ship
the new onboarding experience to all users.
### Testing
Locally you can add this to your `kibana.dev.yml` to enable the FF:
```
uiSettings.overrides.searchIndices:globalEmptyStateEnabled: true
```
Or you can enable the ui setting via Dev Tools and refresh the browser:
```
POST kbn:/internal/kibana/settings/searchIndices:globalEmptyStateEnabled
{"value": true}
```
### 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] [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: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
## Summary
Removing search home usage from serverless search and enterprise search.
The search home page project is on hold while we re-assess requirements.
Until we know when we are starting that back up I'm removing the feature
flagged usage to simplify other work. When we spin this back up usage
will likely be different anyway with other projects like onboarding and
the updating navigation refactor in enterprise_search.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Updates our base version to 9.0.0
For reviewers: there are test skips in this pull request. Please assess
whether these failures should block merging as part of your review. If
not, we will track them in
https://github.com/elastic/kibana/issues/192624.
---------
Co-authored-by: Sebastián Zaffarano <sebastian.zaffarano@elastic.co>
Kibana should already support packages with spec version 3.2, update the
max version in serverless.
Supersedes part of https://github.com/elastic/kibana/pull/184792.
Co-authored-by: Jen Huang <its.jenetic@gmail.com>
## Summary
Resolves https://github.com/elastic/kibana/issues/182827
As the title says :)
This also corrects `spec.max` to `3.1`, which it should have been all
along.
Integrations available for Observability projects after change:
[Click
here](b9592e60-0bda-4597-b7fc-0e7ee5a673da)
Integrations available for Security projects after change:
[Click
here](f74142ae-88d8-4445-96f7-413c12a1434b)
