Story #7210
closedAs a user, I can configure the permissions created at object creation time
100%
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 thepermissions
for one or more users by name. This requiresparameters
to not benull
.* -
add_for_groups
will addthe permissions
for one or more groups by name. This requiresparameters
to not benull
. -
object_creator
will addthe permissions
to the creator of the object. This requires theparameters
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
.
Updated by bmbouter over 4 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.
Updated by bmbouter over 4 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to bmbouter
Updated by mdellweg over 4 years ago
Would it be helpful, for conststency, to always make parameters a list (sometimes an empty one)?
Updated by bmbouter over 4 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.
Updated by bmbouter over 4 years ago
- Status changed from ASSIGNED to POST
PR available at: https://github.com/pulp/pulpcore/pull/815/files
Added by bmbouter over 4 years ago
Updated by pulpbot over 4 years ago
Updated by bmbouter over 4 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulpcore|3adeff2cd62c057f1da19c455377089154606bc6.
Updated by pulpbot over 4 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
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 thepermission_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 methodsobject_creator
,add_for_users
, andadd_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 usesdjango-lifecycle
allowing subcalsses to use it instead of signalsPlugin writers can easily provide queryset scoping on ViewSets that inherit from the
pulpcore.plugin.viewsets.NamedModelViewSet
by declaring thequeryset_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