[RAM] .es-query and .observability.rules.threshold RBAC #166032
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… in O11Y and Stack Management (#162605) ## Summary Resolves: - #162484 - #160677 This PR adds the ability for `logs` and/or `infrastructure` only users to create and modify ES Query and new Generic Threshold rules. The `ensureAuthorized` function is modified and simplified to support this use case, by skipping producer authorization and only authorizing for consumers. When the consumer is `alerts`, we will consider this legacy and replace it with the rule’s producer (`consumer = ruleType.producer`) There is now a dropdown in the rule form to prompt the user when creating ES Query/Generic threshold rules to select the consumer based on their authorized consumers (we can no longer use `alerts` for these). If there is only 1 option, then the dropdown will not be shown and the option will be chosen automatically. Generic threshold rules will have the following possible consumers: - slo - infrastructure - logs - apm - uptime ES query rules will have the following possible consumers: - slo - infrastructure - logs - apm - uptime - stackAlerts ## To Test: ### Single Consumer: 1. Create a user with only `logs` feature enabled (ensuring `stackAlerts` is not enabled). 2. Navigate to the O11Y rule management page 3. Click the create rule button 4. Assert that both ES query and generic threshold rules are available 5. Click ES query and fill out the relevant information and create the rule 6. Assert that the rule created has `logs` set in the `consumer` field 7. Repeat 5-6 for the generic threshold rule 8. Repeat 2-7 but on the Stack Management rules page 9. Repeat 1-8 for the `infrastructure` feature. ### Multiple Consumers: 1. Create a user with `logs`, `infrastructure` and `apm` features enabled (ensuring `stackAlerts` is not enabled). 2. Navigate to the O11Y rule management page 3. Click the create rule button 4. Assert that both ES query and generic threshold rules are available 5. Click ES query and fill out the relevant information and create the rule 6. A dropdown should prompt the user to select between 1 of the 3 consumers, select 1 7. Assert that the rule was created with the selected consumer 8. Repeat 5-7 for the generic threshold rule 9. Repeat 2-8 but on the Stack Management rules page   ### 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 <[email protected]>
…5182) ## Summary This PR is here to update the alerting authorization model to allow `.es-query` and `observability.rules.threshold` to work with different consumers. We also the rule find's API to allow to filter on consumers. We update the alert client from the rule_registry plugin to get the alert index through the rule type and the alerting plugin like we did for the search strategy. ### 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 <[email protected]>
XavierM
added
release_note:enhancement
Team:ResponseOps
|
Pinging @elastic/response-ops (Team:ResponseOps) |
botelastic
bot
added
Team:APM
|
Pinging @elastic/apm-ui (Team:APM) |
|
Pinging @elastic/uptime (Team:uptime) |
XavierM
changed the title
…bana into o11y-rbac-rule-feature-branch
mikecote
approved these changes
Sep 21, 2023
maryam-saeidi
approved these changes
Sep 21, 2023
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
delanni
added a commit
that referenced
this pull request
Sep 22, 2023
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 22, 2023
…167026) ## Summary There was an accidental race-condition on a variable re-name and usage between elastic#166032 & elastic#166603. This PR intends to correct that. (cherry picked from commit e2a7157)
This was referenced Sep 26, 2023
2 tasks
cnasikas
added a commit
that referenced
this pull request
Sep 30, 2024
…sumers (#192321) ## Summary Alerts use its own RBAC model. The RBAC relies on a property called `consumer`. The consumer is tight coupled with the feature ID. It denotes the user's access to the rule and the alerts. For example, a user with access to the "Logs" feature has access only to alerts and rules with the `consumer` set as `logs`. Users can create an ES Query rule from Discover. When the feature was [implemented](#124534) (v8.3.0) the consumer was set to `discover`. Then it [changed](#166032) (v8.11.0) to `stackAlerts` (visible only on the stack management page) and then [to](#171364) (v8.12.0) `alerts` so it can be visible in Observability. Users who created rules that generated alerts with the `discover` consumer cannot see the alerts generated by the rule when they upgrade Kibana to 8.11+ even as superusers. This PR fixes the issues around the `discover` consumer. I added the following alert document to the `data.json.gz` to test for alerts with `discover` consumer. ``` { "type": "doc", "value": { "id": "1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97", "index": ".internal.alerts-stack.alerts-default-000001", "source": { "@timestamp": "2021-10-19T14:00:38.749Z", "event.action": "active", "event.kind": "signal", "kibana.alert.duration.us": 1370302000, "kibana.alert.evaluation.threshold": -1, "kibana.alert.evaluation.value": 80, "kibana.alert.instance.id": "query matched", "kibana.alert.reason": "Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.", "kibana.alert.rule.category": "Elasticsearch query", "kibana.alert.rule.consumer": "discover", "kibana.alert.rule.name": "EsQuery discover", "kibana.alert.rule.producer": "stackAlerts", "kibana.alert.rule.rule_type_id": ".es-query", "kibana.alert.rule.uuid": "25c14920-faa7-4a9a-830c-ce32c8211237", "kibana.alert.start": "2021-10-19T15:00:41.555Z", "kibana.alert.status": "active", "kibana.alert.time_range": { "gte": "2021-10-19T15:00:41.555Z" }, "kibana.alert.uuid": "23237979-75bf-4b68-a210-ce5056b93356", "kibana.alert.workflow_status": "open", "kibana.space_ids": [ "default" ], "kibana.version": "8.0.0", "tags": [] } } } ``` ## Testing 1. Create a rule with the consumer as `discover`. See #184595 for instructions. 2. Go to the rule details page. 3. Verify that you do not get any error toaster and you can see the alerts. Fixes: #184595 ### Checklist Delete any items that are not applicable to this PR. - [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Fix an issue with rules not being accessible created from Discover before 8.11.0. --------- Co-authored-by: Elastic Machine <[email protected]>
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 30, 2024
…sumers (elastic#192321) ## Summary Alerts use its own RBAC model. The RBAC relies on a property called `consumer`. The consumer is tight coupled with the feature ID. It denotes the user's access to the rule and the alerts. For example, a user with access to the "Logs" feature has access only to alerts and rules with the `consumer` set as `logs`. Users can create an ES Query rule from Discover. When the feature was [implemented](elastic#124534) (v8.3.0) the consumer was set to `discover`. Then it [changed](elastic#166032) (v8.11.0) to `stackAlerts` (visible only on the stack management page) and then [to](elastic#171364) (v8.12.0) `alerts` so it can be visible in Observability. Users who created rules that generated alerts with the `discover` consumer cannot see the alerts generated by the rule when they upgrade Kibana to 8.11+ even as superusers. This PR fixes the issues around the `discover` consumer. I added the following alert document to the `data.json.gz` to test for alerts with `discover` consumer. ``` { "type": "doc", "value": { "id": "1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97", "index": ".internal.alerts-stack.alerts-default-000001", "source": { "@timestamp": "2021-10-19T14:00:38.749Z", "event.action": "active", "event.kind": "signal", "kibana.alert.duration.us": 1370302000, "kibana.alert.evaluation.threshold": -1, "kibana.alert.evaluation.value": 80, "kibana.alert.instance.id": "query matched", "kibana.alert.reason": "Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.", "kibana.alert.rule.category": "Elasticsearch query", "kibana.alert.rule.consumer": "discover", "kibana.alert.rule.name": "EsQuery discover", "kibana.alert.rule.producer": "stackAlerts", "kibana.alert.rule.rule_type_id": ".es-query", "kibana.alert.rule.uuid": "25c14920-faa7-4a9a-830c-ce32c8211237", "kibana.alert.start": "2021-10-19T15:00:41.555Z", "kibana.alert.status": "active", "kibana.alert.time_range": { "gte": "2021-10-19T15:00:41.555Z" }, "kibana.alert.uuid": "23237979-75bf-4b68-a210-ce5056b93356", "kibana.alert.workflow_status": "open", "kibana.space_ids": [ "default" ], "kibana.version": "8.0.0", "tags": [] } } } ``` ## Testing 1. Create a rule with the consumer as `discover`. See elastic#184595 for instructions. 2. Go to the rule details page. 3. Verify that you do not get any error toaster and you can see the alerts. Fixes: elastic#184595 ### Checklist Delete any items that are not applicable to this PR. - [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Fix an issue with rules not being accessible created from Discover before 8.11.0. --------- Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit 396931f)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Sep 30, 2024
…sumers (elastic#192321) ## Summary Alerts use its own RBAC model. The RBAC relies on a property called `consumer`. The consumer is tight coupled with the feature ID. It denotes the user's access to the rule and the alerts. For example, a user with access to the "Logs" feature has access only to alerts and rules with the `consumer` set as `logs`. Users can create an ES Query rule from Discover. When the feature was [implemented](elastic#124534) (v8.3.0) the consumer was set to `discover`. Then it [changed](elastic#166032) (v8.11.0) to `stackAlerts` (visible only on the stack management page) and then [to](elastic#171364) (v8.12.0) `alerts` so it can be visible in Observability. Users who created rules that generated alerts with the `discover` consumer cannot see the alerts generated by the rule when they upgrade Kibana to 8.11+ even as superusers. This PR fixes the issues around the `discover` consumer. I added the following alert document to the `data.json.gz` to test for alerts with `discover` consumer. ``` { "type": "doc", "value": { "id": "1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97", "index": ".internal.alerts-stack.alerts-default-000001", "source": { "@timestamp": "2021-10-19T14:00:38.749Z", "event.action": "active", "event.kind": "signal", "kibana.alert.duration.us": 1370302000, "kibana.alert.evaluation.threshold": -1, "kibana.alert.evaluation.value": 80, "kibana.alert.instance.id": "query matched", "kibana.alert.reason": "Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.", "kibana.alert.rule.category": "Elasticsearch query", "kibana.alert.rule.consumer": "discover", "kibana.alert.rule.name": "EsQuery discover", "kibana.alert.rule.producer": "stackAlerts", "kibana.alert.rule.rule_type_id": ".es-query", "kibana.alert.rule.uuid": "25c14920-faa7-4a9a-830c-ce32c8211237", "kibana.alert.start": "2021-10-19T15:00:41.555Z", "kibana.alert.status": "active", "kibana.alert.time_range": { "gte": "2021-10-19T15:00:41.555Z" }, "kibana.alert.uuid": "23237979-75bf-4b68-a210-ce5056b93356", "kibana.alert.workflow_status": "open", "kibana.space_ids": [ "default" ], "kibana.version": "8.0.0", "tags": [] } } } ``` ## Testing 1. Create a rule with the consumer as `discover`. See elastic#184595 for instructions. 2. Go to the rule details page. 3. Verify that you do not get any error toaster and you can see the alerts. Fixes: elastic#184595 ### Checklist Delete any items that are not applicable to this PR. - [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 ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Fix an issue with rules not being accessible created from Discover before 8.11.0. --------- Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit 396931f)
kibanamachine
added a commit
that referenced
this pull request
Sep 30, 2024
…over` as consumers (#192321) (#194440) # Backport This will backport the following commits from `main` to `8.15`: - [[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)](#192321) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Christos Nasikas","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-30T14:11:00Z","message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Feature:Alerting","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:prev-major","v8.16.0","v8.15.3"],"title":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers","number":192321,"url":"https://github.com/elastic/kibana/pull/192321","mergeCommit":{"message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192321","number":192321,"mergeCommit":{"message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Christos Nasikas <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Sep 30, 2024
…ver` as consumers (#192321) (#194441) # Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)](#192321) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Christos Nasikas","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-09-30T14:11:00Z","message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Feature:Alerting","Team:ResponseOps","v9.0.0","Feature:Alerting/RulesFramework","backport:prev-major","v8.16.0","v8.15.3"],"title":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers","number":192321,"url":"https://github.com/elastic/kibana/pull/192321","mergeCommit":{"message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},"sourceBranch":"main","suggestedTargetBranches":["8.x","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192321","number":192321,"mergeCommit":{"message":"[ResponseOps][Alerts] Fix authorization issues with `discover` as consumers (#192321)\n\n## Summary\r\n\r\nAlerts use its own RBAC model. The RBAC relies on a property called\r\n`consumer`. The consumer is tight coupled with the feature ID. It\r\ndenotes the user's access to the rule and the alerts. For example, a\r\nuser with access to the \"Logs\" feature has access only to alerts and\r\nrules with the `consumer` set as `logs`. Users can create an ES Query\r\nrule from Discover. When the feature was\r\n[implemented](#124534) (v8.3.0)\r\nthe consumer was set to `discover`. Then it\r\n[changed](#166032) (v8.11.0) to\r\n`stackAlerts` (visible only on the stack management page) and then\r\n[to](#171364) (v8.12.0) `alerts`\r\nso it can be visible in Observability. Users who created rules that\r\ngenerated alerts with the `discover` consumer cannot see the alerts\r\ngenerated by the rule when they upgrade Kibana to 8.11+ even as\r\nsuperusers. This PR fixes the issues around the `discover` consumer.\r\n\r\nI added the following alert document to the `data.json.gz` to test for\r\nalerts with `discover` consumer.\r\n\r\n```\r\n{\r\n \"type\": \"doc\",\r\n \"value\": {\r\n \"id\": \"1b75bfe9-d2f5-47e9-bac6-b082dd9c9e97\",\r\n \"index\": \".internal.alerts-stack.alerts-default-000001\",\r\n \"source\": {\r\n \"@timestamp\": \"2021-10-19T14:00:38.749Z\",\r\n \"event.action\": \"active\",\r\n \"event.kind\": \"signal\",\r\n \"kibana.alert.duration.us\": 1370302000,\r\n \"kibana.alert.evaluation.threshold\": -1,\r\n \"kibana.alert.evaluation.value\": 80,\r\n \"kibana.alert.instance.id\": \"query matched\",\r\n \"kibana.alert.reason\": \"Document count is 80 in the last 100d in .kibana_alerting_cases index. Alert when greater than -1.\",\r\n \"kibana.alert.rule.category\": \"Elasticsearch query\",\r\n \"kibana.alert.rule.consumer\": \"discover\",\r\n \"kibana.alert.rule.name\": \"EsQuery discover\",\r\n \"kibana.alert.rule.producer\": \"stackAlerts\",\r\n \"kibana.alert.rule.rule_type_id\": \".es-query\",\r\n \"kibana.alert.rule.uuid\": \"25c14920-faa7-4a9a-830c-ce32c8211237\",\r\n \"kibana.alert.start\": \"2021-10-19T15:00:41.555Z\",\r\n \"kibana.alert.status\": \"active\",\r\n \"kibana.alert.time_range\": {\r\n \"gte\": \"2021-10-19T15:00:41.555Z\"\r\n },\r\n \"kibana.alert.uuid\": \"23237979-75bf-4b68-a210-ce5056b93356\",\r\n \"kibana.alert.workflow_status\": \"open\",\r\n \"kibana.space_ids\": [\r\n \"default\"\r\n ],\r\n \"kibana.version\": \"8.0.0\",\r\n \"tags\": []\r\n }\r\n }\r\n}\r\n```\r\n\r\n## Testing\r\n\r\n1. Create a rule with the consumer as `discover`. See\r\nhttps://github.com//issues/184595 for instructions.\r\n2. Go to the rule details page.\r\n3. Verify that you do not get any error toaster and you can see the\r\nalerts.\r\n\r\nFixes: https://github.com/elastic/kibana/issues/184595\r\n\r\n### Checklist\r\n\r\nDelete any items that are not applicable to this PR.\r\n\r\n- [x] [Unit or functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere updated or added to match the most common scenarios\r\n\r\n### For maintainers\r\n\r\n- [x] This was checked for breaking API changes and was [labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n## Release notes\r\nFix an issue with rules not being accessible created from Discover\r\nbefore 8.11.0.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"396931f5056600e633dba64dab81a66096d05f72"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Christos Nasikas <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR is updating Discover's rule to be created under the
stackAlertsconsumer and we created an breaking change issue to explain the consequences of this update.We also fix the rule's consumer for all rule types created under the observability rule management to use their producer instead of
alerts. Also, we add the ability for the ES Query and new Generic Threshold rules type to pick the consumer associated to the rule. TheensureAuthorizedand thefilterfunctions have modified and simplified to support this use case please check the newest unit test added inx-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts.There is now a dropdown in the rule form to prompt the user when creating ES Query/Generic threshold rules to select the consumer based on their authorized consumers (we can no longer use
alertsfor these). If there is only 1 option, then the dropdown will not be shown and the option will be chosen automatically.Generic threshold rules will have the following possible consumers:
ES query rules will have the following possible consumers:
To Test:
Single Consumer:
logsfeature enabled (ensuringstackAlertsis not enabled).logsset in theconsumerfieldinfrastructurefeature.Multiple Consumers:
logs,infrastructureandapmfeatures enabled (ensuringstackAlertsis not enabled).Checklist