-
Notifications
You must be signed in to change notification settings - Fork 12.8k
[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
base: main
Are you sure you want to change the base?
[WIP] RBAC: Improves Plugin ability for reqAction
to have multiple actions
#106335
Conversation
😢 zizmor failed with exit code 14. Expand for full output
|
💻 Deploy preview available: |
There was a problem hiding this 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.*')" |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
pkg/plugins/plugins.go
Outdated
if str, ok := action.(string); ok && str != "" { | ||
actions = append(actions, str) | ||
} |
There was a problem hiding this comment.
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.
if len(actions) == 0 { | ||
return ac.EvalPermission("") // Always deny | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
// 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍
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! |
NOTE:
any
orall
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. Theplugin.schema.json
foraction
andreqAction
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:
action
andreqAction
inplugin.schema.json
now support string or array of strings.MultiActionEvaluator
functions implement OR logic for permission checks; relevant middleware updated.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