Skip to content

[WIP] RBAC: Improves Plugin ability for reqAction to have multiple actions #106335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

eleijonmarck
Copy link
Contributor

NOTE:

  • Decision needed: we need to figure out of the operation should be a any or all evaluation of permissions.

What is this feature?

This update allows plugin RBAC to use multiple actions (with OR logic) for routes and navigation items. Users gain access if they possess any of the specified permissions. The plugin.schema.json for action and reqAction now accepts either a single string or an array of strings.

Why do we need this feature?

Previously, only a single RBAC action could be defined for plugin routes/navigation, limiting flexibility. This change enables more granular access control where users can have one of several permissions to access a resource

Who is this feature for?

Plugin developers needing more fine-grained access control, and Grafana administrators managing plugin permissions.

Changes:

  • Schema: action and reqAction in plugin.schema.json now support string or array of strings.
  • RBAC Logic: New MultiActionEvaluator functions implement OR logic for permission checks; relevant middleware updated.
  • Tests: Added unit tests for checking actions in the plugin json to be correct and in line with array of strings, or a string.

This change is backward compatible with existing single string action definitions.


Which issue(s) does this PR fix?:
https://github.com/grafana/grafana-enterprise/issues/8691

@eleijonmarck eleijonmarck self-assigned this Jun 4, 2025
@github-actions github-actions bot added area/backend type/docs Flags the technical writing team for documentation support; auto adds to org-wide docs project labels Jun 4, 2025
Copy link
Contributor

github-actions bot commented Jun 4, 2025

😢 zizmor failed with exit code 14.

Expand for full output
error[excessive-permissions]: overly broad permissions
  --> ./.github/workflows/release-pr.yml:42:3
   |
42 |   id-token: write
   |   ^^^^^^^^^^^^^^^ id-token: write is overly broad at the workflow level
   |
   = note: audit confidence → High

93 findings (45 ignored, 47 suppressed): 0 unknown, 0 informational, 0 low, 0 medium, 1 high

Copy link
Contributor

github-actions bot commented Jun 4, 2025

Copy link
Contributor

@IevaVasiljeva IevaVasiljeva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall, but added some suggestions and corrections.

"oneOf": [
{
"type": "string",
"description": "Single RBAC action required to see this page in the navigation menu. Supports wildcards (e.g., 'plugin.write.*')"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need wildcard support if we allow defining multiple actions? Same question for reqAction.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking through the code changes, I don't think we actually support wildcards.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh that's a miss from me! i had initially worked on wildcard

Comment on lines 250 to 252
if str, ok := action.(string); ok && str != "" {
actions = append(actions, str)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: might be worth adding a log for cases where a non-string is specified here, to help debugging.

Comment on lines +122 to +124
if len(actions) == 0 {
return ac.EvalPermission("") // Always deny
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should never encounter this case here, so I'm not sure how to best treat it. Feels wrong to deny, but feels risky to allow. Also feels weird to be denying by using EvalPermission(""). Something like "no opinion" that was implemented for the new APIs evaluators would be suitable, but that's probably overcomplicating it. If you stick with this code, could you please add a comment stating that this code should never be hit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i actually removed this piece of code to make it easier. if we would have zero actions, we would hit the evaluator with zero evaluators which would result in a false. Meaning we would deny the request. Is this okay?

if datasourcesActions[action] {
return ac.EvalPermission(action, "datasources:uid:"+dsUID)
}
return ac.EvalPermission(action)
}

// GetDataSourceRouteMultiActionEvaluator returns an evaluator for multiple data source actions (OR logic)
func GetDataSourceRouteMultiActionEvaluator(dsUID string, actions []string) ac.Evaluator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to keep the previous function name, and not split the functions into a public and private one. Probably just a matter of preference, but these feel like unnecessary changes to me.

Comment on lines +155 to +158
// NOTE: maybe redundant test as the "only" thing the it does is to check the len of GetActions()
//
// actions := e.GetActions()
// return len(actions) > 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: remove the comment. I think it's worth keeping the test in, the logic might become more complex in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, this was a review comment actually. so it worked! il note that for next time. that it is a review comment 👍

Copy link
Contributor

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 2 weeks if no further activity occurs. Please feel free to give a status update or ping for review. Thank you for your contributions!

@github-actions github-actions bot added the stale Issue with no recent activity label Jul 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/backend stale Issue with no recent activity type/docs Flags the technical writing team for documentation support; auto adds to org-wide docs project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants