# Role Based Access Control (RBAC) for Pulp

###### tags: `RBAC`

## Introduction/problem statement

Pulp is a multitenant software, but without RBAC it is not safe to use as a multitenant software. Assume you have a few users Alice, Bob, and Eve using one Pulp installation; here are some example problems you have:

* Alice can create new RepositoryVersions for a Repository Bob uses and Bob doesn't want that
* Alice puts sensitive credentials in a Remote and Bob then inappropriately uses that Remote to sync content he isn't entitled to
* Eve deletes all Repositories, Remotes, Distributions, and Content from a Pulp installation that Alice and Bob are using
* Alice uploads a container with `docker push` and then Bob is able to `docker pull` it incorrectly
* Bob "exclusively "owns" the pulp_ansible Collection Namesapce `Foo` but Eve can add CollectionVersion's to `Foo` even though it's Bob's.

## Definitions

- **Subject** - A person or automated agent
- **Role** - Job function or title which defines an authority level
- **Permissions** - An approval of a mode of access to a resource

## Use Cases

USE CASES GO HERE

* PulpImport use-case:
* I have a Role that allows me to do a PulpImport.
* That specific import-process wants to result in an update to a Repository
* I do *NOT* have a Role that allows me to make updates to that Repository
* How do I know that this won't work?
* Alternately - if we only enforce at viewset, how could this proposal keep this from happening?

* As a user, I'm allowed to perform a specific action only.
* As a user, I'm allowed to only sync repos (no other modifications).
* As a user, I'm allowed to upload content to Pulp but not add it to repos.

* As a user, I get the same permissions to the sub-repos (managed repos) as to the main one.
* Kickstart use case

* As a user, I can create a Distribution only under certain namespace
* E.g. one team/user can publish repositories only under 'my_org/project1/', another - under 'my_org/project2/'
* was asked about this feature many times at conferences
* podman push will probably need this so you can only create a distribution in yournamespace

* Content Isolation
* As a user with private content loaded into Pulp, another user cannot "take" my content either through a copy API, add_content_units, or falsifying uploaded content.
* Who owns content? A user who uploaded it, or a group of users who that user is a part of.
* As a user, if I upload a piece of content which already exists in Pulp, I get all permissions to it as it was mine
* Probably would be better if I get all permissions except the DELETE
* What to do with revoking permisions for content in such cases? ^
* Is there an admin role which allows to manage permissions for a subset of users/roles only, and not for everyone?
* Does orphan cleanup take any permissions to content into account?
* Can I remove content from Pulp which I don't have access to?

* User experience
* As a user, I can easily manage permissions for main actions and resources without knowing every single model used by Pulp
* E.g. Does it make sense to separate permissions for Publication (if exists) and Distribution?
* As a user, I can easily grant all permissions with some exceptions
* E.g. I can do whatever except the deletion of Repos, Remotes, Distributions.

* Group Definitions
* External Groups...
* As a user in an environment where groups are defined not in Pulp but in, e.g. ActiveDirectory or LDAP
* How does an administrator maintain a mapping of externally defined groups to "roles" or "permissions" defined by Plugin Writers?
* Groups defined in Pulp
* As a user, I don't have to use an external identify management solution to define groups. I can use groups natively offered to Pulp

* As a user I am allowed to copy Content from a source Repository to a destination Repository
* What permissions do I need on the source Repo, the destination Repo, and the Content?
* What if I use something like dep solving and I don't have permissions on the deps?
* Also, deps aren't currently resolved in the viewset

## Mental Model

1. Roles provide a specified set of permissions
2. Each permission includes a mode of access and a resource.

## Types of Permissions

### Model Permissions

* The resource is a Model, e.g. a `FileDistribution`, or `FileRepository`.
* The mode of access is dependant on the feature set we want to make, but it would likely be "create" at a minimum.

#### Examples

* "Create a FileDistribution" - Required to create a `FileDistribution`
* "Create a FileRepository" - Required to create a `FileRepository`

### Object Permissions

* The resource is a specific object with a primary key, e.g. `FileRepository(name='foo')`, `FileRemote(name='my_secret_remote')`

* The mode of access is likely: "read", "update", "delete"

#### Read/Update/Delete Examples

* "Read a `FileRepository` instance" - Required to GET a specific `FileRepository` instance, e.g. `FileRepository(name=foo)`

* "Update a `FileRepository` instance" - Required to PATCH a specific `FileRepository` instance, e.g. `FileRepository(name=foo)`

* "Delete a `FileRepository` instance" - Required to DELETE a specific `FileRepository` instance, e.g. `FileRepository(name=foo)`

