Skip to content
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

RBAC: Expand action sets when fetching permissions #87967

Merged
merged 7 commits into from
May 21, 2024

Conversation

IevaVasiljeva
Copy link
Contributor

@IevaVasiljeva IevaVasiljeva commented May 16, 2024

What is this feature?

When user permissions are fetched, always expand action sets into the underlying actions.

Also adding logic to deduplicate scopes when we group permissions: https://github.com/grafana/grafana/pull/87967/files#r1603476920

Why do we need this feature?

This way we don't need to make changes to any permission checks that don't directly query the DB (see the notes below on what else will need to be covered). This is safer, as we have permission checks in many places, and it is easy to miss adding an action resolver in some of them.

This means that we can undo changes introduced in #86801.

Who is this feature for?

Internal only

Which issue(s) does this PR fix?:

Fixes https://github.com/grafana/identity-access-team/issues/615

Special notes for your reviewer:

There is more work to take action sets into account for permission filters and for permission search. These will be covered in separate PRs.

Enterprise PR: https://github.com/grafana/grafana-enterprise/pull/6647

@IevaVasiljeva IevaVasiljeva added no-backport Skip backport of PR no-changelog Skip including change in changelog/release notes labels May 16, 2024
@IevaVasiljeva IevaVasiljeva added this to the 11.1.x milestone May 16, 2024
@IevaVasiljeva IevaVasiljeva requested review from a team as code owners May 16, 2024 10:46
@IevaVasiljeva IevaVasiljeva changed the title logic to expand action set to the underlying actions when permissions… RBAC: Expand action sets when fetching permissions May 16, 2024
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change is slightly out of scope of this PR, so I wanted to highlight it. We didn't use to deduplicate the scopes, which became more obvious with action sets if we're double-writing (so we'd have, eg, dashboards:read permission from the action set as well as from the fine-grained permissions written to the DB). So I've added some deduplication logic here.

Copy link
Contributor

Choose a reason for hiding this comment

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

could we add more comments to the function call to indicate that we are deduping as well and for what purpose.

much like your comment here

Resolve(action string) []string
ResolveAction(action string) []string
ResolveActionSet(actionSet string) []string
ExpandActions(permissions []Permission) []Permission
Copy link
Contributor

Choose a reason for hiding this comment

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

so we get permissions and get permissions out?

it's just that naming is a bit off, I completely understand why. Do you think we could change the interface to use

	ExpandActions(actionSets []string) []Permission

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's no way to transition from actionSets []string to []Permission. Permissions have additional information about scopes, roles etc, while action set list only has info about actions. I could rename the method if you have a better name candidate?

Copy link
Contributor

Choose a reason for hiding this comment

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

yea, apologize. i should come up with a solution as well.

perhaps we could use

ExpandActionSetsToActions
ExpandActionSets

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I'll go with ExpandActionSets 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: we can always change this back if it's just about naming convention. I'd prefer to be a bit more descriptive to ExpandingActionSetsToActions , to indicate what is happening

Maybe even using something like this (toooo long, but to get the description of what is happening):

ExtendPermissionsWithActionSetsToActions

@@ -756,7 +757,7 @@ type InMemoryActionSets struct {
}

// NewActionSetService returns a new instance of InMemoryActionSetService.
func NewActionSetService(a *acimpl.AccessControl) ActionSetService {
func NewActionSetService(a *acimpl.AccessControl) *InMemoryActionSets {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
func NewActionSetService(a *acimpl.AccessControl) *InMemoryActionSets {
func NewActionSetService(a *acimpl.AccessControl) *InMemoryActionSets {

what is the difference here when we return the pointer to a struct?

I think we changed this previously to a interface, if i am not mistaken

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, there's a slight difference with what wire supports, and I couldn't find an easy way around it. I'm planning to change this back once this PR is merged and I can do a follow up PR to clean up the action resolvers, as we won't need those anymore. So this is just a temporary change. Sorry for making it briefly messy 🙈

Copy link
Contributor

Choose a reason for hiding this comment

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

nada! just wanted to understand what this change was about and if i was missing something.

Copy link
Contributor

@eleijonmarck eleijonmarck left a comment

Choose a reason for hiding this comment

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

All good since we are just dealing with naming convention now!

great job. Tested this as well locally

@IevaVasiljeva IevaVasiljeva merged commit 3e77768 into main May 21, 2024
12 checks passed
@IevaVasiljeva IevaVasiljeva deleted the ieva/expand-action-sets-on-perm-read branch May 21, 2024 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/backend no-backport Skip backport of PR no-changelog Skip including change in changelog/release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants