RBAC User-scenarios for pulp_RPM

# 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 * Sync * [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 * Publish * Distribute * 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 * Export * Import * 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? ## Questions * 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 ### 21-JUN * 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 * https://docs.aws.amazon.com/codeartifact/latest/ug/domain-policies.html * https://docs.aws.amazon.com/codeartifact/latest/ug/domains.html * https://docs.aws.amazon.com/codeartifact/latest/APIReference/Welcome.html * 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`

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.