Resolves#188428
## Summary
- Add callout in serverless to indicate that initial data backfill is
limited to 7 days.
- If prevent data backfill is checked, transform will still use the SLO
delay for the filter range.
- If serverless and prevent data backfill is not checked, data backfill
is hard coded to 7 days, the lowest rolling time window option. Time
window will not be rounded down.
<img width="980" alt="Screenshot 2025-01-29 at 11 18 01 AM"
src="https://github.com/user-attachments/assets/b6481ef9-cc0e-4403-8309-50b6d8f37e70"
/>
## 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 adds the following parameters to the `INIT` engine API:
* `frequency`: the transform run frequency
* `timeout`: the timeout for the initial creation of the transform
* `docsPerSecond`: transform throttling option. See
[here](https://arc.net/l/quote/vxcmfnhh)
* `delay`: The transform delay duration. See
[here](https://arc.net/l/quote/mzvaexhv)
Coming soon
In addition, the PR adds these fields to the Saved Object with the
engine descriptor, as well as providing a migration with the appropriate
backfilling.
Finally, there are some utility function that were/are helpful in
working with objects.
## How to test
*NOTE*: Always make sure the security default data view exists. Easiest
way it to just navigate to some Security UI.
### Checking the new defaults
1. Initialize an engine via dev tools by calling: `POST
kbn:/api/entity_store/engines/<entity_type>/init {}`
2. Call `GET kbn:/api/entity_store/status`. This response should now
contain all the default optional values.
### Observing the parameters are being applied
1. Initialize an engine via the API. This time pass any of the `timeout,
frequency, delay and docsPerSecond` options in the request body.
2. Once the `status` changes to `started`, query the respective
transform: `GET
_transform/entities-v1-latest-security_<entity_type>_default`
3. Check that the parameters have been applied to the transform
### Checking Saved Object Migration
1. Check out `main`.
2. Initialize the store.
3. Query `GET kbn:/api/entity_store/status`. Note down the fields in the
engine object.
4. Check out this branch.
5. Restart kibana.
6. Query `GET kbn:/api/entity_store/status` again. Observe the new
fields have been added and backfilled
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
## Summary
All tests in
`x-pack/test/spaces_api_integration/deployment_agnostic/security_and_spaces/stateful.config_basic.ts`
are intended to be run only with `basic` license, since FIPS overrides
it we need to skip that test for FIPS.
### 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 removes Web Crawler connector creation and management from
enterprise_search plugin. Because a large part of that was included in
in the legacy create index flow this PR also removes the legacy search
create index page in favor of the search_indices create index page.
### Checklist
- [ ]
[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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### Identify risks
I want to do some more regression testing on this one because I had to
delete whole folders of code. Types and unit tests are still passing but
I'm still afraid I might have missed something.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Currently, the deprecation warning message for the
`search:includeFrozen` advanced setting says it will be removed in 9.0:
After some discussions with ES, we are keeping this parameter around
until 9.0, so this PR updates the warning message to reflect this.
## Summary
Collects two events of graph visualization usage
1. When graph preview is shown - allows to determine how many users
ingested data that is graph compliant
2. When graph investigation component is visible - allows to determine
how many users entered the investigation user flow
**How to test:**
- Enable the feature flag
`kibana.dev.yml`:
```yaml
uiSettings.overrides.securitySolution:enableVisualizationsInFlyout: true
uiSettings.overrides.securitySolution:enableGraphVisualization: true
```
- Load mocked data:
```bash
node scripts/es_archiver load x-pack/test/cloud_security_posture_functional/es_archives/logs_gcp_audit \
--es-url http://elastic:changeme@localhost:9200 \
--kibana-url http://elastic:changeme@localhost:5601
node scripts/es_archiver load x-pack/test/cloud_security_posture_functional/es_archives/security_alerts \
--es-url http://elastic:changeme@localhost:9200 \
--kibana-url http://elastic:changeme@localhost:5601
```
- Make sure you include data from Oct 13 2024. (in the video I use Last
year)
- Run in dev tools:
```
POST kbn:/internal/telemetry/clusters/_stats?pretty=true&apiVersion=2
{
"unencrypted": true,
"refreshCache": true
}
```
- Check if the ui_counters were reported
**Resolves:** https://github.com/elastic/security-team/issues/10410
## Summary
We want to make Rule Customization available at higher license tiers.
### **Intended Workflows/UX**
#### **Basic/Platinum/Security Essentials License Tiers**
- **Editing Prebuilt Rules:**
- Allow the 8.16 behavior: only actions, exceptions, snoozing, and
enable/disable options can be modified.
- On the rule editing page, all tabs except *Actions* are disabled.
Disabled tabs will display a hover explanation:
- "Upgrade to Enterprise to enable prebuilt rule customization" for ECH.
- "Upgrade to Security Complete to enable prebuilt rule customization"
for Serverless.
<img width="356" alt="image"
src="https://github.com/user-attachments/assets/72e60933-aaaf-45a0-9660-4cd066d3afec"
/>
- Rule editing via API is not restricted (tracked separately:
https://github.com/elastic/security-team/issues/11504.
- **Bulk Actions:**
- Modifications to rule content via bulk actions are not allowed.
Prebuilt rules are excluded from bulk actions if the license level is
insufficient. Users will see an explanation for the exclusion.
- Serverless
<img width="737" alt="image"
src="https://github.com/user-attachments/assets/99fef72f-dd38-4c73-a9e3-7b4c8018b4ed"
/>
- ECH
- On the API level (`_bulk_action`), an error is returned if a user
tries to modify a prebuilt rule without the required license. Response
in this case looks like this:
```json
{
"statusCode": 500,
"error": "Internal Server Error",
"message": "Bulk edit failed",
"attributes": {
"errors": [
{
"message": "Elastic rule can't be edited",
"status_code": 500,
"rules": []
}
]
}
}
```
- **Rule Updates:**
- Updates are restricted to Elastic’s incoming updates only.
- The rule upgrade flyout is in read-only mode.
<img width="949" alt="image"
src="https://github.com/user-attachments/assets/16a56430-63e6-4096-8ffd-b97f828abdd4"
/>
- For previously customized rules where customization is now disabled
due to insufficient licensing, a notification will appear on the upgrade
flyout, clarifying that only an upgrade to Elastic's version is
available.
- On the API level (`_perform`), only requests with `pick_version =
target` are permitted. Requests with `rule.fields` values are not
allowed.
API response when `pick_version` is not `target`:
```json
{
"message": "Only the 'TARGET' version can be selected for a rule update;
received: 'CURRENT'",
"status_code": 400
}
```
API response when the `fields` value is provided:
```json
{
"message": "Rule field customization is not allowed. Received fields:
name, description",
"status_code": 400
}
```
- **Customized Rules:**
- Existing customizations remain intact, and the “Modified” badge is
retained
- On the rule management, monitoring, and update tables:
- On the rule update flyout:
- On the rule details page:
- When we edit a rule with customizations (e.g., change rule's actions),
the rule should stay marked as customized
- **Import/Export Scenarios:**
- These are handled separately
(https://github.com/elastic/security-team/issues/11502)
#### **Enterprise/Security Complete License Tiers**
- All rules can be fully edited
- Upgraded prebuilt or customized rules will have an editable view,
enabling full customization
Allow inherit/dsl lifecycles on unwired streams:
- inherit is a noop. it keeps the data streams lifecycle configuration
untouched
- dsl will apply a retention if the data stream is either unmanaged or
already using a dsl
Since we're still discussing how to apply ilm/fields changes on unwired
streams, ilm is currently disabled.
### Testing
- update an unmanaged/ilm/dsl unwired stream
```
PUT kbn:/api/streams/logs-foo-default
{
"stream": {
"ingest": {
"lifecycle": {
"dsl": {}
},
"routing": [],
"processing": [],
"unwired": {}
}
},
"dashboards": []
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Background
This change introduces a new Kibana task within the Security solution.
When the Security solution's entity store feature is enabled, the task
is scheduled in order to continuously reflect changes to the Security
solution's default data view, thereby updating the Transform associated
with the Entity Store when necessary.
# Implementation notes
A key problem when updating/upgrading a transform in the background is
that Elasticsearch requires a user to make the request for these
changes, but no "user" is present in background tasks. The internal
Kibana user does not suffice, because it does not always have access to
the underlying indices.
To accomplish the above, this PR leverages the Entity Manager's ability
to store the API Key of the user who installed the entity store, and
makes any associated changes to the Transform using that user's stored
API key. Said API key is encrypted, and uses a deterministic ID per
installed space in order to support later retrieval.
A single API key is installed per space, meaning multiple entity
"engines" in a space will leverage a single API key for updates.
# Steps to test locally
1. Pull down the code
2. To assist with a quicker feedback loop, manually edit the task's
`interval` constant to a low value, such as `1m`. This value can be
found
[here](x-pack/solutions/security/plugins/security_solution/server/lib/entity_analytics/entity_store/tasks/data_view_refresh/constants.ts)
3. Start Kibana
4. Load desired entity test event data. (For example, the internal
[security-documents-generator](https://github.com/elastic/security-documents-generator)
repository's `yarn start entity-store` command can be used)
5. Enable the Security Entity Store by navigating to "Management->Entity
Store"
6. Validate the list of indices in the current transform by navigating
to `/app/management/data/transform` in Kibana, and clicking
"entities-v1-latest-security_host_default->JSON", looking for the
`source.index` field
7. Update the security default data view's index patterns to include a
new pattern. To do so, navigate to `/app/management/kibana/dataViews` in
Kibana, click the data view with the "Security Data View" badge, click
edit, and change the "Index pattern" by adding a comma and a new pattern
to the end, such as `,some-cool-pattern-*`. Save the change.
8. Wait the appropriate amount of time, as defined in step 2.
(Optionally check the Kibana console logs for activity.)
9. Once again, validate the list of indices within the transform as in
step 6, but this time see that the new index pattern is included.
---------
Co-authored-by: Pablo Machado <pablo.nevesmachado@elastic.co>
Replacing links to the serverless java client with the standard client
following merging of the two.
---------
Co-authored-by: Sylvain Wallez <sylvain@bluxte.net>
## 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>
## Summary
Adding custom `ScoutLogger` class to use across its services so that we
can better read logs related only to test framework runner.
We can also later migrate from `ToolingLog` to something better
integrated with Playwright to unify logs from different levels
https://github.com/elastic/kibana/issues/203591
To make sure we use the same instance, I converted few core services
(logger, kbnClient, esClient, esArchiver) to singletons.
Log output example:
```
Running 1 test using 1 worker
› should allow removing the dashboard panel after the underlying saved search has been deleted @svlSecurity @svlOblt @svlSearch @ess
debg [scout] [service] logger
info [scout] [config] Reading test servers confiuration from file: /Users/dmle/github/kibana/.scout/servers/local.json
debg [scout] [service] config
debg [scout] [service] esClient
debg [scout] [service] kbnClient
debg [scout] [service] esArchiver
debg [scout] [service] uiSettings
debg [scout] Requesting url (redacted): [http://localhost:5620/api/status]
info [scout] [x-pack/test/functional/es_archives/logstash_functional] Loading "mappings.json"
info [scout] [x-pack/test/functional/es_archives/logstash_functional] Loading "data.json.gz"
info [scout] [x-pack/test/functional/es_archives/logstash_functional] Skipped restore for existing index "logstash-2015.09.22"
info [scout] [x-pack/test/functional/es_archives/logstash_functional] Skipped restore for existing index "logstash-2015.09.20"
info [scout] [x-pack/test/functional/es_archives/logstash_functional] Skipped restore for existing index "logstash-2015.09.21"
```
## Summary
This ticket fixes#207183, #207040, #207039
Most solutions were just increasing `cy.get` timeouts.
~~However, #207183 was being caused by undefined `trend` timeseries
being passed to the metric chart. I think this is a shortcoming of the
the mobile data generation, as I couldn't reproduce this with real data.
Either way, I improved the page by adding empty arrays if trend is
undefined.~~
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
Note: It looks like the crashing issue I encountered was already fixed :
0dfe806aaf (diff-8370cf1dc84ed3a7c7b5038237ad48f1196f516fde94152ccda01d45e9234318R162)
## Summary
This PR adds an "All logs" ad hoc (temporary) data view to the Discover
Observability root profile based on the central log sources setting,
allowing quick access to logs (with the most up to date log sources)
without needing to first manually create a data view:
To support this, a new `getDefaultAdHocDataViews` extension point has
been added to Discover, allowing profiles to specify an array of ad hoc
data view specs would should be created by default when the profile is
resolved, and automatically cleaned up when the profile changes or the
user leaves Discover.
Resolves#201669.
Resolves#189166.
### Notes
- The "All logs" ad hoc data view should only appear when using the
Observability Solution view (in any deployment type).
- Data view specs returned from `getDefaultAdHocDataViews` must include
consistent IDs across resolutions in order for Discover to manage them
correctly (e.g. to find and reload the data view after a page refresh).
Situations where we'd expect a change in ID (e.g. when saving to a
Discover session) are handled internally by Discover.
- To avoid a breaking change, the returned ad hoc data views have no
impact on the default data view shown when navigating to Discover. If
any persisted data views exist, one of them will be used as the default.
If no persisted data views exist, the first entry of the array returned
by `getDefaultAdHocDataViews` will be used as the default.
- We still want to notify users in Discover when they have no ES data at
all, and prompt them to install integrations. For this reason, the "no
data" page is still shown in Discover even if there are default profile
ad hoc data views (unlike if there are persisted data views, in which
case we use the default and hide the "no data" page).
- When saving a Discover session that uses a default profile ad hoc data
view, the data view will be copied on save as `{DATA_VIEW_NAME} (copy)`.
This allows us to assign a unique ID to the version that gets saved with
the Discover session, and avoids having to choose between the profile
data view or the embedded data view when reopening the session, which
has drawbacks:
- If choosing the profile data view, the Discover session may display
incorrectly if the log sources setting changed since it was saved, and
the user would no longer be able to view the session as it was intended
without first modifying the setting to the expected value.
- If choosing the embedded data view, the replacement shown after
opening the Discover session may not reflect the latest log sources
setting until a new session is started, and there would be no way for
the user to migrate the session to use the latest version of the profile
data view.
### 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)
- [ ]
[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)
- [ ] 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_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Closes https://github.com/elastic/kibana/issues/186266
## Release notes
Enhanced Role management to manage larger number of roles by adding
server side filtering, pagination and querying.
## Summary
- Replaced the usage of Get Roles API with Query Role API
- Added server side pagination and filtering with a maximum limit of
10000 keys (default for max results on index). Added new label to
indicate that we show only 10k results.
- Search box replicates client side implementation by only filtering on
Role names.
### Run locally
Start ES ~with the JVM option to enable this feature~:
```
yarn es snapshot --license=trial
```
Start Kibana normally
```
yarn start --no-base-path
```
Navigate to Stack Management > Roles and verify the same behavior as the
screen recording below
### Screen recording
https://github.com/user-attachments/assets/a447e7df-8aa1-4044-a6b2-0aafe56844a9
## Technical notes
- Client side EuiInMemory table has been replaced by EuiSearchBar,
EuiBasicTable and Filters
- One new Kibana endpoint added
- `roles/_query`
- Replicates existing get_role endpoint by being public and added to
Open API spec
- Extra logic to handle previously UI only filter to show/hide reserved
roles
- Parse the query to construct the correct DSL if the filter is present
- Update Get All Roles by Space internal API to use the Query Role and
filter by space id using query DSL.
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Addresses https://github.com/elastic/kibana/issues/207350
Follow-up to https://github.com/elastic/kibana/pull/207413
## Summary
This PR adds validation to the index settings step in the template
creation flow so that the `index.number_of_shards` setting can only be
set to 1 if the Lookup index is selected.
<img width="900" alt="Screenshot 2025-01-28 at 15 33 59"
src="https://github.com/user-attachments/assets/a867fc6d-460d-4ab6-86b2-2ec54ac7203f"
/>
How to test:
1. Go to Index Management -> Index templates and start creating a
template
2. In the Logistics step, select Lookup index mode
3. In the index settings step, add the `index.number_of_shards` setting
and verify that only the values `1` and `null` are allowed.
4. Change the index mode and verify that for all other index modes,
there is no restriction on this index setting.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
