Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-16
16:00:31 lbragstad ah
16:00:58 efried mriedem: oh, the abstract business, okay. Yeah, I understand, and yeah, abc is kind of a retrofit in python, not really any different behavior-wise from raising NotImplementedError. But we can probably clean that up if it's a thing for you.
16:01:04 lbragstad ok - i always thought that project_id was safe to assume in all cases (since pretty much everything requires a project scoped token today)
16:02:09 mriedem yes we always pass project_id,
16:02:10 gibi melwitt: I cannot make it to the tomorrow's nova team meeting so I cannot chair it.
16:02:26 mriedem and during scheduling we always pass user_id too, i just knew we had something different about how nova does that https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L842
16:02:31 melwitt gibi: k, np. thanks for the heads up
16:03:02 mriedem lbragstad: yeah so allocations will have project_id and user_id, and /usages response is built based on the allocations data i believe
16:03:30 lbragstad mriedem: so - based on the fact that project_id is always required when calling list-usages, i think it's safe to say that is a project-specific API
16:03:34 lbragstad (not sure if that was your question)
16:03:49 lbragstad but i would set scope_types on that to be project specific
16:04:46 lbragstad so - that's interesting thoguh
16:05:00 lbragstad if a system administrator wants to set the usage of a project, should they be able to?
16:05:15 lbragstad a project administrator should be able to set the usage of _their_ project
16:05:36 lbragstad so, in the second case, you'd need to make sure context.project_id and query_param.project_id match
16:06:00 lbragstad otherwise, if you just base things on the role assignment, you might open yourself up to allowing them to set usage for projects they have no authorization on
16:06:11 openstackgerrit Vladyslav Drok proposed openstack/nova master: Placement: allow to set reserved value equal to total for inventory https://review.openstack.org/564838
16:06:20 lbragstad the check for system administrators is a bit more loose
16:06:45 efried mriedem: Do you need to remove the comment at the top of nova/debugger.py?
16:07:13 lbragstad if context.system_scope and context.role == policy.check_str then update the usage with the project id in the query parameter
16:07:23 mriedem lbragstad: the usages stuff is all read-only, like a view table kind of, but yeah admins could change usage by modifying allocations for a given project/user
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?

Earlier   Later