# RBAC Meeting Minutes - May 7, 2020 ###### tags: `RBAC`, `meeting`, `Minutes` ## Agenda * What is our goal today * Who are the stakeholders and how do we satisfy their needs? * What is a resource? * What needs does your plugin have that aren't represented in the documenent currently? * Open Question: Queryset Isolation? * Open Question: Determining effective permissions? * Open Question: Determining needed permissions? * Open Question: How will Roles be assigned? * Open Question: How will this work with external Roles, e.g. LDAP * What are our next steps ## Notes * What are our goals? * determine some of the answers to the open question * how do we plan on Roles being assigned? * how granular do we want our permissions to be * Who are the stakeholders and how do we satisfy their needs? * To establish a common terminology, e.g. a resource * What are our next steps after this meeting? * Who are our stakeholders? * Our users, e.g. Bin Li on pulp-list and @misa * anyone with multi-user needs * Plugin writers * galaxy_ng * pulp_container (each repository needs to be readable by multiple groups but writable by a single group) * pulp_rpm (complicated-model issues) * Katello is not a stakeholder because they already have RBAC outside * Need to ensure we don't disturb that * (dalley Q: should we make Pulp RBAC compatible w/ Katello needs so that they could eventually defer to Pulp? Does Katello have very different needs than other users in this area?) * Content Delivery Team * multi-user needs * What is a resource? * a *specific* Thing (a specific Repository that exists) * a *class* of Things (e.g., the model 'Repository') * A Thing that has permisions granted on it * Permissions * Actions that can be performed on a resource. e.g.: read, create, update, delete * Some Actions are complex (e.g., 'sync' could be a specific named Permission) * static vs dynamic permission evaluation * static - evaluated at REST API/incoming viewset time * dynamic - evaluated as (for example) a Task is executing (see Import use case below) * Role ideas * Repository Admin - has all permissions * Repository Users - has only the permission(s) allowed by the Roles assigned to that User * Where do we enforce permissions? * Are we going to enforce permissions at the REST API level (django view)? * What happens when the REST API (view) doesn't have a specific model associated with it? ## Whiteboard/parking-lot * RE Model-lvl permissions: do they grant the same/implied access to all Objects of that Model? * What about implied permissions (e.g., if I can Create a Repository, should I have 'implied' update/delete access to the Repository *and its contents*?) * Use case: allow to create distributions within a certain namespace * What about situations where there are many resources? * What about use-cases where the REST call creates a Task, that then does complicated things? * A complicated 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 thet Repository * How do I know that this won't work? * Alternately - if we only enfore at viewset, how could this proposal keep this from happening? * Do we need both 'static' *and* 'dynamic' permissions/roles at first-release? * Would be excellent if we could reuse "resource" backend to implement "CreatedResource" and eliminate the use of GenericForeignKey ## Action Items * bmbouter to write up use case roundup by May 12 via pulp-dev * bmbouter to search pulp-list and pulp-dev for RBAC needs * everyone to add complicated use cases to document https://hackmd.io/6rmwt_tgQTuFsfAJ4B2sXw