14:01:06 <dkliban> #startmeeting Pulp Triage 2019-11-20
14:01:06 <dkliban> #info dkliban has joined triage
14:01:06 <dkliban> !start
14:01:06 <pulpbot> Meeting started Wed Nov 20 14:01:06 2019 UTC.  The chair is dkliban. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:06 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:06 <pulpbot> The meeting name has been set to 'pulp_triage_2019-11-20'
14:01:06 <pulpbot> dkliban: dkliban has joined triage
14:01:30 <dawalker> #info dawalker has joined triage
14:01:30 <dawalker> !here
14:01:30 <pulpbot> dawalker: dawalker has joined triage
14:01:57 <dawalker> I think as long as we just use it as is without any "next" commands it will just log everything, right?
14:02:01 <bmbouter> we are going to temporarily use this etherpad https://etherpad.net/p/Pulp_-_RBAC_Use_Cases
14:02:09 <dkliban> yep
14:02:22 <bmbouter> and then I'll move the content to a drive doc after the meeting and share it back out
14:02:28 <dkliban> sounds good
14:02:35 <mikedep333> #info mikedep333 has joined triage
14:02:35 <mikedep333> !here
14:02:36 <pulpbot> mikedep333: mikedep333 has joined triage
14:03:11 <bmbouter> I'd like anyone who has a use case to write it in that doc to get us started
14:03:12 <dawalker> cool
14:06:04 <daviddavis> #info daviddavis has joined triage
14:06:04 <daviddavis> !here
14:06:05 <pulpbot> daviddavis: daviddavis has joined triage
14:06:17 <dalley> #info dalley has joined triage
14:06:17 <dalley> !here
14:06:17 <pulpbot> dalley: dalley has joined triage
14:06:50 <bmbouter> ok I see some there for starters
14:07:25 <daviddavis> bmbouter: what's the scope of rbac? just users? not like orgs or anything else
14:08:09 <daviddavis> also, are we doing user roles at all? like administrators
14:08:20 <bmbouter> I think orgs, to be meaningful (to me) we need to have it apply w/ groups and also those groups can't be defined in pulp
14:08:24 <bmbouter> wdyt?
14:08:38 <dkliban> yeah
14:08:58 <dkliban> we definitely wants orgs that are defined outside of pulp
14:09:14 <bmbouter> yeah the easiest thing to do is not that
14:09:24 <dkliban> lol
14:09:33 <bmbouter> but to be meaningful we can't ask people to "replicate" users in groups into pulp
14:10:40 <dkliban> yeah ... but i think pulp will need to replicate it
14:11:05 <dkliban> i am thinking that we want to apply RBAC at the database level
14:11:14 <bmbouter> I imagined not replication but service integration
14:11:25 <dkliban> and in order to do that pulp needs to have information about the users/orgs in the db
14:11:59 <bmbouter> perhaps, but let's talk use cases
14:12:11 <dkliban> yep .... do we want to start on line 3?
14:13:46 <bmbouter> yes that's the one I submit to capture that requirement
14:14:07 <bmbouter> as in "groups" are defined outside of pulp itself
14:14:13 <daviddavis> re: line 3. is this any user that can do this? seems like we should have some concept of pulp admin
14:14:30 <bmbouter> I call that specifically for groups because authentication already correctly identifies a user today
14:14:52 <bmbouter> daviddavis: I want to reword to focus on the user
14:15:35 <bmbouter> I reworded it some
14:15:48 <dkliban> that sounds better
14:15:54 <bmbouter> also these are starter use cases, not a situation where we accept and we're committed
14:16:01 <dkliban> lol
14:16:19 * mikedep333 writes use cases from a previous job as a Katello/Satellite user.
14:16:50 <bmbouter> more questions/idea on L#3, or can we move to the others
14:16:53 <dkliban> i am good with accepting line 3 as is now.
14:17:09 <bmbouter> I wrote L#5 but I think it's similar to the one below
14:17:13 <mikedep333> We should be thinking of CI pipeline use cases. Where pulp is the artifact storage at the end.
14:17:36 <bmbouter> mikedep333: that sounds good
14:17:48 <dkliban> bmbouter: do you mean line 5 and 7 are similar?
14:17:56 <bmbouter> yes
14:18:00 <bmbouter> I'm removing L#5 (mine)
14:18:05 <dkliban> ok
14:18:20 <daviddavis> new line 5 leaves some questions about who has access to give permissions
14:18:45 <daviddavis> +1
14:19:30 <dkliban> so line 5 is about giving specific users access and line 7 is about doing the same thing on the group level
14:19:40 <daviddavis> that's my understanding
14:20:29 <dkliban> are there any questions about line 5?
14:21:09 <dawalker> are there any other "levels" of access than admin and some level of granted permissions user?
14:21:27 <dawalker> like are there multiple admin levels or anything else we haven't covered?
14:24:38 <dawalker> I'm going to assume just boolean admin yes/no, everyone else is a user.
14:24:52 <dkliban> what we have described so far only has one level of admin and that allows the user to do everything
14:25:02 <dawalker> ok
14:25:05 <dawalker> next?
14:25:34 <bmbouter> is that administrative user a pulp user?
14:25:50 <bmbouter> I don't imagine the pulp admin is in control as much as whoever is administrating the IDM
14:26:01 <bmbouter> identity management system == IDM == ldap
14:26:17 <dkliban> yeah ... the IDM should define who the admin for pulp is
14:26:39 <daviddavis> are you all imagining that an IDM will be required to use pulp's rbac?
14:26:48 <dkliban> pulp needs to be configured to know what 'group' in the IDM is the 'admin' group for pulp
14:26:57 <bmbouter> daviddavis: it's a good question
14:27:23 <bmbouter> I'm hesitatant to try to have a light idm inside of pulp
14:27:33 <bmbouter> but I can see why some segment of users would be really into that
14:27:53 <dawalker> noooo
14:28:05 <bmbouter> daviddavis: to get the superset of use cases out there could you articulate that need as a use case itself?
14:28:10 <dawalker> I really think we should focus on what we're good at and not reinvent the wheel to add entirely different functionality
14:28:17 <dawalker> I liked the initial interfacing idea
14:28:39 <daviddavis> IDM seems like the easy part
14:28:50 <daviddavis> getting the perms management right seems hard
14:29:32 <bmbouter> I believe articulating that "I don't need a separate" system/service would be valuable
14:29:35 <bmbouter> as a use case
14:30:11 <dkliban> yep
14:30:18 <dawalker> what's the largest group size, ballpark?  Are we talking an admin and a group of 5 users or are we talking hundreds where manual adding would be out of the question?
14:30:24 <daviddavis> yea, at the very least, users should be able to use pulp without an IDM. whether they get rbac or not seems debatable
14:30:29 <bmbouter> they come in all the sizes I think
14:30:58 <dawalker> +1 they shouldn't *have* to have another service
14:31:19 <bmbouter> w.r.t L#5 and L#6 I was hoping to always use a "group"
14:31:42 <bmbouter> as in membership to a group is what gives a user perms, (the Role in RBAC)
14:32:25 <bmbouter> so I propose the strikethough edit on L#5
14:32:53 <dkliban> bmbouter: then we should just remove line 5
14:33:07 <dkliban> cause line 7 captures that
14:33:16 <bmbouter> oic then +1 to that
14:33:19 <bmbouter> I agree
14:33:22 <daviddavis> let's strikethrough?
14:33:29 <daviddavis> or nevermind
14:33:36 <bmbouter> +1 remove to keep content simple
14:34:09 <bmbouter> ok so the new L#5, any concerns/thoughts on that?
14:35:27 <daviddavis> do admins assign these resources individually?
14:35:46 <daviddavis> ah, I see someone's updated the use case
14:35:58 <bmbouter> I modified some to call them out as object-level permissions
14:36:34 <bmbouter> daviddavis: I think there are two scenarios (at least)
14:37:08 <bmbouter> 1) these objects already exist and the admin user is applying user/perms to them (that's L#5 and the easy case)
14:37:45 <bmbouter> 2) the admin assigned users to groups, new objects (content, repos, etc) get created and permissions get auto-created
14:38:55 <dkliban> yep
14:38:56 <daviddavis> makes sense, I don't see 2 captured on this etherpad. should we add it?
14:39:05 <bmbouter> daviddavis: yes somehow
14:39:23 <bmbouter> in my reading prior to this meeting I've been reading that some folks do "object level perms"
14:39:42 <bmbouter> that's really (1) btw because each object is owned by 1 role
14:40:03 <dkliban> what about multiple roles owning an object?
14:40:19 <bmbouter> and others do "view based permissions" that's a permission model where it's positioned on what actions a user can take, e.g. I can or cannot create a new repo, the existing objects will never tell you that
14:40:55 <dkliban> brb
14:41:07 <bmbouter> yes multiple roles owning an object it straightforward in the "assemble the super set of object level perms" but its not straightforward in terms of what a view can do
14:41:51 <bmbouter> let's revisit/integrate view perms later I think L#5 captures the object-level concept well
14:42:03 <bmbouter> and I'd like to cover all the suggested use cases in the 18 min remaining
14:42:09 <daviddavis> ha
14:42:10 <bmbouter> moving to L#7?
14:42:17 <daviddavis> yea
14:43:59 <bmbouter> conceptually this need is simple, content read/access is role based, so two users who sync the same repo will each see their "own"content in the senes that if you delete one (the content not the repo association) the other is still in tact
14:44:09 <bmbouter> and this is full re-download for exapmle on the second sync
14:44:18 * bmbouter did not write this use case but has thought about it for a while
14:44:59 <daviddavis> I guess we'll have to manage a set of views into content
14:45:00 <dkliban> yeah ... i wrote that one
14:45:20 <bmbouter> this use case is key to legit multitenancy
14:45:20 <daviddavis> if I "create" a content unit that already exists, I get permissions to view it
14:45:30 <bmbouter> yes but you have to re-supply the bits
14:45:38 <bmbouter> that seems inefficient (and it is) but it's extremely important
14:46:10 <bmbouter> consider sensistive content inside pulp, not consider spoofing the sha256 of that content and you don't resupply the binary data itself, now you can bring in someone else's content...
14:46:19 <bmbouter> s/not consider/now consider/
14:46:55 <bmbouter> alice uploads sensitive contnet, eve sync's in a spoofed repo w/ matching sha256 hashes and nevras, pulp makes alice's secure content available to eve
14:47:06 <dkliban> yeah
14:47:56 <bmbouter> thoughts on this wording for now?
14:48:03 <daviddavis> also, what about content that matches the unique_together fields but the other fields differ?
14:48:38 <bmbouter> we'll have to adjust that to rfer to the content role that "owns" the content I imagine
14:48:45 <bmbouter> in addition to unique_together
14:49:16 <daviddavis> I see
14:50:24 <bmbouter> I'm ok to accept L#7 as a descriptoin of that
14:50:53 <dkliban> cool ... i don't have a better description either
14:50:58 <dawalker> yeah. ten minutes.  next line?
14:51:03 <bmbouter> yes
14:51:17 <bmbouter> L#9 looks straightforward and that makes sense to me
14:51:28 <bmbouter> also L#12 too
14:51:43 <bmbouter> these are well written use cases because they are very clearly rooted in a user workflow
14:51:53 <mikedep333> Thanks :)
14:52:25 <bmbouter> any concerns/discussion on L#9 or L#12?
14:53:22 <dawalker> nope, both are good
14:53:35 <bmbouter> ok stop me we need more discussion on them
14:53:43 <bmbouter> L#13 I think captures well what we talked about earlier
14:53:50 <dkliban> L#9 - we need to make it more specific, but i don't thikn we can do that without defining what constitutes an environment ifn Pulp
14:54:16 <dkliban> environment could be a tag that's applied to a Distribution
14:54:20 <bmbouter> mmmmm
14:54:30 <dkliban> or an environment could be a specific Distribution
14:54:38 <bmbouter> dkliban: want to capture that in an idea section at the bottom?
14:54:46 <dkliban> i will
14:54:56 <bmbouter> ty
14:55:14 <bmbouter> I need to write something to capture the view permissions but with our time ending I'm going to take an an AI
14:55:24 <bmbouter> I propose we meet again in 1 week and I can schedule
14:55:35 <dkliban> +1
14:55:36 <bmbouter> wdyt about ^ (or any closing comments?)
14:57:59 <dawalker> I'd like to see more involvement/input from actual users or just more team members if possible, but I'm ok with just this small working group of you all given the quality of research and thought you've put into it as well.
14:59:21 <daviddavis> dawalker: +1 to more external input
15:00:13 <dawalker> bmbouter, do you intend to write up what you've got so far and share to a mailing list?
15:03:36 <dawalker> (I noted you mentioned the etherpad was temporary for this meeting since it's getting shut down)
15:05:53 <dkliban> #endmeeting