"Actions & Connectors" users are surprised by the fact that users with read-only permissions can test connectors and execute actions

[nickpeihl]

Kibana version:
7.14.0-BC

Original install method (e.g. download page, yum, from source, etc.):

Cloud

Describe the bug:

A user with only "Read" permissions on "Actions and Connectors" and "Stack Rules" can test connectors. I'm not sure if this is intentional or not. But it seems to be that limited access users should maybe not be able to test connectors. I imagine a scenario where a read-only user is able to send a test through an existing PagerDuty connector either naively (or belligerently) to wake up the on-call person at 3AM. 😅

Steps to reproduce:

1. Create a connector using a third-party integration such as PagerDuty or Email
2. Create a user with only "Read" permissions on "Actions and Connectors" and "Stack Rules"
3. Log in as the user created in step 2 and create a test on the connector created in step 1
4. Note that the read-only user is able to send the test successfully

Expected behavior:

It seems to me that only users with permission to create and modify connectors should be able to test the connectors.

[elasticmachine]

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

[gmmorris]

This is actually ok, I think, but worth discussing.

A reminder of what the semantic are:

1. A user with all can CRUD Connectors
2. A user with read can R Connectors, meaning they can execute them too

This means, for example, a user with read can use a connector as an action on a rule. But they can't reconfigure this connector.
It makes sense then for a user that can create a rule and use a connector on it, to be able to test this connector and make sure it works.

But happy to have a debate about it :) @arisonl

[arisonl]

My view is that because read on connectors allows users to create and attach actions, they should be able to test the connector. However, I think that the privilege semantics are not obvious in the case of connectors and actions: the fact that read on connectors equals write and execute actions, is not immediately obvious, and this has come up a couple of times in the past. I think that this is in contrast to the bulk of other apps/cases, where the semantics of read and write are mostly evident. This is perhaps why this is perceived as a bug. Could sub-privileges help here for decoupling or even for the testing functionality?

[gmmorris]

Could sub-privileges help here for decoupling or even for the testing functionality?

How would that address the perception of this as a bug? Are you thinking users with read on Actions & Connectors would not be able to execute actions by default?
What's the point of read on the feature if they can't execute?

The only thing they could do in such a case is view the configuration of connectors that they can't actually use, so it seems like there isn't much point to them having access to the feature at all.

Feels like a product question, but I wonder if we can relabel "read" as something else for specific features (I know this isn't possible today, but something @elastic/kibana-security can add perhaps?). 🤷 Worth a thought, I guess.

This is perhaps why this is perceived as a bug.

Could we address this in the UX somehow? Adding a callout on the Test tab?

[gmmorris]

Changing this issue from bug to a docs and UX issue as it is an expected behaviour, but I recognise users might be surprised by this and I think we should address this at UX and docs level.

[legrego]

Feels like a product question, but I wonder if we can relabel "read" as something else for specific features (I know this isn't possible today, but something @elastic/kibana-security can add perhaps?). 🤷 Worth a thought, I guess.

This is something we can consider in the future, but you're right that it isn't possible today. If we maintain our current privilege "hierarchy" in the future, then whatever replacement you come up with for read would have to make sense in the context of the base all and read privileges. In other words, should users with read access to all features within the space be granted access to your read replacement? If so, will that experience be intuitive?

We are aggregating our authorization wish-list in #95513. I'll add a note there to capture this request.