owned this note
owned this note
Published
Linked with GitHub
# Galaxy/pulp RBAC user stories
## Personas
* Administrator - The caretaker of the system
* Content Administrator (CA) - someone who manages the content in the system and various repos
* Automated User -
* Namespace Owner - A content owner of a namesapce
* Partner Engineer - An owner who can administrate things on behalf of an external partner
## Object Types
* Repository
* Repository Version
* Remote
* Distribution
* Namespace
* Synclist
* Content
* Users (via /ui/users API)
## Repository Use Cases
* When listing Repositories I can only see Repository objects I have view_repository permission.
* I can create a Repository with the add_repository permission
* I can view any Repository I have the view_repository permission for
* I can modify any Repository I have the change_repository permission for
* I can delete any Repository I have the delete_repository permission for
* **I can create/delete RepositoryVersions for this Repository only if I have the modifyrepocontent permission**
* **I can sync to create a new RepositoryVersion for this Repository iff I have**
* **modify_repo_content permission**
* **view_remote permission on the remote**
#### Auto-assigned permissions
* When creating a Repository I recieve view, modify, delete, and modify_repo_content permissions
## Remote Use Cases
* When listing Remotes I can only see Remote objects I have view_remote permission.
* I can create a Remote with the add_remote permission
* I can view any Remote I have the view_remote permission for
* I can modify any Remote I have the change_remote permission for
* I can delete any Remote I have the delete_remote permission for
#### Auto-assigned permissions
* When creating a Remote I recieve view, modify, and delete permissions
## Distribution Use Cases
* When listing Distributions I can only see Distribution objects I have view_distribution permission.
* I can create a Distribution with the add_distribution permission
* I can view any Distribution I have the view_distribution permission for
* I can modify any Distribution I have the change_distribution permission for
* I can delete any Distribution I have the delete_distribution permission for
#### Auto-assigned permissions
* When creating a Distribution I recieve view, modify, and delete permissions
## Namespace Use Cases
* When listing Namespaces I can only see Namespace objects I have view_namespace permission.
* I can create a Namespace with the add_namespace permission
* I can view any Namespace I have the view_namespace permission for
* I can modify any Namespace I have the change_namespace permission for
* I can delete any Namespace I have the delete_namespace permission for
#### Auto-assigned permissions
* When creating a Namespace I recieve view, modify, and delete permissions
## SyncList Use Cases
* When listing Synclists I can only see Synclist objects I have view_SyncList permission.
* **I can create a SyncList with the add_SyncList permission if I also have modify_repository for the source repo**
* I can view any SyncList I have the view_SyncList permission for
* I can modify any SyncList (add/remove collections, add/remove namespaces) I have the change_SyncList permission for
* I can delete any SyncList I have the delete_SyncList permission for
#### Auto-assigned permissions
* When creating a synclist for myself, I recieve view, modify, and delete SyncList permissions
* **When create a synclist for someone else, they receive view, modify**
#### Content Use Cases
* **When uploading a collection, I can only upload if I have the modify_repo_content permission on the repository the distribution is pointing at**
## Not Covered Yet
* Tasks (pulpcore RBAC is learning this)
## Notes, comments, feedback
### Steps needed
* Pulp based viewsets should mostly just work
* Any views not based on pulp base viewsets may need to be updated to use them
* For Object types / views, reuse or add an AccessPolicy (based on https://rsinger86.github.io/drf-access-policy/)
* See https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC#diff-b8a33258feb0183716da827efd0b4102R16 for an example
### Misc
* AccessPolicy can be assigned or mapped to users or groups
* via django auth backend
* (ie, LDAP, or RH SSO account info passed to automation-hub via http headers)
* AccessPolicy is meant to be pluggable. ie, standalone and cloud.redhat.com can and should have different policies
* The RBAC policy also includes QuerySetFilter implems (ie, only seeing the objects you have read perms for)
### Questions
* How does pulp/galaxy_ng RBAC interwork with cloud.redhat.com "platform" RBAC service?
* "" but for Tower RBAC
## Oddments, strangelets, and assorted ephemera
### meeting notes