## Summary
This PR adds validation only for internal routes that use the `rRule`
schema.
## Testing
1. Create a rule in main.
2. Snooze the rule by using the API as
```
POST /internal/alerting/rule/<ruleId>/_snooze
{
"snooze_schedule": {
"id": "e58e2340-dba6-454c-8308-b2ca66a7cf7b",
"duration": 86400000,
"rRule": {
"dtstart": "2024-09-04T09:27:37.011Z",
"tzid": "invalid",
"freq": 2,
"interval": 1,
"byweekday": [
"invalid"
]
}
}
}
```
4. Go to the rules page and verify that the rules are not loaded.
5. Switch to my PR.
6. Go to the rules page and verify that the rules load.
### 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: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#198774
## Summary
- There was a bug when submitting `rrule` with a `byweekday` I fixed
that validation to use a more inclusive regex. `byweekday` can be the
expected `MO`, `TU`, etc but also `-1FR` or `+3SA` where the number
corresponds to the week in a month.
- The model version for the maintenance window was incorrect so when
saving the SO the validation was failing. I fixed that and now we are
allowed to save `number[]` as expected.
- I removed some duplicated code and we now use the `rrule` schema from
the `common` folder
## Summary
This PR is followup to, https://github.com/elastic/kibana/pull/203503.
This PR adds a test to make sure that sub-feature description remains
accurate, and changes to hide the connector edit test tab and create
connector button when a user only has read access.
### Checklist
- [ ] [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
### To verify
1. Create a new read only role and disable EDR connectors under the
Actions and Connectors privilege
2. Create a new user and assign that role to user
3. Create a Sentinel One connector (It doesn't need to work, you can use
fake values for the url and token)
4. Login as the new user and go to the connector page in stack
management
5. Verify that the "Create connector" button is not visible
6. Click on the connector you created, verify that you can't see the
test tab
Resolves https://github.com/elastic/response-ops-team/issues/251
## Note
This PR includes some saved object schema changes that I will pull out
into their own separate PR in order to perform an intermediate release.
I wanted to make sure all the schema changes made sense in the overall
context of the PR before opening those separate PRs.
Update: PR for intermediate release here:
https://github.com/elastic/kibana/pull/203184 (Merged)
## Summary
Adds ability to run actions for backfill rule runs.
- Updates schedule backfill API to accept `run_actions` parameter to
specify whether to run actions for backfill.
- Schedule API accepts any action where `frequency.notifyWhen ===
'onActiveAlert'`. If a rule has multiple actions where some are
`onActiveAlert` and some are `onThrottleInterval`, the invalid actions
will be stripped and a warning returned in the schedule response but
valid actions will be scheduled.
- Connector IDs are extracted and stored as references in the ad hoc run
params saved object
- Any actions that result from a backfill task run are scheduled as low
priority tasks
## To Verify
1. Create a detection rule. Make sure you have some past data that the
rule can run over in order to generate actions. Make sure you add
actions to the rule. For testing, I added some conditional actions so I
could see actions running only on backfill runs using
`kibana.alert.rule.execution.type: "manual"`. Create actions with and
without summaries.
2. Schedule a backfill either directly via the API or using the
detection UI. Verify that actions are run for the backfill runs that
generate alerts.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
As part of v9.0 readiness, we reindex the indices in v.8 but still has
data from v.7x.
As a result of the process, the reindexed indices get `.reindexed-v8-`
prefix.
This PR add that prefix to the valid prefixes list.
# To verify:
Run Kibana and ES in 7.17 (use `-E path.data=your-data-path` to keep the
data in your local)
Create some rules that generate alerts (Observability rules to have AAD)
Let them run for a while.
Stop Kibana and ES, switch to 8.x branch and run ES and Kibana again
Open the Upgrade Assistant.
It should show the `.internal.alerts-*` indices
Click on them and start reindexing on the opened flyout.
Check that `.reindexed-v8-internal.alerts-*` index has been created
Let you rules run for a while again.
Your alerts should be updated and there shouldn't be any error on your
terminal.
---------
Co-authored-by: Ersin Erdal <ersin.erdal@elastic.co>
Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/180908
## Summary
**EDR Connector Subfeature Privilege**
This PR creates a new EDR connector sub-feature privilege under the read
privilege for connectors. The read privilege currently allows users to
execute connectors, and this new privilege will limit some of the
connectors that can be executed. When the EDR privilege is turned on,
users will be able to execute EDR connectors, and when it is off they
will not execute. This new privilege includes SentinelOne and
Crowdstrike connectors.
To determine which connectors are considered EDR connectors, we
leverage`getKibanaPrivileges` in the connector type definition. I
removed the restrictions to use this field only for system actions and
renamed `getSystemActionKibanaPrivileges` to
`getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to
the connector type definition to help disable testing/executing an
connectors that are restricted under a sub-feature.
**EDR Connector Execution for Testing**
The execution of EDR connectors using the API is limited to a single
sub-action for testing purposes. This ensures users can still
configure/test EDR connectors. In a separate
[PR](https://github.com/elastic/kibana/pull/204804), I added back the
SentinelOne and Crowdstrike params UIs with options restricted to one
sub-action.
**Rule API and Feature Configuration Updates**
Validation has been added to the rule APIs to enforce restrictions on
adding EDR connectors. The connector feature configuration has been
updated to include a new feature ID, EdrForSecurityFeature, which
ensures that EDR connectors are hidden on the rule form.
Note: I saw that EDR connectors are also temporarily restricted in the
Security Solution UI. To streamline this, I removed the
`isBidirectionalConnectorType` check in `action_type_registry.ts`.
Instead, I removed `SecurityConnectorFeatureId` from the
`supportedFeatureIds` of the SentinelOne connector type definition.
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
## To test
**EDR Connector Subfeature Privilege**
1. Create a new role and disable EDR connectors under the Actions and
Connectors privilege
2. Create a new user and assign that role to user
3. Create a Sentinel One connector (It doesn't need to work, you can use
fake values for the url and token)
4. Login as the new user and run the following in Dev Tools to verify
that you aren't authorized execute the Sentinel One connector
```
POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute
{
"params": {
"subAction": "getAgents",
"subActionParams": {}
}
}
```
7. Update the role to enable EDR connectors and repeat the steps to
verify that you are authorized to run the connector. (It will fail but
verify it's not Unauthorized)
**EDR Connector Execution for Testing**
1. Enable the EDR connectors privilege in the role you created above and
log in as the user you created above.
2. Run the following in Dev Tools to verify that you are authorized
execute the Sentinel One connector using only the `getAgents`
sub-action. (It will fail but verify it's not `Unauthorized`)
```
POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute
{
"params": {
"subAction": "getAgents",
"subActionParams": {}
}
}
```
3. Run it again but replace the `subAction` with `isolateHost`. Verify
that you get an unauthorized error.
**Rule API and Feature Configuration Updates**
1. 1. Enable the EDR connectors privilege in the role you created above
and log in as the user you created above.
2. Go to Stack Management
3. Try to create a rule, and verify that you don't see the SentinelOne
connector.
4. Try to create a rule using the API and add your SentinelOne
connector, verify that the API throws an error.
```
POST kbn:/api/alerting/rule
{
"tags": [],
"params": {},
"schedule": {
"interval": "1m"
},
"consumer": "alerts",
"name": "Always firing rule",
"rule_type_id": "example.always-firing",
"actions": [
{
"group": "small",
"id": "$CONNECTOR_ID",
"params": {
"subAction": "isolateAgent",
"subActionParams": {}
},
"frequency": {
"notify_when": "onActionGroupChange",
"throttle": null,
"summary": false
}
}
],
"alert_delay": {
"active": 1
}
}
```
5. You can test the same behaviors when trying to add a SentinelOne
connector to existing rules.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Connected with #195187
## Summary
- Moved params of synthetic status monitor rule type to
`/response-ops/rule_params/synthetics_monitor_status/`
- Moved params of TLS rule type to
`/response-ops/rule_params/synthetics_tls/`
I created a follow-up issue to handle the places where io-ts is used for
params validation in `observability/plugins/synthetics`. #205207
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/180908
## Summary
This change is part of adding granular RBAC for SecuritySolution
connectors. In this PR, I updated the action executor to log API key
details when a connector is executed by a user authenticated via API
key. The public name and id of the API key are now included in the event
log.
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
### To verify
1. Create an API key
2. Create a connector that will successfully run, it doesn't have to be
SentinelOne.
3. Run the following with the ID and correct params for your connector
type.
```
curl -X POST "http://localhost:5601/api/actions/connector/$CONNECTOR_ID/_execute" -H 'Authorization: ApiKey $API_KEY' -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d'
{
"params": {
"message": "hi"
}
}'
```
4. Go to dev tools and run the following query to verify that the API
key information is stored in the event log
```
GET /.kibana-event-log*/_search
{
"sort": [
{
"@timestamp": {
"order": "desc"
}
}
],
"query": {
"bool": {
"filter": [
{
"term": {
"event.provider": {
"value": "actions"
}
}
}
]
}
}
```
## Summary
Reverts the `getMutedAlerts` filter to use rule ids instead of rule type
ids that caused the muted alerts state to be always empty.
## To verify
1. Create a rule that fire alerts
2. Navigate to `Stack management > Alerts`
3. Click on any alert actions menu (•••)
4. Toggle on and off the alert muted state and check that the action
updates accordingly and the slashed bell icon appears in the status cell
when muted
## Release note
Fix alert mute/unmute action
Fixes#203472
## Summary
|Rule|Group info|
|---|---|
||
@elastic/response-ops What sort of test do you suggest to add for this
case?
### 🧪 How to run test
#### Deployment agnostic
- [x] Test on MKI
```
// Server
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
// Test
node scripts/functional_test_runner --config=x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="ElasticSearch query rule"
```
## 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
Issue: https://github.com/elastic/kibana/issues/151461
Removes all reference to ephemeral tasks in the alerting and actions
plugin. As well as unit and E2E tests while maintaining backwards
compatibility for `xpack.alerting.maxEphemeralActionsPerAlert` flag.
### 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>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Authz API migration for authorized routes
This PR migrates `access:<privilege>` tags used in route definitions to
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)
### **Before migration:**
Access control tags were defined in the `options` object of the route:
```ts
router.get({
path: '/api/path',
options: {
tags: ['access:<privilege_1>', 'access:<privilege_2>'],
},
...
}, handler);
```
### **After migration:**
Tags have been replaced with the more robust
`security.authz.requiredPrivileges` field under `security`:
```ts
router.get({
path: '/api/path',
security: {
authz: {
requiredPrivileges: ['<privilege_1>', '<privilege_2>'],
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. You might need to update your tests to reflect the new security
configuration:
- If you have tests that rely on checking `access` tags.
- If you have snapshot tests that include the route definition.
- If you have FTR tests that rely on checking unauthorized error
message. The error message changed to also include missing privileges.
## 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: Christos Nasikas <christos.nasikas@elastic.co>
Resolves https://github.com/elastic/kibana/issues/192686
## Summary
Creates a background task to search for removed task types and mark them
as unrecognized. Removes the current logic that does this during the
task claim cycle for both task claim strategies.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/190801 !!
Handle private locations simultaneous edits !!
Registered a new saved object to handle private locations properly.
Instead of using a singleton, now each private location will be
represented by it's own saved object.
### Existing private locations
When we are doing any write operation, we migrate them to new kind of
saved object and remove the legacy saved object type.
### Testing
- Create multiple private locations on main
- Switch to branch and create few more locations
- Make sure all private locations are editable, deleteable and have been
migrated to new saved object types in the course
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Jira Cloud and Datacenter work using the same API urls. In this PR we
remove the calls to the capabilities API which was being used to know
the API url we needed to hit
To test it:
- Create Jira Cloud and Datacenter connectors
- Test all use cases related to them
Related to https://github.com/elastic/kibana/issues/189017
## Research Work
**getCapabilities, createIncident and getIncident** are always the same,
therefore ignored for the rest of this document
- getCapabilities: `/rest/capabilities`
- createIncident: `/rest/api/2/issue`
- getIncident: `/rest/api/2/issue`
## API links
- Cloud:
https://developer.atlassian.com/cloud/jira/platform/rest/v2/intro/#version
- DC: https://docs.atlassian.com/software/jira/docs/api/REST/9.17.0/
### Expected API urls based on the API links
- Get issue types
- Cloud: `GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes`
- DC:`GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes`
- Get fields by issue type
- Cloud: `GET
/rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`
- DC:
`GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`
### API we hit
- Get issue types
- Cloud `GET
/rest/api/2/issue/createmeta?projectKeys=ROC&expand=projects.issuetypes.fields`
(variable name we are using is `getIssueTypesOldAPIURL`)
- DC `GET /rest/api/2/issue/createmeta/RES/issuetypes` (variable name is
`getIssueTypesUrl`)
- Get fields by issue type
- Cloud `GET
/rest/api/2/issue/createmeta?projectKeys=ROC&issuetypeIds={issueTypeId}&expand=projects.issuetypes.fields`
(variable name is `getIssueTypeFieldsOldAPIURL`)
- DC `GET /rest/api/2/issue/createmeta/RES/issuetypes/{issueTypeId}`
(variable name is `getIssueTypeFieldsUrl`)
#### Analysed use cases to retrieve API urls we hit
- created a case with JIRA Cloud as Connector
- did a connector test with JIRA Cloud as connector
- created a case with JIRA DC as connector
- did a connector test with JIRA DC as connector
### Conclusions
- We are not using the right endpoints for Cloud, we should update them
to use the same endpoints.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: adcoelho <antonio.coelho@elastic.co>
Co-authored-by: Antonio <antoniodcoelho@gmail.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Closes#183378Closes#179095
## Summary
This PR moves the Custom threshold rule duplicated API integration tests
to the deployment agnostic test.
## How to run
To run 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="Custom Threshold rule"
```
To run 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="Custom Threshold rule"
```
### TODO
- [x] Test in MKI before merging
#### How to run tests on MKI
According to this
[discussion](https://github.com/elastic/observability-dev/issues/3519#issuecomment-2379914274),
we should test in MKI environment before merging. For details on how to
run in MKI, see [this section of the
document](https://docs.google.com/document/d/1tiax7xoDYwFXYZjRTgVKkVMjN-SQzBWk4yn1JY6Z5UY/edit#heading=h.ece2z8p74izh)
and [this
readme](https://github.com/elastic/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
All lifecycle rule types have been migrated to use the alerting
framework alerts client so the lifecycle executor in the rule registry
can be removed since it is no longer in use.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/response-ops-team/issues/250
## Summary
This PR eliminates the alerting RBAC exemption code. It removes all
references to `getAuthorizationModeBySource` and
`bulkGetAuthorizationModeBySource`, along with the corresponding legacy
RBAC usage counters. Additionally, downstream code paths that rely on
RBAC for authorization have been updated, and all related test cases
have been removed.
Resolves https://github.com/elastic/kibana/issues/90382
## Summary
Removes legacy action APIs for 9.0 and updates all tests that still used
the legacy APIs to use the current APIs. Also did some renaming of
action -> connector in the files I had to touch.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/response-ops-team/issues/255
In this PR, I'm changing the type of error thrown when connector
parameter validation fails so it indicates it's a user type of error.
This will allow us to exclude these errors from our serverless
monitoring given the users define the parameters the connectors receive
when they run. Mainly via alerting rule mustache templates, which are
easy to render empty strings and such.
Part of #183378
## Summary
This PR moves the first Custom threshold rule test to the deployment
agnostic test. The rest will follow in a follow-up PR.
## How to run
To run 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="Custom Threshold rule"
```
To run 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="Custom Threshold rule"
```
### TODO
- [x] https://github.com/elastic/kibana/pull/195890
- [x] Test in MKI before merging
#### How to run tests on MKI
According to this
[discussion](https://github.com/elastic/observability-dev/issues/3519#issuecomment-2379914274),
we should test in MKI environment before merging. For details on how to
run in MKI, see [this section of the
document](https://docs.google.com/document/d/1tiax7xoDYwFXYZjRTgVKkVMjN-SQzBWk4yn1JY6Z5UY/edit#heading=h.ece2z8p74izh)
and [this
readme](https://github.com/elastic/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki).
## Summary
Fixes#192957
Removes the `internal/_find` route from public access by moving the
hard-coded `options` into the route builder functions.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
