Feat: Add RBAC to Synthetic Monitoring

[VikaCep]

Closes https://github.com/grafana/synthetic-monitoring/issues/166
Closes https://github.com/grafana/synthetic-monitoring/issues/167

This PR adds the configuration for the new roles associated with the different actions that can be performed within the plugin by following the RBAC in app plugins approach, and enforces this permissions in the frontend.

There's this document where different scenarios are combined to show how the app behaves in those cases.

I've taken the list from 166 and created the following categories so that users and teams can be assigned one or several of the following:

Admin: Provides permissions to manage all aspects of the app, including enabling/disabling the plugin and managing checks, probes, alerts, thresholds, and access tokens.

Editor: Similar to Admin access but does not include enabling/disabling the plugin or creating/deleting tokens.

Reader: Grants read access to all components (checks, probes, alerts, thresholds, and access tokens) in the app.

Checks Reader: Allows users to read checks within the app.
Checks Writer: Enables users to create, edit, and delete checks.

Probes Reader: Provides read access to probes.
Probes Writer: Allows users to create, edit, and delete probes.

Alerts Reader: Permits users to read alerts.
Alerts Writer: Enables the creation, editing, and deletion of alerts.

Thresholds Reader: Grants read access to thresholds.
Thresholds Writer: Allows users to read and edit thresholds,.

Access Tokens Writer: Permits the creation and deletion of access tokens.

[w1kman]

Is this prep work or is it possible to test the roles?

[w1kman]

Perhaps I'm not understanding this correctly, but it seems a little loose to allow someone that can write, to modify the data source. Seems like that should have its own role and only be assigned to admins.

[w1kman]

I guess this has nothing to do with adding/removing the data source 😅

[VikaCep]

In order to write checks or probes, users need to be able to write the SM datasource. For POST and DELETE operations to "{{.JsonData.apiHost}}/api/v1/" I've set a reqAction of grafana-synthetic-monitoring-app:write which before, it was Editor. This custom writer role is included in roles that perform write operations (such as Checks Writer, Probes Writer, etc).

Now, for the {{.JsonData.apiHost}}/api/v1/register/save url, I changed the required permission to be grafana-synthetic-monitoring-app.plugin:enable which is only assigned to Admins.

As an example, this is what happens if I try to edit a check and I don't have the permissions defined in the POST {{.JsonData.apiHost}}/api/v1/" section of the datasources/plugin.json file:

Screen.Recording.2024-11-19.at.16.31.50.mov

[VikaCep]

Is this prep work or is it possible to test the roles?

This is the roles definitions only. In this other PR I consume the roles and apply the restrictions in the UI.

didn't mean to add approval

[ckbedwell]

LGTM 🥇

I went on quite a journey when I started to deep dive in the other PR when testing the roles on an individual level. I am leaving my findings below as reference for anyone else who might get confused if they do this level of testing.

All screenshots show my admin user granting permissions on the left screen; my viewer user consuming said permissions.

I started by removing every role and just adding: Synthetic Monitoring: Access tokens reader

And I can't access SM or any other plugin for that matter. This is correct because at the moment we don't grant any routes to Access tokens readers. When they can view access tokens and have a route assigned this should go back to working.

So I added: Plugins:Application Plugins Access

And I can't access SM but I can access other plugins (poorly). This also seems correct because of the same reasoning above. I do wonder if we should show the homepage and have some level of explanation that they need a level of RBAC access?

So then I removed everything and added: Synthetic Monitoring:Reader

And this is what I expected as I hadn't granted SM DS datasource access.

So I added my user 'viewer' to the SM datasource and I can see a limited view of the SM app.

Have some questions based on exploration in the other PR.

[ckbedwell]

So based on the comment above. I think we need to support some sort of parred back homepage for users with limited access. Here I have the Synthetic Monitoring: Alerts reader role and if I go back to the homepage I get given an Access denied alert.

There is a wider conversation towards having an 'adaptable' homepage dependent on what your role and permissions are but that would be a lot of work and beyond the scope of the ticket.

[VikaCep]

@ckbedwell I have changed the required permissions that are needed to read the SM home page, which previously were requiring Check Reader access. Please let me know if this addresses your questions.

Here I have the Synthetic Monitoring: Alerts reader role and if I go back to the homepage I get given an Access denied alert.

After changing the mentioned permission, now in the scenario you described we get this view:

BTW, any custom SM role that you add (like Checks reader, Alerts reader, etc) will automatically include the { "action": "plugins.app:access", "scope": "plugins:id:grafana-synthetic-monitoring-app" }, permission so it's not necessary to add the Plugins:Application Plugins Access permission to the user manually.

[ckbedwell]

After changing the mentioned permission, now in the scenario you described we get this view:

You only get this view if you don't have SMDS Query permissions. Once you add them you get a skeleton view of the Scenes homepage with the checks (which I shouldn't have because I don't have 'Checks reader' permissions).

I wonder if we should add some sort of testing matrix to try and ensure this remains bug-free for the future or to document what the expected behaviour is?

[VikaCep]

I wonder if we should consider adding a testing matrix to help ensure this remains bug-free going forward, or perhaps document the expected behavior more clearly?

Yes, given the number of testing scenarios involved, I'll work on creating a document that outlines all possible cases and their expected behavior to help streamline the review process.

Additionally, some of the issues raised here should be addressed in this PR, as my focus here was primarily on the roles in the plugin.json file. My original plan was to submit two separate PRs—one for defining the new roles and permissions, and another for implementing the frontend enforcements—to first ensure consensus on the proposed roles. Now that we've mostly agreed on that, I think it makes sense to consolidate both PRs into one for easier testing. I'll proceed with merging PR #986 into this one.