-
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
[RAM] Update RBAC to manage es-query/generic o11y threshold rule #165182
[RAM] Update RBAC to manage es-query/generic o11y threshold rule #165182
Conversation
…bana into o11y-rbac-rule-feature-branch
…-ref HEAD~1..HEAD --fix'
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
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.
@XavierM can you list the four testing scenarios / rules you used yesterday? I want to use them when reviewing the alerting_authorization.ts
file.
x-pack/plugins/alerting/server/rule_type_registry_deprecated_consumers.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
@mikecote I will write jest test around this four scenario so it is easy to understand. |
Pinging @elastic/apm-ui (Team:APM) |
Pinging @elastic/uptime (Team:uptime) |
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.
apm changes lgtm
…bana into o11y-rbac-rule-feature-branch
…bana into o11y-rbac-rule-feature-branch
…bana into o11y-rbac-rule-feature-branch
@@ -84,7 +85,7 @@ export function AlertsPopover({ | |||
|
|||
return triggersActionsUi?.getAddRuleFlyout({ | |||
metadata: discoverMetadata, | |||
consumer: 'discover', |
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.
About this change we created an issue to the breaking changes committee -> https://github.com/elastic/dev/issues/2344
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, pretty straight forward logic.
Have some nitpicks mostly, not blocking though.
@@ -232,7 +242,8 @@ export class AlertingAuthorization { | |||
public async getAuthorizationFilter( | |||
authorizationEntity: AlertingAuthorizationEntity, | |||
filterOpts: AlertingAuthorizationFilterOpts, | |||
operation: WriteOperations | ReadOperations | |||
operation: WriteOperations | ReadOperations, | |||
featuresIds?: Set<string> |
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.
nitpick: does this have to be a set? seems like an array is enough
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.
we do not want duplicated of feature ids
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.
maybe its better to dedupe in the function and let it accept arrays, I think it makes the interface a bit friendlier to work with
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
if (!isEmpty(ruleTypeAuth.validLegacyConsumers)) { | ||
ruleTypeAuth.validLegacyConsumers.forEach((consumer) => { | ||
if (consumer === ALERTS_FEATURE_ID || isEmpty(featuresIds)) { | ||
if (!allPossibleConsumers[consumer]) { |
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.
do we have to do this check? can we just set it regardless
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 you are right that we do not really need the check with our use cases but it feel safer for some reason.
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
@@ -47,6 +47,7 @@ const querySchema = schema.object({ | |||
), | |||
fields: schema.maybe(schema.arrayOf(schema.string())), | |||
filter: schema.maybe(schema.string()), | |||
filter_consumers: schema.maybe(schema.arrayOf(schema.string())), |
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.
should we validate specifically against consumers instead of just strings?
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 was wondering too to be honest let me think more
x-pack/plugins/rule_registry/server/routes/get_browser_fields_by_feature_id.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/alerting/server/authorization/alerting_authorization.ts
Outdated
Show resolved
Hide resolved
'apm.anomaly': [ALERTS_FEATURE_ID], | ||
'apm.error_rate': [ALERTS_FEATURE_ID], | ||
'apm.transaction_error_rate': [ALERTS_FEATURE_ID], | ||
'test.always-firing': [ALERTS_FEATURE_ID], |
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.
Feels weird to be keeping this list. WDYT about having the ruleType specify something like legacyConsumer: boolean | string[]
where legacyConsumer: true
resolves to setting validLegacyConsumers: [ALERTS_FEATURE_ID]
on registration and legacyConsumer: ['discover']
resolves to validLegacyConsumers: [ALERTS_FEATURE_ID, 'discover']
on registration?
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.
That's a decision that @mikecote and I took to avoid to updating every rule type in the repo and also good catch I need to add some unit test so we know if someone is updating this list or not. Also, if we add it to the rule type, it will have to be a conditional type, it is not really safe.
|
||
let authorizationTuple; | ||
try { | ||
authorizationTuple = await context.authorization.getFindAuthorizationFilter( | ||
AlertingAuthorizationEntity.Rule, | ||
alertingAuthorizationFilterOpts | ||
alertingAuthorizationFilterOpts, | ||
isEmpty(filterConsumers) ? undefined : new Set(filterConsumers) |
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.
Does this respect RBAC? API users shouldn't be able to pass whatever set of consumers they want to aggregate over, they should just be able to limit which consumers to aggregate over that they already have access to correct?
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.
Yes it does follow RBAC, thanks for scaring me here ;) but we do, we are just saying that we only care about some consumers. It is helping us to only show o11y rules in the rule management page.
💔 Build FailedFailed CI StepsTest Failures
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
Summary
This PR is here to update the alerting authorization model to allow
.es-query
andobservability.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