Closes https://github.com/elastic/kibana/issues/206126
## Summary
This PR displays a LogsDB index mode for `logs-*-*` data streams and
templates with the `logs-*-*` index pattern if the
`cluster.logsdb.enabled` setting is set to true and as "Standard" if
it's set to false. If the setting is not set, it is false by default in
stateful (and so "Standard" index mode) and true by default in
serverless (and so "LogsDB" index mode).
**How to test:**
In Stateful:
1. Create an index template with a `logs-*-*` index pattern
2. Create a `logs-*-*` data stream: `PUT _data_stream/logs-test-1`
3. Go to Index Management -> Index templates and click on the created
index templates. Verify that the index mode is correct (**NOTE:** In
stateful, the `cluster.logsdb.enabled` setting is `false` by default,
while in serverless it's `true` by default. Therefore, the index mode
should be `Standard` in stateful and `LogsDB` in serverless.
4. Go to Index Management -> Data Streams and find the created data
stream. Verify that the index mode is correct (**NOTE:** In stateful,
the `cluster.logsdb.enabled` setting is `false` by default, while in
serverless it's `true` by default. Therefore, the index mode should be
`Standard` in stateful and `LogsDB` in serverless.
5. In Console, set the `cluster.logsdb.enabled` setting:
```
PUT /_cluster/settings
{
"persistent" : {
"cluster.logsdb.enabled" : true
}
}
```
6. Go to the data stream/templates list and verify that the index mode
of the test data stream/template that we created is displayed as LogsDB
7. Change the cluster setting to `false` and verify that the index mode
is now displayed as Standard.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@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
Recently enabled ES flag in QA (see
https://github.com/elastic/serverless-gitops/pull/6185), caused Kibana
to begin rendering predefined roles on the roles management page. This
caused QA test failures. Skipping these tests will eliminate the noise
in the QA test alert channel while we resolve the issue.
Solution will be to make all predefined roles reserved so we can ensure
they are not rendered in Kibana.
cc @wayneseymour
## Summary
This PR in cloud https://github.com/elastic/cloud/pull/135346 is going
to pass an `onboarding_token` query string. I am just trying to
Intercept it and saved it. Therefore solution can streamline the Kibana
onboarding process for trial user.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#192718
## Summary
This PR add a deployment-agnostic testing environment for Observability
AI Assistant tests by unifying the duplicated tests for stateful and
serverless environments. It create the ObservabilityAIAssistantApiClient
to work seamlessly in both environments, enabling a single test to run
across stateful, CI, and MKI.
Initial efforts focus on deduplicating the `conversations.spec.ts` and
`connectors.spec.ts` files, as these already run in all environments.
Move / dedup the tests that exist in stateful and serverless. They run
in serverless CI but not MKI and add the skipMki tag.
`chat.spec.ts`
`complete.spec.ts`
`elasticsearch.spec.ts`
`public_complete.spec.ts`
`alerts.spec.ts`
`knowledge_base_setup.spec.ts`
`knowledge_base_status.spec.ts`
`knowledge_base.spec.ts`
`summarize.ts`
`knowledge_base_user_instructions.spec.ts`
## Summary
Resolves https://github.com/elastic/kibana/issues/192886
- Unskips `knowledge_base_user_instructions.spec.ts` in serverless
- stays skipped in mki due to proxy usage issue
- Duplicates new changes from non serverless
- Removes `skipInMKI` tags for:
`knowledge_base_setup.spec.ts`
`knowledge_base.spec.ts `
`knowledge_base_status.spec.ts`
If https://github.com/elastic/kibana/issues/192718 is merged before
this, I will move `knowledge_base_user_instructions.spec.ts` to
deployment agnostic. Otherwise It can be done in that PR or another.
## Summary
Functional tests for data usage UI.
- `data_streams` route is intercepted, due to filtering out zero size
data streams which will happen because metering api needs time to
aggregate data
- `autoops_api` is using the mock server as there will be no data for it
to return
- tests will only run in local serverless and not MKI due to using the
autoops mock server that won't return data for created data streams
- adds `interceptRequest` functionality to FTR `browser` service
## Tests
- data stream filter dropdown renders with created data streams of
`data_streams` response and are checked
- data stream filter dropdown renders badge with correct number of
selected data streams
- charts render from `data_streams` route response
- chart legends render with correct items
- popover renders for legend items
- links in popovers correctly navigate and update navigation between
different data stream items
## Summary
### Problem
Cookie authentication was introduced in Kibana for serverless internal
API tests via https://github.com/elastic/kibana/pull/192727.
The serverless tests for Obs AI Assistant still uses API key based auth.
### Solution
Change authentication to cookie based auth for internal APIs in
serverless 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] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Closes https://github.com/elastic/kibana/issues/183245Closes#197630
[Observability AI Assistant] Partially migrate to inference client
replacing `inferenceClient.chatComplete` to
`observabilityAIAssistantClient.chat` -
`observabilityAIAssistantClient.complete` does a bunch of stuff on top
of `chat`. keepping `observabilityAIAssistantClient.chat` as a wrapper
for now because it also adds instrumentation and logging.
- handling of 2 error cases to error handler
- `security_exception` due to lack of privileges. Metering api will
respond when one of the following isn't available as a user privilege
`monitor,view_index_metadata,manage,all`.
- `index_not_found_exception`. Metering api will respond with this when
no indices exist for the privileges it has access to or when no indices
are found.
- api integration tests for data_streams route for the following cases
- returns no data streams when there are none it has access to and
responds with appropriate message
- returns no data streams without necessary privileges and responds with
appropriate message
- returns data streams when user only has access to a subset of indices
with necessary privileges
- functional tests for same as above. these remain skipped due to not
being able to create data streams picked up by metering api since we
implemented filtering out zero storage size data streams, but useful for
local testing with some code changes.
### `security_exception` view
<img width="1555" alt="Screenshot 2024-12-04 at 1 14 10 PM"
src="https://github.com/user-attachments/assets/241a2eb8-1c77-4592-ba18-b971512e712e">
### `index_not_found_exception` view
<img width="1589" alt="Screenshot 2024-12-04 at 1 13 13 PM"
src="https://github.com/user-attachments/assets/12b68d66-9178-4957-b014-5765be348694">
---------
Co-authored-by: Ashokaditya <ashokaditya@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
--- EDIT ---
This PR also adds two privileges related to saved query APIs:
`savedQuery:read` and `savedQuery:manage`. These are given by default to
the same roles that already have access to the `query`-type saved
objects.
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
---------
Co-authored-by: Lukas Olson <lukas@elastic.co>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
This PR aims to decouple the feature IDs from the `consumer` attribute
of rules and alerts.
Towards: https://github.com/elastic/kibana/issues/187202
Fixes: https://github.com/elastic/kibana/issues/181559
Fixes: https://github.com/elastic/kibana/issues/182435
> [!NOTE]
> Unfortunately, I could not break the PR into smaller pieces. The APIs
could not work anymore with feature IDs and had to convert them to use
rule type IDs. Also, I took the chance and refactored crucial parts of
the authorization class that in turn affected a lot of files. Most of
the changes in the files are minimal and easy to review. The crucial
changes are in the authorization class and some alerting APIs.
## Architecture
### Alerting RBAC model
The Kibana security uses Elasticsearch's [application
privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-privileges.html#security-api-put-privileges).
This way Kibana can represent and store its privilege models within
Elasticsearch roles. To do that, Kibana security creates actions that
are granted by a specific privilege. Alerting uses its own RBAC model
and is built on top of the existing Kibana security model. The Alerting
RBAC uses the `rule_type_id` and `consumer` attributes to define who
owns the rule and the alerts procured by the rule. To connect the
`rule_type_id` and `consumer` with the Kibana security actions the
Alerting RBAC registers its custom actions. They are constructed as
`alerting:<rule-type-id>/<feature-id>/<alerting-entity>/<operation>`.
Because to authorizate a resource an action has to be generated and
because the action needs a valid feature ID the value of the `consumer`
should be a valid feature ID. For example, the
`alerting:siem.esqlRule/siem/rule/get` action, means that a user with a
role that grants this action can get a rule of type `siem.esqlRule` with
consumer `siem`.
### Problem statement
At the moment the `consumer` attribute should be a valid feature ID.
Though this approach worked well so far it has its limitation.
Specifically:
- Rule types cannot support more than one consumer.
- To associate old rules with a new feature ID required a migration on
the rule's SOs and the alerts documents.
- The API calls are feature ID-oriented and not rule-type-oriented.
- The framework has to be aware of the values of the `consumer`
attribute.
- Feature IDs are tightly coupled with the alerting indices leading to
[bugs](https://github.com/elastic/kibana/issues/179082).
- Legacy consumers that are not a valid feature anymore can cause
[bugs](https://github.com/elastic/kibana/issues/184595).
- The framework has to be aware of legacy consumers to handle edge
cases.
- The framework has to be aware of specific consumers to handle edge
cases.
### Proposed solution
This PR aims to decouple the feature IDs from consumers. It achieves
that a) by changing the way solutions configure the alerting privileges
when registering a feature and b) by changing the alerting actions. The
schema changes as:
```
// Old formatting
id: 'siem', <--- feature ID
alerting:['siem.queryRule']
// New formatting
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: 'siem.queryRule', consumers: ['siem'] }] <-- consumer same as the feature ID in the old formatting
```
The new actions are constructed as
`alerting:<rule-type-id>/<consumer>/<alerting-entity>/<operation>`. For
example `alerting:rule-type-id/my-consumer/rule/get`. The new action
means that a user with a role that grants this action can get a rule of
type `rule-type` with consumer `my-consumer`. Changing the action
strings is not considered a breaking change as long as the user's
permission works as before. In our case, this is true because the
consumer will be the same as before (feature ID), and the alerting
security actions will be the same. For example:
**Old formatting**
Schema:
```
id: 'logs', <--- feature ID
alerting:['.es-query'] <-- rule type ID
```
Generated action:
```
alerting:.es-query/logs/rule/get
```
**New formatting**
Schema:
```
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: '.es-query', consumers: ['logs'] }] <-- consumer same as the feature ID in the old formatting
```
Generated action:
```
alerting:.es-query/logs/rule/get <--- consumer is set as logs and the action is the same as before
```
In both formating the actions are the same thus breaking changes are
avoided.
### Alerting authorization class
The alerting plugin uses and exports the alerting authorization class
(`AlertingAuthorization`). The class is responsible for handling all
authorization actions related to rules and alerts. The class changed to
handle the new actions as described in the above sections. A lot of
methods were renamed, removed, and cleaned up, all method arguments
converted to be an object, and the response signature of some methods
changed. These changes affected various pieces of the code. The changes
in this class are the most important in this PR especially the
`_getAuthorizedRuleTypesWithAuthorizedConsumers` method which is the
cornerstone of the alerting RBAC. Please review carefully.
### Instantiation of the alerting authorization class
The `AlertingAuthorizationClientFactory` is used to create instances of
the `AlertingAuthorization` class. The `AlertingAuthorization` class
needs to perform async operations upon instantiation. Because JS, at the
moment, does not support async instantiation of classes the
`AlertingAuthorization` class was assigning `Promise` objects to
variables that could be resolved later in other phases of the lifecycle
of the class. To improve readability and make the lifecycle of the class
clearer, I separated the construction of the class (initialization) from
the bootstrap process. As a result, getting the `AlertingAuthorization`
class or any client that depends on it (`getRulesClient` for example) is
an async operation.
### Filtering
A lot of routes use the authorization class to get the authorization
filter (`getFindAuthorizationFilter`), a filter that, if applied,
returns only the rule types and consumers the user is authorized to. The
method that returns the filter was built in a way to also support
filtering on top of the authorization filter thus coupling the
authorized filter with router filtering. I believe these two operations
should be decoupled and the filter method should return a filter that
gives you all the authorized rule types. It is the responsibility of the
consumer, router in our case, to apply extra filters on top of the
authorization filter. For that reason, I made all the necessary changes
to decouple them.
### Legacy consumers & producer
A lot of rules and alerts have been created and are still being created
from observability with the `alerts` consumer. When the Alerting RBAC
encounters a rule or alert with `alerts` as a consumer it falls back to
the `producer` of the rule type ID to construct the actions. For example
if a rule with `ruleTypeId: .es-query` and `consumer: alerts` the
alerting action will be constructed as
`alerting:.es-query/stackAlerts/rule/get` where `stackRules` is the
producer of the `.es-query` rule type. The `producer` is used to be used
in alerting authorization but due to its complexity, it was deprecated
and only used as a fallback for the `alerts` consumer. To avoid breaking
changes all feature privileges that specify access to rule types add the
`alerts` consumer when configuring their alerting privileges. By moving
the `alerts` consumer to the registration of the feature we can stop
relying on the `producer`. The `producer` is not used anymore in the
authorization class. In the next PRs the `producer` will removed
entirely.
### Routes
The following changes were introduced to the alerting routes:
- All related routes changed to be rule-type oriented and not feature ID
oriented.
- All related routes support the `ruleTypeIds` and the `consumers`
parameters for filtering. In all routes, the filters are constructed as
`ruleTypeIds: ['foo'] AND consumers: ['bar'] AND authorizationFilter`.
Filtering by consumers is important. In o11y for example, we do not want
to show ES rule types with the `stackAlerts` consumer even if the user
has access to them.
- The `/internal/rac/alerts/_feature_ids` route got deleted as it was
not used anywhere in the codebase and it was internal.
All the changes in the routes are related to internal routes and no
breaking changes are introduced.
### Constants
I moved the o11y and stack rule type IDs to `kbn-rule-data-utils` and
exported all security solution rule type IDs from
`kbn-securitysolution-rules`. I am not a fan of having a centralized
place for the rule type IDs. Ideally, consumers of the framework should
specify keywords like `observablility` (category or subcategory) or even
`apm.*` and the framework should know which rule type IDs to pick up. I
think it is out of the scope of the PR, and at the moment it seems the
most straightforward way to move forward. I will try to clean up as much
as possible in further iterations. If you are interested in the upcoming
work follow this issue https://github.com/elastic/kibana/issues/187202.
### Other notable code changes
- Change all instances of feature IDs to rule type IDs.
- `isSiemRuleType`: This is a temporary helper function that is needed
in places where we handle edge cases related to security solution rule
types. Ideally, the framework should be agnostic to the rule types or
consumers. The plan is to be removed entirely in further iterations.
- Rename alerting `PluginSetupContract` and `PluginStartContract` to
`AlertingServerSetup` and `AlertingServerStart`. This made me touch a
lot of files but I could not resist.
- `filter_consumers` was mistakenly exposed to a public API. It was
undocumented.
- Files or functions that were not used anywhere in the codebase got
deleted.
- Change the returned type of the `list` method of the
`RuleTypeRegistry` from `Set<RegistryRuleType>` to `Map<string,
RegistryRuleType>`.
- Assertion of `KueryNode` in tests changed to an assertion of KQL using
`toKqlExpression`.
- Removal of `useRuleAADFields` as it is not used anywhere.
## Testing
> [!CAUTION]
> It is very important to test all the areas of the application where
rules or alerts are being used directly or indirectly. Scenarios to
consider:
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected as a superuser.
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected by a user with limited access to certain features.
> - The changes in this PR are backward compatible with the previous
users' permissions.
### Solutions
Please test and verify that:
- All the rule types you own with all possible combinations of
permissions both in ESS and in Serverless.
- The consumers and rule types make sense when registering the features.
- The consumers and rule types that are passed to the components are the
intended ones.
### ResponseOps
The most important changes are in the alerting authorization class, the
search strategy, and the routes. Please test:
- The rules we own with all possible combinations of permissions.
- The stack alerts page and its solution filtering.
- The categories filtering in the maintenance window UI.
## Risks
> [!WARNING]
> The risks involved in this PR are related to privileges. Specifically:
> - Users with no privileges can access rules and alerts they do not
have access to.
> - Users with privileges cannot access rules and alerts they have
access to.
>
> An excessive list of integration tests is in place to ensure that the
above scenarios will not occur. In the case of a bug, we could a)
release an energy release for serverless and b) backport the fix in ESS.
Given that this PR is intended to be merged in 8.17 we have plenty of
time to test and to minimize the chances of risks.
## FQA
- I noticed that a lot of routes support the `filter` parameter where we
can pass an arbitrary KQL filter. Why we do not use this to filter by
the rule type IDs and the consumers and instead we introduce new
dedicated parameters?
The `filter` parameter should not be exposed in the first place. It
assumes that the consumer of the API knows the underlying structure and
implementation details of the persisted storage API (SavedObject client
API). For example, a valid filter would be
`alerting.attributes.rule_type_id`. In this filter the consumer should
know a) the name of the SO b) the keyword `attributes` (storage
implementation detail) and c) the name of the attribute as it is
persisted in ES (snake case instead of camel case as it is returned by
the APIs). As there is no abstraction layer between the SO and the API,
it makes it very difficult to make changes in the persistent schema or
the APIs. For all the above I decided to introduce new query parameters
where the alerting framework has total control over it.
- I noticed in the code a lot of instances where the consumer is used.
Should not remove any logic around consumers?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I noticed a lot of hacks like checking if the rule type is `siem`.
Should not remove the hacks?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I hate the "Role visibility" dropdown. Can we remove it?
I also do not like it. The goal is to remove it. Follow
https://github.com/elastic/kibana/issues/189997.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Co-authored-by: Paula Borgonovi <159723434+pborgonovi@users.noreply.github.com>
## Summary
- update data_streams route to accept includeZeroStorage flag to make
testing easier. the metering api only collects data once every 30s and
that might be changed to being longer so we can't wait for data to be
aggregated. We can potentially surface this option to the user in the
future.
- unskip data stream api test. will enable in MKI after manual
confirmation it passes with a followup PR.
---------
Co-authored-by: Ash <1849116+ashokaditya@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/200899
Added Synthetics Sub-feature for managing private locations !!
User can configure a sub feature in a role under synthetics to allow
managing private locations ,
with role API it will be with
```
{
kibana: [
{
feature: {
uptime: [
'minimal_all',
'can_manage_private_locations',
],
},
spaces: ['*'],
},
],
}
```
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/f842da22-9c82-43d0-ad34-c6e19ea187c6">
Create/delete actions on UI will be disabled
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/1a164d85-357b-42f3-ae15-0682b2db6c75">
## Release note
If you have already modified sub feature for the synthetics/uptime
feature to disable user access for using elastic managed location,
addition of this feature means, they will also will not be able to
manage(add/delete) private locations. Though this will not impact usage
of private locations in monitors. If you want those users to have
ability to add/delete new private locations, you can enable that by
toggle this feature in role ui or via api.
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
Adds a bunch of UX updates based on the feedback after demo.
- [x] Tidy chart legend action popup and links
- [x] fix UX date picker invalid time (UX shows invalid time falsely)
- [ ] Tooltip for date filter
- [ ] send UTC time to requests (1:1 mapping for date-time picked vs
date-time sent)
- [x] Remove unusable common date filter shortcuts
- [x] data stream filter `select all`
- [x] data stream filter `clear all`
- [x] No charts empty state
- [x] filter in datastreams that have greater than `0` bytes storage
size
- [ ] Filter out system indices from data stream filter?
- [x] Taller filter popover list for larger lists
Follow up of https://github.com/elastic/kibana/pull/200731
### 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)
- [ ]
[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] 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_node:*` 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)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes [#198995](https://github.com/elastic/kibana/issues/198995)
Closes https://github.com/elastic/kibana/issues/198996
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate `traces` test folder to
Deployment-agnostic testing strategy.
It also adds support for deployment-agnostic snapshots validation
### How to test
- Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
- Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
- [ ] ~(OPTIONAL, only if a test has been unskipped) Run flaky test
suite~
- [x] local run for serverless
- [x] local run for stateful
- [x] MKI run for serverless
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
