Feat: Add RBAC to Synthetic Monitoring #982
Conversation
src/datasource/plugin.json
Outdated
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I guess this has nothing to do with adding/removing the data source 😅
There was a problem hiding this comment.
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
This is the roles definitions only. In this other PR I consume the roles and apply the restrictions in the UI. |
There was a problem hiding this comment.
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.
ckbedwell
dismissed
their stale review
Have some questions based on exploration in the other PR.
There was a problem hiding this comment.
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.
|
@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.
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 |
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? |
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 |
VikaCep
changed the title
* feat: create useUserPermissions hook * feat: define PluginPermissions type * feat: enforce Check permissions using RBAC * feat: enforce Probe permissions usign RBAC * feat: enforce Alert permissions using RBAC * fix: lint * feat: enforce Config permissions using RBAC * feat: apply new permissions to plugin installation * fix: remove console.log * fix: fallback to basic user roles contemplating roles hierarchy * fix: change PluginPermission to use write instead of edit * fix: add tests * fix: update types for access-tokens permissions * fix: lint * fix: tests * fix: show missing permissions alert * fix: adjust types to match plugin definitions * fix: refactor getUserPermissions function * fix: change plugin permissions to use template literal types * fix: uppercase RBAC in function names * fix: updates after rebasing with main * fix: adapt after rebasing with main * fix: remove useCanWriteSM hook - instead, we should query permissions from getUserPermissions * fix: lint * fix: check for metrics ds query access in order to display alerts
I added
|
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.
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.
Access Tokens Reader: Permits reading access tokens.