RBAC in Galaxy NG
Every object in a GalaxyNG has at least four permissions created for it by default:
- Add: grants the ability to add objects of that class
- Delete: grants the ability to delete objects of that class
- View: grants the ability to view objects of that class
- Update: grants the ability to update objects of that class
Additional custom permissions can also be created for objects. For example, the namespace object has the "Upload to namespace" custom permission that we have defined to allow users to upload collections to a specific namespace.
Permissions can be granted at two levels: model (global) and object.
Model permissions are global, and grant the permission to all objects of the given class in the system. For example, granting model level update namespace permissions will allow a user to update all namespaces in the system.
Object level permissions are for specific objects. They allow for a user in the system to be granted permissions for a specific object. For example, granting update permissions on the foo namespace will allow a user to update namespace foo, but no other namespaces.
Permissions can be granted in one of two ways: on a per user level or on a per group level. At the moment, only group permissions are supported. To grant permissions, an admin has to create a group with the desired set of permissions and then add users who need those permissions to a group. For example an admin might create a "Content Managers" group that has global permissions to create and update new collections, namespaces and EEs. This would allow the admin to grant new users all the permissions needed to manage content by adding them to the "Content Managers" group.
Not all permissions are enforced. GalaxyNG doesn't currently allow content deletion, so most delete permissions are hidden in the UI. Likewise, content types such as collections and execution environments don't require any special permissions to view, so the view permissions for collections and EEs aren't enforced.
Users with django super user permissions automatically have all permissions in the system and can do anything that the app allows.
To make all of this work, we use two external libaries that add some addition functionality to the existing Django RBAC system.
Django guardian (https://django-guardian.readthedocs.io/en/stable/) adds per object permissions. This allows us to check if a user has permissions on a specific object, find objects that user's have permissions on and set permissions on specific objects for specific users or groups.
DRF access policy (https://rsinger86.github.io/drf-access-policy/) allows us to create DRF permission classes that read a JSON or python object and return whether or not the user has permissions to perform some action. A DRF access policy statement looks something like this:
[
{
"action": ["list", "retrieve"],
"principal": "authenticated",
"effect": "allow",
},
{
"action": "destroy",
"principal": "*",
"effect": "deny",
},
{
"action": "create",
"principal": "authenticated",
"effect": "allow",
"condition": "has_model_perms:galaxy.add_namespace"
},
{
"action": "update",
"principal": "authenticated",
"effect": "allow",
"condition": "has_model_or_obj_perms:galaxy.change_namespace"
},
]
This access policy allows for authenticated users to view content, users with the galaxy.add_namespace permissions to create new namespaces, users with the change_namespace permissions to update namespaces and denies everyone from deleting namespaces.
Our access policy definitions can be found in galaxy_ng/galaxy_ng/app/access_control/statements
Access policies are loaded in galaxy_ng/galaxy_ng/app/access_control/access_policy.py. At the moment there are two sets of access policies, one for insights mode, which disables features that aren't allowed in insights mode and one for standalone mode, which enables features such as user management and collection syncing. When the app is loaded, the access policy base class checks if the app is running in insights mode or standalone mode and loads the corresponding access policy.
Pulp has a slightly different approach for access policies. Rather than define them in a static python file, statements are stored in the database and loaded from there. This allows users to modify them if they wish. Modifying access policy statements isn't supported in galaxy_ng for end users, however there are cases were we need to update access policies in other pulp plugins to suit our use cases.
At the moment this is done using a post migration signal. When a migration happens, galaxy_ng loads it's own access policies for pulp container into the database. Our custom container policies can be found here: galaxy_ng/galaxy_ng/app/access_control/statements/pulp_container.py
Sponsored by Red Hat, Inc.