#### More Complex Examples

Simple objects, e.g. a FileRemote only have read/update/delete permissions on the object instance, but composed objects, e.g. Repositories have RepositoryVersions which present a new challenge. One approach to solving this is to manage RepositoryVerisons as permissions which map to the Repository they are a member of. Here are some examples of that:

* "Create new `RepositoryVersion` for a `FileRepository` instance" - Required for a user to create a `RepositoryVersion` for a specific `FileRepository` instance, e.g. `FileRepository(name=foo)`

* "Delete a `RepositoryVersion` for a `FileRepository` instance" - Required for a user to create a `RepositoryVersion` for a specific `FileRepository` instance, e.g. `FileRepository(name=foo)`

## Existing RBAC Solutions

Pulp wants to use an existing software to add Roles and Permissions concepts to the extent possible. Here are some possible options:

#### Built-in Solutions

* Use [Django's built-in permissions](https://docs.djangoproject.com/en/3.0/topics/auth/default/#permissions-and-authorization)
* Use the [DRF built-in permissions](https://www.django-rest-framework.org/tutorial/4-authentication-and-permissions/#tutorial-4-authentication-permissions).

#### Additional Package Solutions

The [permissions page on djangopackages.net](https://djangopackages.org/grids/g/perms/) gives a lot of options. Below are the ones that seemed most compelling. Please suggest more if one you think should be considered is not listed:

* [django-guardian](https://github.com/django-guardian/django-guardian). Its docs are [here](https://django-guardian.readthedocs.io).
* [drf-accesss-policy](https://github.com/rsinger86/drf-access-policy/). Its docs are [here](https://rsinger86.github.io/drf-access-policy/).

## Evaluation and Discussion of Solutions

#### Django's built-in permissions, docs [here](https://docs.djangoproject.com/en/3.0/topics/auth/default/#permissions-and-authorization)

Summary: not an option

Django's permissions only allow for "Model level" permissions. It cannot provide object-level (aka instance-level) permissions.

#### DRF built-in permissions, docs [here](https://www.django-rest-framework.org/tutorial/4-authentication-and-permissions/#tutorial-4-authentication-permissions)

Summary: an option, but its mostly DIY still for object-level permissions

DRF's permissions provide both model-level and object-level permissions, but the object-level would require Pulp to build ownership data onto every model we want to have managed at an instance level. This is covered in their [object level permissions documentation](https://www.django-rest-framework.org/tutorial/4-authentication-and-permissions/#object-level-permissions) which would require Pulp for every model to:

1. Define an owner somehow as a FK to either a user or group
2. Implement an object-level permission that checks data from (1)

#### django-guardian, docs [here](https://django-guardian.readthedocs.io)

Summary: a good option

It's build on Django's CRUD permissions and focuses on adding object-level permissions. It's the most heavily used permissions package by every metric (stars, forks, django-packages usage numbers, etc).

The upside: It fulfills all the use cases with both Model-level and Object-level capabilities. It would allow plugin writers to define and ship Roles, a set of permissions, and relationships between them.

The downside: The Roles a plugin defines, plugin permission checks, and code to perform permissions assignment after additional objects are created, etc, are all spread out in the application code iteself. Thus it's difficult to assess:

1. What permissions do I need to perform a single operation or workflow?
2. What permissions will I receive after I do something, e.g. if I `docker push image-foo` do I get the permission rights to manage it automatically?
3. What Roles are available and which ones would be right for me?

#### drf-access-policy, docs [here](https://rsinger86.github.io/drf-access-policy/)

Summary: a good option

The upside: Inspired by AWS policy definitions for permissions management allowing permissions checks, the roles that grant them, and the viewset operations they govern to be all contained in one place. Also able to have policy defined in a database allowing each installation to manage the policy and avoid a one-size-fits all solution.

The downside: It sounds to good to be true.

## Open Questions:

### Queryset Isolation?

To what extent do we want to perform queryset isolation based on "Read" permissions as described [here](https://rsinger86.github.io/drf-access-policy/multi_tenacy/)?

### Determining effective permissions?

How can a user determine what permissions they have?

### Determining needed permissions?

How can a user determine what permissions they need for a given operation?

### How will Roles be assigned?

* How will administrators be able to assign/remove a User from a Role?
* What about assigning a Role to a group of users?
* What happens when Roles/Users live outside of Pulp, e.g. in LDAP, and can't have a FK to them?

### Roles outside of Pulp?

* How will Roles defined outside Pulp meet Permissions in Pulp, e.g. LDAP Roles?