Project

Profile

Help

Story #7210

closed

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

Added by bmbouter over 3 years ago. Updated over 3 years 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.

Actions #1

Updated by bmbouter over 3 years 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.

Actions #2

Updated by bmbouter over 3 years ago

  • Sprint set to Sprint 78

Adding to sprint 78 per open floor.

Actions #3

Updated by bmbouter over 3 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to bmbouter
Actions #4

Updated by mdellweg over 3 years ago

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

Actions #5

Updated by bmbouter over 3 years 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.

Actions #6

Updated by rchan over 3 years ago

  • Sprint changed from Sprint 78 to Sprint 79
Actions #7

Updated by bmbouter over 3 years ago

  • Status changed from ASSIGNED to POST

Added by bmbouter over 3 years ago

Revision 3adeff2c | View on GitHub

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

Actions #9

Updated by bmbouter over 3 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #10

Updated by dkliban@redhat.com over 3 years ago

  • Sprint/Milestone set to 3.6.0
Actions #11

Updated by pulpbot over 3 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF