[Cases][Discuss] Actions and Connectors permissions

[jonathan-buttner]

If a user is only granted access to read Cases, when they navigate to the detail view of a specific case they will receive a 403 when we attempt to retrieve the connectors because the user was not granted permissions for connectors.

This issue is to discuss granting users read permissions to connectors automatically when they are granted read or all permissions for cases. This would happen in two places that register the cases feature privilege: security_solution and observability. Ideally a readonly user would be able to read all parts of a case (including any connector that was associated with that case previously). A readonly user would not be able to modify the connectors though.

Error for a readonly user of cases without connectors permissions

The solution we were thinking of was to registry a cases feature that includes access to the connectors saved objects like this:

      subFeatures: [
        {
          name: 'Cases',
          privilegeGroups: [
            {
              groupType: 'mutually_exclusive',
              privileges: [
                {
                  // if the user is granted access to the cases feature than the global nav will show the cases
                  // sub plugin within the security solution navigation
                  app: [casesSubPlugin],
                  id: 'cases_all',
                  includeIn: 'all',
                  name: 'All',
                  savedObject: {
                    all: [],
                    read: [ACTION_SAVED_OBJECT_TYPE, ACTION_TASK_PARAMS_SAVED_OBJECT_TYPE],
                  },
                  ...
                },
                {
                  app: [casesSubPlugin],
                  id: 'cases_read',
                  includeIn: 'read',
                  name: 'Read',
                  savedObject: {
                    all: [],
                    read: [ACTION_SAVED_OBJECT_TYPE, ACTION_TASK_PARAMS_SAVED_OBJECT_TYPE],
                  },
                  ...
                },
              ],
            },
          ],
        },
      ],

We don't want to grant users with all cases access write access to the actions saved objects because if an admin ever wanted to prevent certain users from configuring external connectors we wouldn't be able to support that. Instead we would display a callout within the Cases UI explaining that they need to be granted write permissions.

These variables would need to be moved to a common location so they could be imported within security_solution and observability: ACTION_SAVED_OBJECT_TYPE, ACTION_TASK_PARAMS_SAVED_OBJECT_TYPE. They currently are defined here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/actions/server/constants/saved_objects.ts

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[ymao1]

Are there other examples of subfeature privileges that grant access to a top-level feature? To me, it would seem like a permissions bug that you could explicitly select none for the Actions and Connectors privilege but still be able to see them because you have the Cases privilege. Curious what others on @elastic/kibana-alerting-services think.

Would it be possible instead to surface a message to the user about their missing Actions and Connectors read permission before they reach this error state?

[jonathan-buttner]

Are there other examples of subfeature privileges that grant access to a top-level feature? To me, it would seem like a permissions bug that you could explicitly select none for the Actions and Connectors privilege but still be able to see them because you have the Cases privilege.

I'm not aware of any other sub features that do it. Our use of a sub feature in security solution is kind of a special one off. Within observability we use a regular top-level feature for cases but I think your concern is still valid there too. When I chatted with @legrego he mentioned the example of dashboards getting access to visualization's saved objects and this situation seems similar.

A more long term solution might be for the actions framework to implement a consumer style RBAC where cases could register its dependency on connectors maybe similar to how alerting does it.

Would it be possible instead to surface a message to the user about their missing Actions and Connectors read permission before they reach this error state?

Yeah we need to surface a message anyway in the case where a user has write access to cases but doesn't have write access to connectors (since it's probably not a good idea to have Cases All grant Connectors All).

[legrego]

Are there other examples of subfeature privileges that grant access to a top-level feature? To me, it would seem like a permissions bug that you could explicitly select none for the Actions and Connectors privilege but still be able to see them because you have the Cases privilege. Curious what others on @elastic/kibana-alerting-services think.

I wouldn't consider this sub-feature granting access to an entire top-level feature. If that's the intent, then I've misunderstood. We are instead requiring access to a specific type of saved object, which happens to be primarily managed by a top-level feature. Through this lens, it is very similar to how we handle visualizations and index patterns today. Index Patterns are managed by the Index Pattern Management top-level feature, but those saved objects are consumed by a number of other features, such as Dashboards, Discover, Lens, Maps, etc.

[ymao1]

Gotcha. So it looks like if I give explicit access to Index Pattern Management, I will be able to see the management page but giving explicit none to Index Pattern Management but access to Discover will grant access to the saved object but not surface the management page.

I think if as long as that is the outcome of Cases/Connectors, that would be fine. I was thinking with the suggested permissions model that giving access to Cases would allow users to view the Connector Management page, but if that's not the case, then that would make sense to me.

[jonathan-buttner]

I think if as long as that is the outcome of Cases/Connectors, that would be fine. I was thinking with the suggested permissions model that giving access to Cases would allow users to view the Connector Management page, but if that's not the case, then that would make sense to me.

Oh sorry for the miscommunication. Yeah we only want access to the saved objects, we wouldn't grant access to the connector management page.

[cnasikas]

@jonathan-buttner In this PR #127872 (check the screenshots) we no longer show this error. We put subtle messages to inform users about not having access to the actions plugin. Is that sufficient? Should we close this issue?

[jonathan-buttner]

The idea of this issue would be to grant users actions privileges when they have given certain cases privileges. The subtle messages will help but it might still be worth granting the actions privileges when a user is granted certain cases permissions. This might even be easier now that we've split up some of the permissions. I think I'd leave this in our backlog and see if any users want it 🤷‍♂️