Repository navigation
Allow disabling object-level permissions for a given model in the RBAC registry #424
Description
This is a "model registration flexibility" issue similar to #365
The ask here is to allow disabling of using object-level roles for a particular model. Spitball of the contract for this:
permission_registry.register(Instance, allow_object_roles=False)We would have allow_object_roles default to True, as this is how it is always used today. With this change, the (see later notes). However, importantly, the permissions related to the /api/v1/role_metadata/ endpoint would not show the content type for the Instance modelInstance model would still be shown as possible for system-wide roles. This is a valid use-case for this feature, because you may want to allow someone to manage instances in AWX without making them a superuser, but you still don't want to build out a UI for giving permissions to single instances, because you just don't want that.
The AWX Instance model does not have a related organization, but you could repeat for an organization-scoped model.
Our use case for this second version (org-scoped) mode would be the OAuth2 Application model. In AWX organization admins got permissions to this model. Implementation here would be that the model's permissions are listed in the organization admin roles. Optionally, someone could create custom organization-level roles that include OAuth2 Application permissions. But a user would not be able to create custom roles that give permission to individual applications, simply because we do not want to build a UI for this.
Activity
AlanCoding commentedon Jun 6, 2024
@relrod my only hangup for doing a fast 30-minute version of this is where this data could live. Right now the
permission_registrykeeps some simple dictionaries and sets that were introduced for specific problems.setonpermission_registrythat lists model names that don't allow object roles? That would get the job done.setattr(cls, '_allow_object_roles', True), and then use that flag on the objects themselves in the serializer.Thinking it over, I'm okay with either approach.
Lock down OAuth2 views (#434)
Lock down OAuth2 views (ansible#434)
AlanCoding commentedon Jun 26, 2024
This has a problem with the need for "creator" roles after someone creates a new object and does not have a role which would give implicit access to that object. Options for ways around that are:
None of these options are slam dunks. If I were to choose one, I would lean towards (1). However that still leaves unanswered questions.
Also, a half-way option that looks like option (3) will be possible with #490. Drawback is that it blocks the action late in the user experience, as opposed to giving advance notice to clients. On the other hand, it can offer a detailed rationale which needs to be filled in by the specific model permission policies.
Those together make this a pretty solid won't-fix.
AlanCoding commentedon Aug 19, 2024
This is now coming back up for galaxy_ng, and we will be getting a model list for this for those models.
AlanCoding commentedon Aug 19, 2024
Link prior work for this #475