Project

Profile

Help

Story #7210

As a user, I can configure the permissions created at object creation time

Added by bmbouter 2 months ago. Updated about 2 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
No
Tags:
Sprint:
Sprint 79
Quarter:

Description

Problem

When a user creates an object, e.g. a Task, what permissions are assigned to it?

On some installation when object foo is created users X, groups Y, and permissions Z should receive object foo. On other installations they want users A, groups B, and permissions C to be assigned. How can we make this satisfy everyone?

Solution

Add a post_create_callable JSONField to the AccessPolicy model which will be a list of dictionaries. Each dictionary will have three allowed keys, see the example entry below.

[{
		"function": "add_for_users",
		"parameters": ["alice", "bob"],
		"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
	},
	{
		"function": "add_for_groups",
		"parameters": "foo",
		"permissions": "pulpcore.view_task"
	},
	{
		"function": "object_creator",
		"parameters": null,
		"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
	}
]

Each entry will be a function called at object creation time. These methods are callables on the AccessPolicy object linked to the ViewSet, not on the model itself.

All three keys are required. The function value is a single string which will be validated to be a callable on the AccessPolicy governing the policy. The parameters can either be null, a single string, or a list of strings. The permissions case can either be a single string or list of strings, and each entry is validated against a permission in the DB.

Built in callables

By default three callables will always be available, but plugin-writers can add more.

  • add_for_users will add the permissions for one or more users by name. This requires parameters to not be null.*
  • add_for_groups will add the permissions for one or more groups by name. This requires parameters to not be null.
  • object_creator will add the permissions to the creator of the object. This requires the parameters value to be `null.

The Default

Plugin writers are expected to ship a default like this one:

[{
	"function": "object_creator",
	"parameters": null,
	"permissions": ["pulpcore.view_task", "pulpcore.change_task", "pulpcore.delete_task"]
}]

How Users Configure This

This will be available via the AccessPolicySerializer similar to how users read/set/adjust the statements part today as part of story https://pulp.plan.io/issues/7160. This JsonField will be named permissions_assignment.

Associated revisions

Revision 3adeff2c View on GitHub
Added by bmbouter about 2 months ago

Role Based Access Control

This PR adds in user-manageable Access Policies rooted at the /pulp/api/v3/access_policies/ endpint. This deifnes both statements of the policy as well as what permissions should be created for new objects.

The /pulp/api/v3/tasks/ endpoint is now protected by an AccessPolicy which by default provides user-isolation. This effectively limits a non-admin user to only view their own tasks.

Plugins writers can enable role base access control easily using the pulpcore.plugin.models.AccessPolicyFromDB object and declaring with the permission_classes attribute.

Plugin writers can use the pulpcore.plugin.models.AutoAddObjPermsMixin which provides user-configurable ways to create permissions for new objects. This includes three methods object_creator, add_for_users, and add_for_groups.

Plugin writers can use the pulpcore.plugin.models.AutoDeleteObjPermsMixin which provides auto-removal of object level permissions during object deletion.

pulpcore.plugin.models.BaseModel now uses django-lifecycle allowing subcalsses to use it instead of signals

Plugin writers can easily provide queryset scoping on ViewSets that inherit from the pulpcore.plugin.viewsets.NamedModelViewSet by declaring the queryset_filtering_required_permission class attribute naming the permission required to view an object.

closes #7160 closes #7210 closes #7151 closes #7157 closes #7158 closes #7300 closes #7301

History

#1 Updated by bmbouter 2 months ago

  • Description updated (diff)
  • Groomed changed from No to Yes

Groomed at open floor, changes incorporated form that discussion are now added to the plan.

#2 Updated by bmbouter 2 months ago

  • Sprint set to Sprint 78

Adding to sprint 78 per open floor.

#3 Updated by bmbouter 2 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to bmbouter

#4 Updated by mdellweg 2 months ago

Would it be helpful, for conststency, to always make parameters a list (sometimes an empty one)?

#5 Updated by bmbouter 2 months ago

mdellweg wrote:

Would it be helpful, for conststency, to always make parameters a list (sometimes an empty one)?

I was liking the idea of supporting both list and non-list forms. It's not consistent, but I was liking it. Here's the implementation I used. https://github.com/pulp/pulpcore/compare/master...bmbouter:rbac-PoC#diff-682e02af31bad2bd607317989f0951b2R60-R63

In terms of permissions being null, I don't have a use case for it, but perhaps we should make it optional so plugin writers can have the permissions hard-coded into the callable itself.

#6 Updated by rchan about 2 months ago

  • Sprint changed from Sprint 78 to Sprint 79

#7 Updated by bmbouter about 2 months ago

  • Status changed from ASSIGNED to POST

#9 Updated by bmbouter about 2 months ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#10 Updated by dkliban@redhat.com about 2 months ago

  • Sprint/Milestone set to 3.6.0

#11 Updated by pulpbot about 2 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF