Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-16
16:08:22 lbragstad mriedem: imo (which could be wrong), the ability to set that kind of stuff should be system administrator territy
16:08:27 lbragstad territory*
16:08:28 mriedem # so we avoid extra imports here
16:08:28 mriedem efried: this? # NOTE(markmc): this is imported before monkey patching in nova.cmd
16:08:40 efried mriedem: Yes. Wasn't sure if that referred to the same monkey patching you're axing.
16:08:40 mriedem efried: that's talking about eventlet monkey patching
16:08:44 mriedem not "hack features into nova"
16:08:44 efried okay, cool.
16:08:50 openstackgerrit Vladyslav Drok proposed openstack/nova master: Placement: allow to set reserved value equal to total for inventory https://review.openstack.org/564838
16:08:58 mriedem nova/cmd/__init__.py monkey patches eventlet
16:09:12 mriedem er whatever, you get it
16:09:29 efried +A
16:09:50 mriedem rhNKA
16:09:51 mriedem HA
16:09:53 mriedem *thanks
16:10:21 mriedem lbragstad: ok, you've gone over my head, but i haven't gotten to POST and PUT for allocations yet
16:10:30 mriedem also, where are scope types defined? keystone?
16:10:43 lbragstad they are defined at the service
16:10:57 lbragstad technically in the policy rules
16:10:58 mriedem using a config option?
16:10:59 mriedem oh
16:11:06 mriedem https://docs.openstack.org/oslo.policy/latest/user/usage.html?highlight=scope_types#setting-scope doesn't tell me anything about that
16:11:11 lbragstad but they should correspond to the different token scopes you can get from keystone
16:11:38 lbragstad " During enforcement, the information in scope_types is compared to the scope of the token used in the request."
16:11:40 mriedem and the token scopes from keystone, are those a finite hard-coded list or per deployment?
16:11:58 lbragstad nope - a project scoped token and a system scoped token should exist in every deployment
16:12:08 mriedem right, let me ask this way: if i set scope_types on a rule in code, how do i know what a valid scope type is? foo bar baz?!
16:12:18 mriedem is that doc'ed somewhere?
16:13:00 mriedem https://docs.openstack.org/keystoneauth/latest/api/keystoneauth1.access.html?highlight=scope#keystoneauth1.access.access.AccessInfo.scoped
16:13:23 lbragstad http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html
16:15:58 mriedem so looks like scope_types can include project, system, domain, trust, right?
16:16:25 lbragstad technically - trust's are useless without projects and must include a project, so trust-scoped tokens are essentially project scoped
16:16:32 lbragstad (the usability is weird...)
16:16:41 lbragstad ideally, just 'project' and 'system' for now
16:16:46 lbragstad *maybe* 'domain' in the future
16:17:23 mriedem so would it be fair to put something into either https://docs.openstack.org/oslo.policy/latest/user/usage.html?highlight=scope_types#setting-scope or the "enforce_scope" config option help saying, "these are the valid scope types and what they mean"?
16:17:31 mriedem or at least link to some other doc that defines the valid scope types
16:17:47 lbragstad ++
16:17:56 lbragstad yeah - that was probably an oversight on my part
16:18:00 lbragstad and probably a doc bug
16:18:21 mriedem i can report it, but where? oslo.policy?
16:18:50 lbragstad yeah - oslo.policy
16:19:20 lbragstad since projects will probably see if there before they dig into keystone docs if they're using DocumentedRuleDefault or RuleDefault objects
16:19:56 mriedem yeah
16:19:57 openstack Launchpad bug 1771621 in oslo.policy "Documentation for scope_types doesn't mention what the valid scope types are" [Undecided,New]
16:19:57 mriedem https://bugs.launchpad.net/oslo.policy/+bug/1771621
16:20:29 lbragstad sweet - i can get that fixed today
16:20:44 mriedem so if i set scope_types=['project'] for /usages, that means a system-scope token or a token scoped to the project in the target for the check has access?
16:21:09 mriedem i'm trying to think about admin_or_owner terms here
16:21:22 lbragstad yeah - scope_types handles that mapping
16:21:41 mriedem but that also means the project_id from the query param needs to be in the target to the enforce() call?
16:21:55 lbragstad if you set 'project' as a scope type for a policy, the policy engine will make sure the token used to make that request is project-scoped
16:21:58 mriedem because if i'm using a token from project A and doing GET /usages?project_id=B
16:22:01 mriedem i shouldn't be able to right?
16:22:09 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290
16:22:19 lbragstad correct, that would be a violation of the authorization we have with project role assignments
16:22:35 mriedem ok, because the way i have the check for that right now is it just passes in the user request context,
16:22:54 mriedem so it's going to say, "you have a token for project A and you're checking project A, so sure, lgtm"
16:22:55 mriedem right?
16:23:49 lbragstad yes.. that's what you need, but sometimes it's easier to just ask oslo.policy to check that the token is scoped to the proper entity and leave the context.project_id == query_param.project_id check to the nova code
16:24:04 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053
16:24:05 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300
16:24:08 lbragstad oslo.policy should make sure the token used matches the scope_types and that the check_str passes
16:24:42 mriedem "leave the context.project_id == query_param.project_id check to the nova code"
16:24:46 esberglu mriedem: Added the abstract tags and responded to your other comments ^
16:24:48 mriedem i don't know that we explicitly do that in our apis
16:24:57 lbragstad right... and that's fine
16:25:03 lbragstad because openstack always kinda operated like that
16:25:03 mriedem we probably do enforce that in things like DB APIs that query based on the context
16:25:04 mriedem model_query
16:25:16 mriedem esberglu: thanks
16:25:28 lbragstad ideally, in the future, you might want to consider a layer that does some validation like that
16:25:31 stephenfin mriedem, dansmith: Posted updates to that numa-aware-vswitch spec. Think I might need some input regarding how I'm storing the information for use in the scheduler and resource tracker
16:25:53 lbragstad making sure the resource controlled by nova falls within the authorization context set by the token
16:25:58 mriedem stephenfin: we might want to jump on a hangout for that
16:26:10 mriedem need to understand your work items to know how we should store data and pass it around
16:26:27 stephenfin mriedem, dansmith: It's probably best to look at what I have done and suggest why I shouldn't have done that https://review.openstack.org/#/c/564449/3 https://review.openstack.org/#/c/564452/3
16:26:52 stephenfin mriedem: Yeah, that wouldn't be a bad idea. I can't do this evening though :(
16:27:06 mriedem stephenfin: tomorrow morning after the nova meeting?
16:27:09 mriedem well, evening for you
16:28:01 stephenfin mriedem: dansmith and I have our team meeting then. I can do any time before
16:28:08 dansmith I can't do before
16:28:13 dansmith but could do after-after
16:28:46 mriedem i'm free tomorrow, depends on stephen's hard drop everything and leave the office time :)
16:28:47 stephenfin Heh, and I can't do after-after (tag rugby game to play)
16:28:53 mriedem see!
16:29:11 dansmith we'll all also be in YVR
16:29:20 stephenfin aaaand I'm gone to Vancouver Friday AM
16:29:26 mriedem stephenfin, see, you need to start a family, give up on friends, and confine yourself to your desk
16:29:39 stephenfin dansmith: That would work. Don't imagine it'll take long
16:29:40 mriedem start working on your sweet sweet paunch
16:29:49 mriedem yeah we can punt to YVR...
16:30:38 stephenfin Aye, but if efried_rollin can fit in 8 sessions a week, I should probably try fit in a tag game
16:30:46 stephenfin mriedem: Sweet
16:34:27 mriedem efried_rollin: esberglu: +2 on https://review.openstack.org/#/c/549053/
16:36:41 esberglu mriedem: ack, tx for review
16:36:57 cfriesen stephenfin: tag rugby? that's not as much fun. :)
16:39:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Add granular policy rules for usages https://review.openstack.org/568706
17:00:16 lbragstad mriedem: let me know if this helps https://review.openstack.org/#/c/568901/
17:02:08 lbragstad it's rough - but it might also be beneficial to add in a section on how the service is responsible for checking the scope of the resource in the request against the token being used, and how that differs from the scope_types check

Earlier   Later