| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-16 | |||
| 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 | efried: this? # NOTE(markmc): this is imported before monkey patching in nova.cmd | |
| 16:08:28 | mriedem | # so we avoid extra imports here | |
| 16:08:40 | mriedem | efried: that's talking about eventlet monkey patching | |
| 16:08:40 | efried | mriedem: Yes. Wasn't sure if that referred to the same monkey patching you're axing. | |
| 16:08:44 | efried | okay, cool. | |
| 16:08:44 | mriedem | not "hack features into nova" | |
| 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 | mriedem | https://bugs.launchpad.net/oslo.policy/+bug/1771621 | |
| 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: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 | mriedem | we probably do enforce that in things like DB APIs that query based on the context | |
| 16:25:03 | lbragstad | because openstack always kinda operated like that | |
| 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! | |