[APM] A read-only user can create alerts but not select actions

[sorenlouv]

A user that only has read access to APM can create alerts via the APM app but is not able to specify an action:

This means an alert is created without actions - is this intentional?

Btw. This might be affected by #79896)

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[cauemarcondes]

@sqren it works for me with a user that has read permission.

[arisonl]

In 7.10, actions are secured separately through Kibana RBAC via the role definition view. See Actions and Connectors.

@sqren does the role have the required privileges?

[sorenlouv]

does the role have the required privileges?

No, the user does not have access to anything but APM. It therefore surprised me that I could view the flyout and create the alert, but not see or change actions.

I would expect that if I cannot see actions I shouldn't be allowed to create the alert.

[jasonrhodes]

@sqren does the user really only have read permissions to APM? Based on my changes, they shouldn’t be able to create the alert at all. It should fail on submit. If they have “all” privileges for APM but not for Actions and Connectors then they should see the behavior you describe (by design).

[sorenlouv]

Based on my changes, they shouldn’t be able to create the alert at all

This was tested before your changes made it in. Might have changed slightly after.

If they have “all” privileges for APM but not for Actions and Connectors then they should see the behavior you describe (by design).

Ok, so sounds like it still exhibits this slightly surprising behaviour after your change as well.

[sorenlouv]

(by design).

Btw. what does that mean? that we intend for them to be able to see the flyout and create the alert but not select an action? I'm probably missing some context but what's the purpose of letting someone create an alert if they can't set actions?

[jasonrhodes]

@sqren yeah I had the same questions. From @gmmorris in Slack:

Yup, this is correct and by design.

There could potentially be users who you want to allow alerting to but not actions - an analyst role for example where they should be able to investigate data but you might not want them opening a PagerDuty incident.

Longer term we’re talking about using Sub Feature controls so that it’s more granular than just “All Actions”.

[jasonrhodes]

Apparently "Read" permissions to "Actions and Connectors" will allow a user to create an alert and assign it to a pre-configured Action Connector, but not create new Action Connectors. "All" permissions to A&C would allow both.

[sorenlouv]

Thanks for the added context @jasonrhodes . I think that settles it so I'll close this issue.

[arisonl]

Actions can be potentially leveraged by other Kibana features outside alerting. Hence they are secured separately.