# RBAC User-scenarios for pulp_RPM
* Assumes RBAC exists to delegate responsibility from the pulp-superuser-holder
* Assumes actions that affect the whole instance will be more closely-held
* Assumes most useful to be able to delegate daily-operations
* Assumes whole-instance administrative roles do most of the modifications
* [ttereshc] not sure, system-wide permissions or groups-of-users; imo, for small setups it's likely the former, for large ones is the latter.
* Assumes most users have read-only access
* Assumes read-only can be further restricted to user/groups-of-users
* Assumes client-access-to-distributed-repos is a separate issue
* who owns setting up content-guards?
* [ggainey] Pulp- or Repository-Superuser? (under Five User Types)
## As a Pulp administrator, I want to...
* Allow certain users to administer repositories
* CURDL Repository
* RL Remote
* [ttereshc] DL RepositoryVersion
* [ttereshc] RL Content
* [ttereshc] not sure what the real life example for that role is, I'd think that "administer repos" is that I can do anything with repos, incl. publish/distribute, import/export, upload, etc.
* [ggainey] I separated Remotes because Remotes have authentication involved. Had envisioned a list of blessed-Remotes that a Repository admin could use to sync from
* no idea how actually-useful that is, it was just a thought in my brain
* Allow certain users to make Repository content public
* Allow certain users to administer remotes
* CURDL Remote
* Allow certain users to copy content between repositories
* advanced copy
* Allow certain users to manage custom content
* CURDL RPM, Advisory, Modulemd et al, comps, etc
* modify Artifact-to-Repository
* Allow certain users access to import/export functions
* CURDL Exporter/Importer
* Pulp- or Repo-Superuser only?
* potentially *large* impact on instance (disk usage can potentially be doubled)
* Allow groups-of-users access to specific groups-of-repositories
* RL Repository/RPM/Advisory/etc
* [ttereshc] Allow groups-of-users to have the same roles as described above for certain users
## Five User-Types
(names subject to change, ggainey made these up)
* Pulp Superuser
* gets to do All The Things, to All The Things
* Repository Superuser
* trusted by the Pulp Superuser, RPM Repo SME
* gets to do Repo Setup
* create/delete repository/remote entities
* ??gets to create user-groups and repo-groups, and link them??
* Repository Administrator
* trusted by the Repository Superuser to do daily-repo-related-tasks
* gets to do sync/publish/distribute
* may be limited to a specific set/group of existing repositories
* cannot create/delete repositories
* why no create/delete?
* these two actions have an instance-level impact
* repo-existence has impact on the entire instance (disk/mem/cpu)
* repo-deletion impacts pulp-instance consumers/clients
* Repository Consumer
* gets read-only access to repos/set-of-repos
* Content Creator
* trusted by the Repository Administrator for a given repo/set-of-repos
* gets to add/delete custom content to a repo
* Q: is there a system-level Content Creator who gets to add Artifacts for anyone to use?
* Are there administrators who can create anything, and then only see/modify the things they've created?
* Some properties (e.g. repo/remote name) are unique globally. Is this a problem? Users can steal names from each other w/o any recourse.
* Can administrators limit access to the Instances they own? Or is that a site-admin function?
* What about signing?
* How "multi-tenant" are we thinking?
* [ttereshc] if we separate publish/distribute from sync, does it mean that users with out that role can't configure auto-publish/distribute? Such checks won't be easy to have at the viewset level.
## Meeting Notes
* need to give ipanova the answers she needs to take back to the RBAC mtgs
* high-level use-cases
* fine-grained vs system-wide-roles
* initial policy is 'just' default
* admin can modify as desired
* do roles apply cross-plugins
* use-case: Team1 is allowed to do repo-work based on distribution-path, Team2 under a diff distribution-path
* multi-tenant issues are Issues that can't be solved by RBAC
* global-to-plugin naming, for example, is bad in a multi-tenant sense
* introducing namespace - does it alleviate grouping issue?
* Look at what AWS CodeArtifact does
* can I have access to only-a-subset of objects vs system-wide All The Objects?
* how can we limit access to the list of distributions available to be consumed from Pulp?
* RBAC can only limit Pulp-REST-API, not yum-user - yum/dnf-user is limited via ContentGuard?
* AI: ggainey to try and put verbiage around four user-hats discussed, email group for review
* AI: group to continue discussion at Thu RPM Team mtg
###### tags: `RBAC`