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 feature - membership requirement for delegation of permissions #503

Open
AlanCoding opened this issue Jul 1, 2024 · 0 comments
Open
Assignees
Labels
app:rbac question Further information is requested

Comments

@AlanCoding
Copy link
Member

In #490 we added a callback to an old rule in AWX. Walking through the steps there:

  • A credential is created inside of an organization
  • You try to give a user a role so they have permission to that credential
  • This user is not in the organization
  • OBJECTIVE - it is desired to block this action, until the client adds the user as a member of the organization

This is only done for that particular action (plus a team variant). That never made any real sense, because user-organization-membership in AWX is meaningless when that story is repeated for all other models. So this issue asks what we would have if we respected that as a full feature, and resurrected it in DAB RBAC.

Global Setting Implementation

Imagine some setting and default like:

ANSIBLE_BASE_ALLOW_CROSS_ORGANIZATION_PERMISSIONS = True

If this setting is False, it will enforce two things, (1) users need "member_organization" for all role-user-assignments and (2) teams must be in same organization as any content_object they get permission for. So we have to logic this through from the very start:

  • The team model, itself, is a resource model that users get "member_team" permission for. This setting applies to it just like other models. If the setting is False, you can't become a member of a team unless you are also a member of the team's organization.
  • You can't get permission to any other content object without having "member_organization" to its related organization. This, of course, assumes the object has an organization.

Assuming this enforcement is always maintained (or data is migrated to coherency), you can see the 2 enforcement criteria are mutually supporting. Because all team members are known to be organization members, and because teams can only have same-organization permissions, giving team permissions to an object does not spill permissions across multiple organizations.

Model-Specific Implementation

A single global setting is probably too inflexible to ever be workable. Current AWX configuration only asks that this is enforced for the credential model. Model-specific configuration can be done in the permission_registry.register calls.

Some models are "singleton" models that do not have Organization as a parent, so obviously this enforcement would be impossible for those models anyway. Global roles are also apparently totally outside of this system as well.

If the team model does not enforce organization membership, then all other model enforcement is mostly pointless, because users outside of the organization can have permissions to an object via a team.

@AlanCoding AlanCoding added question Further information is requested app:rbac labels Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app:rbac question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants