Remove alerting / actions from features UI in security

[mikecote]

Solution teams should grant alerting access accordingly for 7.6.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[peterschretlen]

A few notes on making changes for solution teams:

1. SIEM should be pretty straightforward, as it has a feature control and we can add to the existing API and saved object privileges:
   https://github.com/elastic/kibana/blob/7.x/x-pack/legacy/plugins/siem/server/kibana.index.ts#L61

2. Stack Monitoring uses a reserved role, so we'd add similar API and saved object privileges but under the reserved.privlege section. This will bind those privileges to the monitoring_user role.
   https://github.com/elastic/kibana/blob/7.x/x-pack/legacy/plugins/monitoring/server/plugin.js#L70

3. If we add any user-defined alerting in 7.6 (like an equivalent to the threshold watch) we'll need to add a feature control to enable access to them I believe @mikecote ? We may need this eventually anyway for alert types that don't fall under a specific feature. User defined alerts don't really fall nicely under any of the existing features.

[mikecote]

we add any user-defined alerting in 7.6 (like an equivalent to the threshold watch) we'll need to add a feature control to enable access to them I believe @mikecote ?

This is an interesting one. If the alerting plugin exposes the index threshold alert type and an application (for example SIEM) wants to use it, the alert should belong to SIEM.

If ever a user goes through our UIs to create a threshold alert (as you mentioned), this is where it gets interesting. If ever there's a privilege that allowed the user to get to the management UIs, I think it should piggy back on that. Otherwise, I wonder if there's a "everyone has access" privilege to give the alert.

Maybe this revives the conversation about feature controls not only belonging to each application but also a generic "Alerts" feature control that would turn on / off alerting everywhere for a user + handle the user defined alerts at the same time.

On the action side, regardless where you're creating an action from, I think it would only work if you have access to the application exposing the action type. The same would apply to users adding actions to their alerts, they can only add actions created for applications they have access to.

Thinking of it, I think actions would have to stay as a feature control to satisfy the requirement of "only admins should setup the actions" while everyone else has read access. This leaves the sub features question for another day (ex blacklist IP).

I put lots of questions here but I think we'll have to figure this out for 7.6 if we want an easy migration once feature controls lands (ex: 7.7). See #51120 as the preparation we should do for 7.6.

[mikecote]

cc @kobelb ^^

[kobelb]

If ever a user goes through our UIs to create a threshold alert (as you mentioned), this is where it gets interesting. If ever there's a privilege that allowed the user to get to the management UIs, I think it should piggy back on that.

I agree.

Otherwise, I wonder if there's a "everyone has access" privilege to give the alert.

It's possible to do this, but I wouldn't recommend giving everyone access to a specific alert. Users will inevitably want to control who can create free-form threshold alerts.

Maybe this revives the conversation about feature controls not only belonging to each application but also a generic "Alerts" feature control that would turn on / off alerting everywhere for a user + handle the user defined alerts at the same time.

The "feature" which allows the user to create free-form alerts doesn't have to also grant the user access to alerting in all of the various applications.

On the action side, regardless where you're creating an action from, I think it would only work if you have access to the application exposing the action type. The same would apply to users adding actions to their alerts, they can only add actions created for applications they have access to.

I thought actions were going to be re-used between applications? Are they actually going to be application specific?

[peterschretlen]

Regarding actions - I agree that actions should be exposed as a feature control, though in 7.6 we could (for now) just include these privileges under the Stack Monitoring role. There is otherwise no real benefit in exposing them in 7.6 (SIEM will not be using them, and alerts will not be exposed otherwise ). There is ongoing discussion in #51784 about security concerns with actions and whitelisting - so limiting action access behind a built-in role for now might be a good thing.

For user-defined alerts, I think it's fair in 7.6 if we can only access it with SIEM 'all' feature privilege. And maybe further we need a config setting to turn it on - It means we can expose it and test in a limited way without having to worry about migrations?

After 7.6 I agree with @kobelb that we can make a "free-form alerts" feature that is tied to types defined in the alert plugin only and can only be created in specific places like the management UI view.

I thought actions were going to be re-used between applications? Are they actually going to be application specific?

@kobelb for the foreseeable future they will be re-used. Most notification style actions, and even more complex actions like case management are re-usable across apps. Certain (notional) types of "response" actions such as blacklisting an IP might only make sense in certain apps though, which is what @mikecote is referring to I believe. They don't exist today, but we anticipate it might happen.

[mikecote]

For user-defined alerts, I think it's fair in 7.6 if we can only access it with SIEM 'all' feature privilege. And maybe further we need a config setting to turn it on - It means we can expose it and test in a limited way without having to worry about migrations?

++ agreed, I think we'll be ok migrating user-defined alerts down the road and have it behind feature flag for now.

Certain (notional) types of "response" actions such as blacklisting an IP might only make sense in certain apps though, which is what @mikecote is referring to I believe. They don't exist today, but we anticipate it might happen.

Yeah, the blacklisting IP scenario is what I was referring to. I was trying to build a picture of what information we need to store to allow feature controls to do their thing (#51120). Though I think we'll postpone that issue for now and try to summarize later within #43994.