Open pmuellr opened 3 months ago
Pinging @elastic/response-ops (Team:ResponseOps)
Hey @pmuellr! If you set the consumer
to alerts
the authorization service falls back to the producer
of the rule type and it should work without any issues. The issue I see here is that the request.featureIds
contained a feature ID that is not valid. For some reason, the UI put that in the request where it should not. The authorization service will ignore any invalid feature IDs when
Ah, thanks!
So, I was able to track this down using trace.id
in the Kibana logs to use as a filter in the ES proxy logs to get the x_opaque_id
of [(empty), application, observability-overview]
. So looks like an o11y UX.
I just noticed (via an SDH) that when you create a metric threshold rule from the o11y pages, it sets
consumer
to"alerts"
.However, the Rule Registry does not consider this a valid consumer:
https://github.com/elastic/kibana/blob/d90d7feda273212023e905620324256ef8bda4bb/packages/kbn-rule-data-utils/src/alerts_as_data_rbac.ts#L18-L38
This ends up generating the following message in the console:
Found invalid feature 'alerts' while using privateRuleRegistryAlertsSearchStrategy search strategy. No alert data from this feature will be searched.
(note, this message should be changed to include the type/id of the rule, if reasonable)
Searching the overview cluster for
privateRuleRegistryAlertsSearchStrategy
shows many hits.It feels like RR should be changed to accept
alerts
as a valid consumer, but I'm not an expert on the consumer bits.