| *** markvoelker has quit IRC | 00:01 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:02 | |
| *** markvoelker has quit IRC | 00:04 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:04 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 01:01 | |
| *** harlowja has quit IRC | 01:08 | |
| *** diablo_rojo has quit IRC | 02:59 | |
| *** gouthamr has quit IRC | 03:57 | |
| *** harlowja has joined #openstack-meeting-cp | 04:33 | |
| *** harlowja has quit IRC | 05:54 | |
| *** mgagne has quit IRC | 06:53 | |
| *** mgagne has joined #openstack-meeting-cp | 06:56 | |
| *** mgagne is now known as Guest24103 | 06:56 | |
| *** MarkBaker has quit IRC | 08:12 | |
| *** MarkBaker has joined #openstack-meeting-cp | 08:17 | |
| *** johnthetubaguy has left #openstack-meeting-cp | 10:06 | |
| *** MarkBaker has quit IRC | 10:14 | |
| *** Daviey_ is now known as Daviey | 10:15 | |
| *** MarkBaker has joined #openstack-meeting-cp | 10:24 | |
| *** sdague has joined #openstack-meeting-cp | 10:29 | |
| *** MarkBaker has quit IRC | 11:01 | |
| *** MarkBaker has joined #openstack-meeting-cp | 11:14 | |
| *** jhesketh has joined #openstack-meeting-cp | 12:06 | |
| *** gouthamr has joined #openstack-meeting-cp | 12:39 | |
| *** edmondsw has joined #openstack-meeting-cp | 12:41 | |
| *** lamt has joined #openstack-meeting-cp | 12:58 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 13:43 | |
| *** lamt has quit IRC | 13:47 | |
| *** lamt has joined #openstack-meeting-cp | 13:53 | |
| *** johnthetubaguy has joined #openstack-meeting-cp | 13:54 | |
| *** Guest24103 is now known as mgagne | 14:32 | |
| *** mgagne has quit IRC | 14:32 | |
| *** mgagne has joined #openstack-meeting-cp | 14:32 | |
| *** spilla has joined #openstack-meeting-cp | 14:49 | |
| *** ayoung has joined #openstack-meeting-cp | 15:03 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 15:24 | |
| *** raies has joined #openstack-meeting-cp | 15:50 | |
| *** qwebirc11625 has joined #openstack-meeting-cp | 15:51 | |
| *** qwebirc11625 has quit IRC | 15:52 | |
| *** blancos has joined #openstack-meeting-cp | 15:57 | |
| *** gouthamr_ has joined #openstack-meeting-cp | 15:58 | |
| *** gouthamr has quit IRC | 15:59 | |
| lbragstad | #startmeeting policy | 16:00 |
|---|---|---|
| openstack | Meeting started Wed May 17 16:00:02 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
| openstack | The meeting name has been set to 'policy' | 16:00 |
| lbragstad | ping lbragstad, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, morgan, raj_singh, johnthetubaguy, knikolla, nhelgeson | 16:00 |
| johnthetubaguy | o/ | 16:00 |
| samueldmq | hi | 16:00 |
| edmondsw | o/ | 16:00 |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:00 |
| lbragstad | agenda ^ | 16:00 |
| lbragstad | o/ | 16:00 |
| lbragstad | let see how many folks we have - we might be able to squeeze by with a google hangout | 16:00 |
| knikolla | o/ | 16:00 |
| felipemonteiro | o/ | 16:01 |
| lamt | o/ | 16:01 |
| blancos | o/ | 16:01 |
| *** gagehugo has joined #openstack-meeting-cp | 16:02 | |
| gagehugo | o/ | 16:02 |
| lbragstad | wow - we're getting a pretty good turn out | 16:02 |
| spilla | o/ | 16:02 |
| aselius | o/ | 16:03 |
| ayoung | Heh | 16:04 |
| knikolla | 11, i believe that takes us over the hangout limit. | 16:04 |
| lbragstad | yep - i think so | 16:04 |
| raies | o/ | 16:04 |
| lbragstad | ok - let's go ahead and get started | 16:04 |
| ayoung | Its OK, that was a special occasion. We should try to make IRC work | 16:04 |
| lbragstad | #topic goals | 16:04 |
| *** openstack changes topic to "goals (Meeting topic: policy)" | 16:04 | |
| *** DavidPurcell has joined #openstack-meeting-cp | 16:04 | |
| ayoung | https://etherpad.openstack.org/p/keystone-policy-meeting | 16:05 |
| lbragstad | imo - part of the reason why we seem to stall out on various policy dicussions is because there are *so* many things to fix | 16:05 |
| lbragstad | to help with that | 16:05 |
| lbragstad | I took a stab at defining the goals we want to strive for | 16:05 |
| ayoung | ++ | 16:05 |
| ayoung | 1. Admin-ness | 16:06 |
| ayoung | 2. mapping easy of understanding and main | 16:06 |
| lbragstad | i wanted to be able to provide a document that folks can use as a reference when reviewing or even discussing policy | 16:06 |
| ayoung | 3. default set of roles | 16:06 |
| samueldmq | lbragstad: that sounds great | 16:06 |
| lbragstad | #link https://review.openstack.org/#/c/460344/ | 16:06 |
| lbragstad | I'd love to get some feedback on that ^ | 16:06 |
| lbragstad | not only from keystone folks, but from other projects as well | 16:07 |
| lbragstad | do we have representation here from other projects? | 16:07 |
| ayoung | lbragstad, so, some prioritization | 16:07 |
| johnthetubaguy | I guess I am a nova-ish voice here | 16:07 |
| *** DavidPurcell_ has joined #openstack-meeting-cp | 16:07 | |
| ayoung | I don't think we can do the "standard set of roles" until we have an interim state of "Be able to add a new role to an already running system" | 16:07 |
| lbragstad | johnthetubaguy: glad you could make it :) | 16:07 |
| felipemonteiro | lbragstad: i work on qa, murano, reading it | 16:08 |
| lbragstad | felipemonteiro: awesome | 16:08 |
| ayoung | I think the "standard set of roles" is the right top level goal | 16:08 |
| ayoung | So, one thing we should probably make explicit, somehow, is that "some" role needs to be enforced for every policy check unless explicitly opted out | 16:09 |
| ayoung | there is probably a better way to say that | 16:09 |
| *** nhelgeson has joined #openstack-meeting-cp | 16:09 | |
| *** nhelgeson_ has joined #openstack-meeting-cp | 16:09 | |
| ayoung | but what I want to address is the cases where the current policy checks scope, but no role. We need a good default | 16:09 |
| *** DavidPurcell has quit IRC | 16:09 | |
| johnthetubaguy | So we don't reallt talk about user/operator aims in that policy goals document, its still quite implementation based | 16:09 |
| *** nhelgeson_ has quit IRC | 16:09 | |
| johnthetubaguy | I wonder if stepping back a tiny bit would help here | 16:10 |
| ayoung | johnthetubaguy, did you make it to my talk? I did address some of it there. | 16:10 |
| edmondsw | johnthetubaguy I don't know that I agree with that... I thought it was quite operator based | 16:10 |
| johnthetubaguy | ayoung: didn't make any talks, had forum sessions in nevery slot, I do plan on watching yours ASAP | 16:11 |
| ayoung | johnthetubaguy, feel free to hit me up for the accellerated version | 16:11 |
| ayoung | two slides I want to call out | 16:11 |
| johnthetubaguy | edmondsw: maybe its just the way I am reading it | 16:11 |
| ayoung | https://docs.google.com/presentation/d/1L31_x977Yrz9im3MapBxVUpcQSv7IGTJnCf7s6kbtFc/edit#slide=id.g1d8796a54f_1_75 | 16:11 |
| ayoung | can everyone see that? | 16:11 |
| lbragstad | #link https://www.youtube.com/watch?v=EYYzl0rFCVU&t=147s | 16:11 |
| gagehugo | need permission | 16:11 |
| aselius | yup need permission | 16:11 |
| ayoung | I have a public version somewhere...let me see if I can find it.. | 16:12 |
| edmondsw | ayoung I requested access | 16:12 |
| knikolla | try now | 16:12 |
| knikolla | i updated the permissions | 16:12 |
| lamt | works for me now | 16:12 |
| ayoung | how about https://docs.google.com/presentation/d/1L31_x977Yrz9im3MapBxVUpcQSv7IGTJnCf7s6kbtFc/pub?start=false&loop=false&delayms=3000#slide=id.p | 16:13 |
| johnthetubaguy | slides 17 and 18 right? | 16:13 |
| gagehugo | ayoung: that link works | 16:13 |
| edmondsw | they both work now | 16:13 |
| ayoung | OK, that is preso mode. The two things I want to call out | 16:13 |
| ayoung | Without | 16:14 |
| ayoung | An Explicit | 16:14 |
| ayoung | Scope Check | 16:14 |
| ayoung | Every Project | 16:14 |
| ayoung | Has Access | 16:14 |
| ayoung | to Every Project’s Resources | 16:14 |
| ayoung | GAh | 16:14 |
| ayoung | Heh | 16:14 |
| ayoung | Without An Explicit Scope Check Every Project Has Access to Every Project’s Resources | 16:14 |
| ayoung | Without An Explicit Role Check for an API Every Role Has Access | 16:14 |
| ayoung | every token scoped to that project has access | 16:14 |
| gagehugo | the whole master keyring issue | 16:15 |
| * johnthetubaguy nods | 16:15 | |
| ayoung | gagehugo, yeah...if you don't look too close at my analogy | 16:15 |
| ayoung | so, close those two things should be at the top. | 16:15 |
| johnthetubaguy | from the operator point of view, which are the critical use cases? | 16:16 |
| johnthetubaguy | like I get those are problems that break lots of flows | 16:16 |
| ayoung | johnthetubaguy, #1 thing I've gotten a request is for a read-only role | 16:16 |
| johnthetubaguy | just wondering which flows we should think about the most | 16:16 |
| johnthetubaguy | ayoung: yeah, I guess number 2 is the whole per project admin? | 16:16 |
| ayoung | yep | 16:16 |
| *** jaugustine has joined #openstack-meeting-cp | 16:16 | |
| lbragstad | so this all ties back to admin-ness | 16:17 |
| johnthetubaguy | cool, so those seem like the two things I was expecting to see in the goals doc | 16:17 |
| ayoung | so a default role for all APIs for a service would go a long way to covering those. | 16:17 |
| ayoung | lbragstad, yeah, sortof | 16:17 |
| edmondsw | johnthetubaguy ayoung my #1 operator request is fixing the admin scoping | 16:17 |
| ayoung | edmondsw, good to know. And its is also a pre-req to the other two | 16:18 |
| edmondsw | then #2 making it easier to customize policy | 16:18 |
| edmondsw | and then having better pre-defined roles would come after that somewhere | 16:18 |
| edmondsw | as the ordering is in the spec lbragstad has up on policy goals | 16:19 |
| johnthetubaguy | "customize policy" isn't really specific enough for me, but its good context for sure | 16:19 |
| morgan | ./ | 16:19 |
| morgan | lurking, just recovering from vacation ;) | 16:19 |
| lbragstad | oh man, we have a morgan | 16:19 |
| ayoung | \O | 16:19 |
| edmondsw | "customize policy" = "define my own roles and what they can do" | 16:19 |
| ayoung | cool. | 16:19 |
| samueldmq | morgan: welcome back! | 16:20 |
| ayoung | OK. So...I think I am OK with this Doc as is, providing we make it a living document, and are not afraid to update it as we get better clarity. | 16:20 |
| ayoung | Some of the things we are talking about is mechanism, but the doc does a good job, I think, of abstracting the use cases to general goals | 16:20 |
| johnthetubaguy | edmondsw: I was really meaning, today what many operators want is the read-only role, which causes them to cusomtize stuff | 16:20 |
| lbragstad | i'm good with that - so long as it stays concise and direct | 16:20 |
| ayoung | OK. So, I'm a put my +2 on it | 16:21 |
| ayoung | Any future changes can be posted as their own reviews. What is important for the upcoming release is work items | 16:22 |
| ayoung | and, the priority of those is directed at goal #1 | 16:22 |
| ayoung | Agreed? | 16:22 |
| knikolla | ++ on the whole living document thing. it would be very beneficial as we move forward. | 16:22 |
| knikolla | having a clear documented path of goals | 16:22 |
| edmondsw | johnthetubaguy readonly is one needed role, for sure. But the ability to customize and create whatever role you want is really what I'm after | 16:22 |
| lbragstad | ok - so i have a question | 16:23 |
| johnthetubaguy | edmondsw: totally, I think they are both separate aims, I added a comment in the spec | 16:23 |
| ayoung | Fire away lbragstad | 16:23 |
| lbragstad | we know fixing admin-ness is a priority, but can that be decoupled from determining which role is required to do an operation? | 16:23 |
| edmondsw | johnthetubaguy right... #2 vs #3 in the spec | 16:23 |
| ayoung | lbragstad, yes | 16:23 |
| edmondsw | #2 gives you the ability to create whatever you want | 16:23 |
| lbragstad | johnthetubaguy: ++ | 16:23 |
| ayoung | lbragstad, that is, in essence, a scope check, and should be done first | 16:23 |
| edmondsw | #3 gives you some pre-defined roles so that you don't have to use #2 if you're happy with what we predefine | 16:24 |
| ayoung | for the moment, admin is checked in the oslo-policy mechanism or the nova/keystone equivalents | 16:24 |
| ayoung | and the checks are all done as Or checks | 16:24 |
| ayoung | either the user has Admin or the scope must match | 16:24 |
| ayoung | to ensure adminess, we need an and check like this | 16:25 |
| johnthetubaguy | edmondsm: ah, I think I miss understood your point, I get what you mean now (I think) | 16:25 |
| ayoung | either ((role == admin and is_admin_project ) or (token.project_)id == resource.project_id)) | 16:25 |
| ayoung | note that the == condition ensures that role == admin on the project still works | 16:26 |
| lbragstad | so that's where this starts to get tricky because we'll have to work with each of the projects to ensure the resource they are checking against makes sense within the scope of a project | 16:26 |
| lbragstad | (i.e. instances make sense within project, endpoints do not) | 16:27 |
| ayoung | lbragstad, right. THat has been Sisyphean | 16:27 |
| edmondsw | ayoung more like "(role == <whatever roles you want to allow>) and (is_admin_project or (token.project_id == resource.project_id))) | 16:27 |
| edmondsw | separate role check from scope check | 16:27 |
| ayoung | edmondsw, Yes, that is the end state. I was answering lbragstad 's question about whether we could serialize the work, though | 16:28 |
| ayoung | the role check work can come afterwards | 16:28 |
| edmondsw | I don't think I agree | 16:28 |
| ayoung | but I think you are referring to the "admin" part of that, and, yes, we should be smarter about that | 16:28 |
| *** gouthamr_ has quit IRC | 16:28 | |
| johnthetubaguy | if we had context.is_global_admin implemented, would that help the project do what they need to do? | 16:28 |
| ayoung | edmondsw, think about it as a patch ordering | 16:28 |
| ayoung | johnthetubaguy, you mean context.is_admin_project> | 16:29 |
| edmondsw | I get that you're talking about patch ordering... I don't understand why you think you should split that into separate patches | 16:29 |
| ayoung | and yes, that is required | 16:29 |
| johnthetubaguy | nope | 16:29 |
| edmondsw | I'm not sure you can split it, much less that you should | 16:29 |
| edmondsw | or why you would want to | 16:29 |
| ayoung | edmondsw, because I think role modificiation is a trickier thing to implement, and, even if we go with a policy.json based implementation, we will have trouble getting it into a single, understandable patch | 16:30 |
| edmondsw | ayoung what "role modification" do you think I'm proposing? | 16:31 |
| edmondsw | I don't think I am proposing anything I'd call that | 16:31 |
| ayoung | edmondsw, taking an API that only allows 'admin' and making it accest 'admin or reader' for example | 16:31 |
| lbragstad | this is my super rough idea of what projects would have to do - http://paste.openstack.org/show/609824/ | 16:31 |
| edmondsw | i'm not proposing we add any new roles in this first patch stage | 16:32 |
| ayoung | lbragstad, not quite | 16:32 |
| lbragstad | which would force them to make sense of operations in a global, domain, and project scope | 16:32 |
| ayoung | lbragstad, lets leave domain out for now, as that is keystone only | 16:32 |
| ayoung | its more like: | 16:32 |
| ayoung | if operation is global_scoped: | 16:32 |
| ayoung | if token.is_admin_project == True: | 16:32 |
| lbragstad | (i.e. does it make sense to do instance things in a global sense - no it's a project thing) | 16:32 |
| ayoung | Oh...wait | 16:32 |
| ayoung | I misread what you wrote.... | 16:32 |
| ayoung | yeah, what you have is right | 16:32 |
| *** harlowja has joined #openstack-meeting-cp | 16:32 | |
| lbragstad | \o/ | 16:33 |
| * lbragstad highfives the dog | 16:33 | |
| ayoung | with the exception that is_admin_project might be needed for domain scope operations, too | 16:33 |
| edmondsw | lbragstad I would only change the domain check to allow both domain_scoped token or is_admin_project True | 16:33 |
| lbragstad | ayoung: sure - that could be applied at the project level too | 16:33 |
| ayoung | so. lets leave that out for now, as that is Keystone only, and we can fix that | 16:33 |
| johnthetubaguy | there are user scoped things too for Nova, but that follows the same pattern | 16:34 |
| ayoung | edmondsw, so, why do you think the role stuff needs to be handled along with is_admin_project? | 16:34 |
| edmondsw | ayoung I think you are just misunderstanding me | 16:34 |
| ayoung | johnthetubaguy, what resources are user scoped? | 16:34 |
| ayoung | edmondsw, likely! | 16:35 |
| johnthetubaguy | ayoung: keypairs | 16:35 |
| ayoung | johnthetubaguy, got it | 16:35 |
| ayoung | johnthetubaguy, those are "also" project scoped, right? | 16:35 |
| edmondsw | ayoung I'm not suggesting we add any roles... just that we not tie is_admin_project checks to the admin role... there's no reason or need to do that | 16:35 |
| ayoung | *also* | 16:35 |
| edmondsw | it doesn't help with anything | 16:35 |
| ayoung | edmondsw, roger | 16:35 |
| edmondsw | and it's not the end goal we want | 16:35 |
| ayoung | rodger dodger. Agree | 16:35 |
| edmondsw | ++ | 16:35 |
| ayoung | OK...so on the agenda, I sketched out the pieces that need to be done. | 16:36 |
| ayoung | lines 15 -30 | 16:36 |
| ayoung | hack on it, please | 16:36 |
| edmondsw | so if you have an admin-only policy check, then it would be "((role == admin) and (is_admin_project or (token.project_id == resource.project_id)))" | 16:37 |
| ayoung | edmondsw, right | 16:37 |
| ayoung | edmondsw, and a reader only check would be | 16:37 |
| edmondsw | but an operation that is allowed for any role would be that minus the role == admin part | 16:37 |
| ayoung | "((role == reader) and (is_admin_project or (token.project_id == resource.project_id)))" | 16:37 |
| edmondsw | right | 16:37 |
| ayoung | yes | 16:37 |
| edmondsw | I'd like to get rid of the "any role will do" stuff, but THAT comes later | 16:37 |
| ayoung | and so, with implied roles, we could then make that, implicitly | 16:37 |
| ayoung | "((role == reader or role == admin) and (is_admin_project or (token.project_id == resource.project_id)))" | 16:37 |
| ayoung | without implied roles, that would be added to the policy file | 16:38 |
| ayoung | otherwise, an admin would not be able to to it without also explicitly having the reader role | 16:38 |
| lbragstad | updated - http://paste.openstack.org/show/609825/ | 16:38 |
| ayoung | lbragstad, ++ | 16:39 |
| johnthetubaguy | so is_admin_project seems really odd, that was the feedback in one of the previous discussions, is this something we want to train our operators to do? | 16:39 |
| *** raies has quit IRC | 16:39 | |
| ayoung | OK...so johnthetubaguy can you take on the nova part, or do we need to find someone to do that? | 16:39 |
| lbragstad | johnthetubaguy: i did write up https://review.openstack.org/#/c/464763/ | 16:39 |
| johnthetubaguy | I don't have a job right now, so its tricky to know either way | 16:39 |
| ayoung | johnthetubaguy, it was based on a lot of discussion... | 16:39 |
| lbragstad | which is an alternative | 16:40 |
| ayoung | johnthetubaguy, ah, joy | 16:40 |
| johnthetubaguy | lbragstad: I should read through that | 16:40 |
| ayoung | johnthetubaguy, is_admin_project was based on the way openstack was origianlly designed to do this, at least according to termie | 16:40 |
| edmondsw | lbragstad johnthetubaguy if/when I can find time to help, my priority will most likely be helping in nova | 16:41 |
| lbragstad | my proposal is that we eventually move away from that model | 16:41 |
| ayoung | it also allowed us a way to get global roles without radically modifying the Keystone server | 16:41 |
| johnthetubaguy | now I want us to make progress as fast as possible, but we do need to take care of training operators to do a thing, then changing that a release or two later | 16:41 |
| edmondsw | I will try to help in keystone as well though | 16:41 |
| lbragstad | i have an idea that might allow us to move away from that model without making the projects consuming the information change more than once | 16:41 |
| edmondsw | that sounds nice | 16:42 |
| johnthetubaguy | its the operators that worry me the most here | 16:42 |
| lbragstad | johnthetubaguy: ++ | 16:42 |
| johnthetubaguy | but the minimal project chagnes would be awesome too | 16:42 |
| lbragstad | do folks want to hear my plan? | 16:42 |
| johnthetubaguy | I would prefer something that checks for the concept "global admin" that could be implemented however | 16:42 |
| johnthetubaguy | lbragstad: I do :) | 16:43 |
| edmondsw | can we not switch from is_admin_project to global-scoped role assignments via a db migration? | 16:43 |
| edmondsw | I would think that's just a keystone db migration | 16:43 |
| johnthetubaguy | edmondsw: I am thinking API calls, and general concepts in all our users heads | 16:43 |
| ayoung | edmondsw, yes, we can do that | 16:43 |
| ayoung | its the changes to oslo-context that require changes in the remote projects | 16:44 |
| lbragstad | 1.) implement the is_admin_project stuff but make it so that the token represents something like token.global_scope=True | 16:44 |
| lbragstad | 2.) make oslo.context changes to honor token.global_scope | 16:44 |
| lbragstad | 3.) project consume that and apply it to their operations | 16:44 |
| ayoung | lbragstad, so...what iffffff | 16:44 |
| edmondsw | johnthetubaguy yeah, they would need to understand that "oh, I can take advantage of global-scoped role assignments now as I add new users/groups instead of being tied to what I had defined as is_admin_project" | 16:44 |
| ayoung | we had a library or something to do the check | 16:44 |
| lbragstad | 4.) implement global roles in keystone | 16:44 |
| ayoung | what if we did the scope check in oslo-context itself? | 16:44 |
| lbragstad | 5.) migrate is_admin_project to global role assignment | 16:45 |
| ayoung | and oslo-context could then handle is_admin_project OR global_roles? | 16:45 |
| johnthetubaguy | can't this just be context.is_global_scope? | 16:45 |
| lbragstad | ayoung: right - that's the magic bit that makes it so other services don't care about is_admin_project | 16:45 |
| lbragstad | or global roles | 16:46 |
| johnthetubaguy | cool, I think thats going to be much easier to describe to folks | 16:46 |
| edmondsw | exactly | 16:46 |
| lbragstad | all the other services should care about is token.global_scope == True | 16:46 |
| johnthetubaguy | so whats the check for admin now? | 16:46 |
| lbragstad | then they can evaluate according to their "global" operations at the service level | 16:46 |
| johnthetubaguy | sorry I was thinking back to the ealier paste with the if statements | 16:47 |
| johnthetubaguy | how do they change in this model? | 16:47 |
| edmondsw | johnthetubaguy they look at token.is_global instead of token.is_admin_project... just a rewording | 16:47 |
| lbragstad | yeah | 16:47 |
| edmondsw | as that will be in code, not in policy, it's not a concern for users/operators | 16:48 |
| lbragstad | but the important bit is that it's not exposing implementation details in the interface | 16:48 |
| johnthetubaguy | so if we want a global read_only role? | 16:48 |
| edmondsw | take the read-only role, and assign it with global scope instead of a project scope | 16:48 |
| knikolla | role==reader and token.global_scope | 16:48 |
| knikolla | is_global* | 16:48 |
| johnthetubaguy | so what I mean is, we are really checking for role=admin and token.is_global_scope | 16:48 |
| lbragstad | then bob should be able to get a global token with the reader role | 16:49 |
| edmondsw | johnthetubaguy if you want to restrict something to something that is a global admin, yes | 16:50 |
| johnthetubaguy | so the current admin folks access the APIs, they would fail this new test I assume? | 16:51 |
| johnthetubaguy | what are we doing for the transition? | 16:51 |
| ayoung | the big thing, though, is that Nova is not even properly loading up the context, is it? | 16:51 |
| johnthetubaguy | ayoung: the context object is fine, we don't always pass the target | 16:52 |
| ayoung | johnthetubaguy, we need that | 16:52 |
| johnthetubaguy | unless we pull out all scope checks from the policy file right? | 16:52 |
| johnthetubaguy | I am finding it hard separating all these concerns and making it work across upgrade | 16:53 |
| johnthetubaguy | without feeling like we are about to break everything | 16:53 |
| edmondsw | johnthetubaguy upgrade is tricky... I think the only way we can solve that and maintain backward compat is to have some transitional policy checks that do scope checking | 16:53 |
| ayoung | johnthetubaguy, I'm guessing that the scope checks are in the database now, but I can't see how that would work for global admin operations. But also, Nova must enforce some scope checks, somehow. | 16:53 |
| johnthetubaguy | I had a plan to do all this in Nova, but its a long old process, and the team happy to do it are no more, but struggling to see the lighterweight approach here | 16:53 |
| johnthetubaguy | ayoung: it all depends on which exact API we are talking about | 16:54 |
| ayoung | OK, first question, is it even possible to do this in oslo-context, assuming we load the target | 16:54 |
| johnthetubaguy | what is "this"? | 16:54 |
| ayoung | johnthetubaguy, scope check IAW the rules above | 16:55 |
| ayoung | so, ignoring the role: | 16:55 |
| ayoung | (is_admin_project or (token.project_id == resource.project_id))) | 16:55 |
| edmondsw | e.g. servers:list:other_projects = "role:admin and is_admin_project==True" and have the code use that as an override for the normal scope checks it would do... and deprecated this for eventual removal | 16:55 |
| ayoung | and, when policy runs, have it do "context.scope_check" | 16:55 |
| johnthetubaguy | the bit I thought was going in context was the extra is_global_scope = True/False property | 16:55 |
| ayoung | what if... | 16:56 |
| ayoung | we did that anyway, and have the scope check ignore the target if it is not set? | 16:56 |
| ayoung | then this resolves to a series of smaller bugs in Nova/cinder etc to get the scope checks right? | 16:56 |
| johnthetubaguy | I did create this thing: https://review.openstack.org/#/c/435485/2/nova/context.py | 16:56 |
| ayoung | johnthetubaguy, yeah, that. but it would be nice if it were in oslo-context, so we could do the same thing in cinder | 16:57 |
| knikolla | ++ on oslo | 16:57 |
| johnthetubaguy | ayoung: yeah, makes sense, its just that would need to be called from each bit of the API separately, the way I initial proposed this | 16:58 |
| lbragstad | two minute warning | 16:59 |
| gagehugo | hmm | 16:59 |
| johnthetubaguy | is the best way forward to do a POC in keystone for this change, that includes dealing with upgrade, etc? | 16:59 |
| johnthetubaguy | this is my nova POC: https://review.openstack.org/#/c/435485 but it would take lots of work to add that everywhere | 17:00 |
| ayoung | johnthetubaguy, not a bad starting point | 17:00 |
| lbragstad | we're out of time | 17:00 |
| lbragstad | do folks want to spill into #openstack-dev or #openstack-keystone? | 17:01 |
| ayoung | lbragstad, yes please | 17:01 |
| edmondsw | johnthetubaguy the problem with a keystone-only PoC is that the admin-is-special-across-projects thing is very different in keystone than in nova/elsewhere | 17:01 |
| ayoung | is anthing scheduled in here for the next hour? | 17:01 |
| johnthetubaguy | edmondsw: ah, that could be a problem | 17:01 |
| ayoung | edmondsw, yes, but... | 17:01 |
| *** gouthamr has joined #openstack-meeting-cp | 17:02 | |
| ayoung | I think we have keystone policy enforce on oslo-context now. If we don't we should make that happen anyway, and we can do the heavy liftin in oslo | 17:02 |
| johnthetubaguy | there is a bit missing for me, between oslo-context and the current policy check calls | 17:02 |
| edmondsw | ayoung I definitely agree with leaning on oslo here as much as possible. I'm inclined to implement the logic the way it needs to be without that first, though, and then figure out how to clean it up with moving things into oslo | 17:03 |
| johnthetubaguy | ++ for a move to olso after we have it working | 17:03 |
| ayoung | ++ | 17:03 |
| ayoung | so, gagehugo you up for that? | 17:03 |
| johnthetubaguy | the bit I am missing on the Nova side is how we avoid touching every API call (like proposed in https://review.openstack.org/#/c/435485), maybe we can't avoid that, and thats fair enough. | 17:04 |
| gagehugo | ayoung sure | 17:05 |
| lbragstad | we're going to have to end the meeting | 17:05 |
| * johnthetubaguy has to go and cook his dinner | 17:05 | |
| lbragstad | i don't want to roll over | 17:05 |
| edmondsw | johnthetubaguy unfortunately I think we will need to touch every API call... I don't see a way around that | 17:05 |
| johnthetubaguy | edmondsw: OK, maybe this can be the POC then: https://review.openstack.org/#/c/435485 | 17:06 |
| *** raies has joined #openstack-meeting-cp | 17:06 | |
| edmondsw | I'd like the PoC to take several different hard cases and show that we can solve them... not be a general change like that | 17:07 |
| edmondsw | i.e. actually prove something :) | 17:08 |
| *** DavidPurcell_ has quit IRC | 17:08 | |
| *** stvnoyes1 has left #openstack-meeting-cp | 17:11 | |
| *** MarkBaker has quit IRC | 17:14 | |
| edmondsw | lbragstad need to end the meeting | 17:15 |
| lbragstad | we are going to have to end the meeting | 17:15 |
| lbragstad | #endmeeting | 17:15 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:15 | |
| openstack | Meeting ended Wed May 17 17:15:46 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:15 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-17-16.00.html | 17:15 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-17-16.00.txt | 17:15 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-05-17-16.00.log.html | 17:15 |
| *** gagehugo has left #openstack-meeting-cp | 17:17 | |
| *** felipemonteiro has quit IRC | 17:18 | |
| *** harlowja has quit IRC | 17:26 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 17:39 | |
| *** felipemonteiro has quit IRC | 17:49 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 17:52 | |
| *** felipemonteiro has quit IRC | 17:56 | |
| *** ayoung has quit IRC | 18:41 | |
| *** raies has quit IRC | 18:45 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 18:49 | |
| *** MarkBaker has joined #openstack-meeting-cp | 18:57 | |
| *** MarkBaker has quit IRC | 18:57 | |
| *** stvnoyes has joined #openstack-meeting-cp | 19:14 | |
| *** blancos has quit IRC | 19:29 | |
| *** harlowja has joined #openstack-meeting-cp | 19:39 | |
| *** harlowja has quit IRC | 19:53 | |
| *** harlowja has joined #openstack-meeting-cp | 19:57 | |
| *** harlowja has quit IRC | 20:00 | |
| *** lamt has quit IRC | 20:33 | |
| *** lamt has joined #openstack-meeting-cp | 20:35 | |
| *** gouthamr has quit IRC | 20:44 | |
| *** gouthamr has joined #openstack-meeting-cp | 21:15 | |
| *** sdague has quit IRC | 21:22 | |
| *** spilla has quit IRC | 21:26 | |
| *** edmondsw has quit IRC | 21:27 | |
| *** edmondsw has joined #openstack-meeting-cp | 21:28 | |
| *** edmondsw_ has joined #openstack-meeting-cp | 21:31 | |
| *** jaugustine has quit IRC | 21:32 | |
| *** edmondsw has quit IRC | 21:32 | |
| *** edmondsw_ has quit IRC | 21:36 | |
| *** harlowja has joined #openstack-meeting-cp | 22:02 | |
| *** harlowja has quit IRC | 22:18 | |
| *** benj_ has joined #openstack-meeting-cp | 22:24 | |
| *** lamt has quit IRC | 22:57 | |
| *** lbragstad has quit IRC | 23:10 | |
| *** gouthamr has quit IRC | 23:12 | |
| *** gouthamr has joined #openstack-meeting-cp | 23:20 | |
| *** pewp has quit IRC | 23:38 | |
| *** pewp has joined #openstack-meeting-cp | 23:38 | |
| *** felipemonteiro has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!