-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RAC] Get o11y alerts in alerts table #109346
Conversation
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping on this so quickly!
The fact that we're using the ruleDataClient
here leads to a few problems (that existed before, but are solidified through these changes):
- The field list is read using the internal user's permissions and not the current user's permissions.
- The addition of the
indexNames
argument togetReader
breaks the abstraction, because the whole point of theRuleDataClient
is to delegate the index name generation to theRuleDataService
.
How about the following:
- The
dynamic_index_pattern
route turns a list ofregistrationContext
s and anamespace
into an index name pattern (e.g.['.alerts-observability.logs.alerts-default', '.alerts-observability.metrics.alerts-default']
). On the alerts page we then use Kibana'sIndexPatternService
to requestgetFieldsForWildcard
to get the field list for use as adynamicIndexPattern
.
Does that make sense?
@@ -37,9 +37,13 @@ export class RuleDataClient implements IRuleDataClient { | |||
return this.options.isWriteEnabled; | |||
} | |||
|
|||
public getReader(options: { namespace?: string } = {}): IRuleDataReader { | |||
public getReader(options: { namespace?: string; indexNames?: string[] } = {}): IRuleDataReader { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this break the abstraction layer the RuleDataClient
represents?
@@ -148,4 +152,13 @@ export class RuleDataPluginService { | |||
waitUntilReadyForWriting, | |||
}); | |||
} | |||
|
|||
/** | |||
* Initializes alerts-as-data index and starts index bootstrapping right away. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this comment correlate to the actual function?
@XavierM I took the liberty of removing the |
return callObservabilityApi({ | ||
signal, | ||
endpoint: 'GET /api/observability/rules/alerts/dynamic_index_pattern', | ||
params: { | ||
query: { | ||
namespace: 'default', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weltenwort Is there a way to get the space id from the UI? This may not always be default
, no?
We were pulling it off of the alerting framework rulesClient in the rules/alerts/dynamic_index_pattern
route so we could ensure we acquired the correct space id on the request.. If observability doesn't plan on segmenting by space id I could understand why this would be hard coded to default
then. Just looking for clarification here..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentionally fixed as default
, because in observability we're not using the space id in the namespace. The filtering by space happens as part of the RBAC filter if I saw that correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me overall, I just left a few comments. Thank you @XavierM @dhurley14 @weltenwort
Also, mapConsumerToIndexName
is still used by AlertsClient
(RBAC), right?
@@ -105,6 +106,8 @@ export class RuleDataPluginService { | |||
indexOptions, | |||
}); | |||
|
|||
this.registeredIndices.set(indexOptions.registrationContext, indexInfo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The full index name (indexInfo.baseName
) is defined not only by registrationContext
, but also by dataset
(alerts
or events
).
I guess the proper key for this map would be ${indexOptions.registrationContext}.${indexOptions.dataset}
, and getRegisteredIndexInfo
would need to accept dataset
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, this only works because we assume alerts
as a dataset implicitly. Would it be ok to add that as a follow-up to unblock this ASAP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, of course 👍
TODO in the follow-up PR: let getRegisteredIndexInfo
to accept dataset
as well, generate keys of the registeredIndices
map correctly.
registrationContexts: [ | ||
'observability.apm', | ||
'observability.logs', | ||
'observability.infrastructure', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
observability.infrastructure
registration context doesn't exist in the code. What plugin is supposed to be defining it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be observability.metrics
. The app is called infrastructure
for historical reasons, but not the registration context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO in the follow-up PR: remove observability.infrastructure
and make sure observability.metrics
is there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weltenwort, I agree with what you did and to be honest I was not really familiar with all the work and discussion around ruleDataClient or ruleDataService. So I am glad you fix it and make it good for everybody.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving to unblock and merge this PR ASAP.
I'll try to address these things in a follow-up PR:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks everyone for the collaboration.
Known issues are the wrong observability.infrastructure
registration context and the lack of dataset
in the registered index info map.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! LGTM!!
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Unknown metric groupsAPI count
API count missing comments
Non-exported public API item count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
💔 Backport failed
Successful backport PRs will be merged automatically after passing CI. To backport manually run: |
The failed backport is probably due a chain of other backports failing. I'll keep track of those any retry later today: |
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com> Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> # Conflicts: # x-pack/plugins/observability/public/pages/alerts/alerts_table_t_grid.tsx # x-pack/plugins/observability/public/pages/alerts/index.tsx
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> # Conflicts: # x-pack/plugins/observability/public/pages/alerts/alerts_table_t_grid.tsx # x-pack/plugins/observability/public/pages/alerts/index.tsx Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com>
…atures to index names (#109567) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [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
…atures to index names (elastic#109567) **Ticket:** elastic#102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of elastic#109346 and replaces elastic#108872. TODO: - [x] Address elastic#109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close elastic#108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [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
…atures to index names (elastic#109567) **Ticket:** elastic#102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of elastic#109346 and replaces elastic#108872. TODO: - [x] Address elastic#109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close elastic#108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [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
…atures to index names (#109567) (#110068) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [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: Georgii Gorbachev <georgii.gorbachev@elastic.co>
…atures to index names (#109567) (#110067) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [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: Georgii Gorbachev <georgii.gorbachev@elastic.co>
Summary
Fixes #109317
@dhurley14 and I pair to bring back o11y alerts in the table. Now, we are passing directly the indexes name in our alerts search strategy and count on the filter of the authorization to show the right alerts. The index names are saved in memory inside of the ruleServiceData.