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_userswill add thepermissionsfor one or more users by name. This requiresparametersto not benull.* -
add_for_groupswill addthe permissionsfor one or more groups by name. This requiresparametersto not benull. -
object_creatorwill addthe permissionsto the creator of the object. This requires theparametersvalue 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 about 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.
Updated by bmbouter about 3 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to bmbouter
Updated by mdellweg about 3 years ago
Would it be helpful, for conststency, to always make parameters a list (sometimes an empty one)?
Updated by bmbouter about 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.
Updated by bmbouter about 3 years ago
- Status changed from ASSIGNED to POST
PR available at: https://github.com/pulp/pulpcore/pull/815/files
Added by bmbouter about 3 years ago
Updated by pulpbot about 3 years ago
Updated by bmbouter about 3 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulpcore|3adeff2cd62c057f1da19c455377089154606bc6.
Updated by pulpbot about 3 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.AccessPolicyFromDBobject and declaring with thepermission_classesattribute.Plugin writers can use the
pulpcore.plugin.models.AutoAddObjPermsMixinwhich 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.AutoDeleteObjPermsMixinwhich provides auto-removal of object level permissions during object deletion.pulpcore.plugin.models.BaseModelnow usesdjango-lifecycleallowing subcalsses to use it instead of signalsPlugin writers can easily provide queryset scoping on ViewSets that inherit from the
pulpcore.plugin.viewsets.NamedModelViewSetby declaring thequeryset_filtering_required_permissionclass attribute naming the permission required to view an object.closes #7160 closes #7210 closes #7151 closes #7157 closes #7158 closes #7300 closes #7301