| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-27 | |||
| 16:48:42 | gmann | k | |
| 16:49:14 | gmann | gibi: stephenfin I replied to this comment if I understand it correctly. can you check this - https://review.opendev.org/c/openstack/nova-specs/+/793011/2/specs/xena/approved/allow-project-admin-list-hypervisors.rst#81 | |
| 16:52:49 | dansmith | gmann: replied | |
| 17:01:31 | melwitt | gmann, dansmith: I skimmed over that spec on tuesday and was thinking, it depends on how you're defining project-admin. if you're defining it as system-admin scoped down to only a project, then showing the hostnames makes sense. if it's not that, then the obfuscated names make sense. I'm curious what lbragstad would say was the intended meaning/use | |
| 17:02:17 | dansmith | melwitt: yeah, I thought it was more the latter (obviously). I'm not sure what the point of the former is in most cases | |
| 17:02:48 | dansmith | I thought the problem was that they wanted some people to be able to violate scheduling restraints and bust locks and reset instance state, but not muck with aggregates and system-level stuff | |
| 17:03:21 | melwitt | yeah, I'm not sure. I haven't acquired a solid understanding of what project-admin is supposed to be, from a secure rbac design perspective | |
| 17:04:35 | dansmith | I think if you take the public cloud case, we need to know if project-admin is supposed to be a low-level sysadmin on the cloud side, or a high-level power user on the customer side | |
| 17:04:41 | dansmith | I have been assuming the latter | |
| 17:05:22 | dansmith | I guess the former could be some customer-dedicated support person, but I would expect those cases to be pretty uncommon | |
| 17:07:13 | melwitt | yeah. one of the use cases that comes to mind first for me (bc a customer wanted this) was a role where some people could do live migrations but not be admin (live the global admin we have today) | |
| 17:07:31 | melwitt | *like the global admin | |
| 17:07:34 | dansmith | yeah exactly | |
| 17:07:51 | dansmith | that might be a role and not all-of-admin I would think, | |
| 17:08:07 | melwitt | so then you will ask, can that live migration person force to a specific host? | |
| 17:08:08 | dansmith | but I would guess you mostly want those people migrating to hosts symbolically and not having to know the hostname | |
| 17:08:48 | melwitt | I know this is whack but I was just thinking I wonder if it would be legit to use obfuscated host for target host | |
| 17:09:22 | dansmith | I don't think it is today, but I think that if we want to delegate live migration to a non-system-admin, that'd be the goal: let them use the obfuscated host | |
| 17:09:46 | melwitt | yeah I doubt it's possible today but I wonder if it would be legit to add it for this project-admin use case | |
| 17:09:51 | sean-k-mooney | melwitt: the issue with using the hashed host is reversing it | |
| 17:09:52 | dansmith | but, as noted in my follow up a few minutes ago, I think host uuid would be a good compromise.. not project-scoped like the hostid, but otherwise opaque | |
| 17:10:02 | dansmith | sean-k-mooney: right, hence using the uuid | |
| 17:10:11 | melwitt | ah yeah, that's even better | |
| 17:10:36 | dansmith | so assume project admins can be trusted with non-project-scoped host identifiers, but without needing to expose actual dns names to them | |
| 17:10:43 | sean-k-mooney | host uuid hum | |
| 17:11:07 | dansmith | they would be able to correlate their hostids to uuids, which regular users can't do, and that would let them collude with other project admins to determine *some* details, | |
| 17:11:07 | sean-k-mooney | is that any safer tehn hostname | |
| 17:11:14 | sean-k-mooney | marginally perhaps | |
| 17:11:31 | dansmith | sean-k-mooney: hostnames contain machine model numbers, deployment dates, network and topology details, etc | |
| 17:11:42 | sean-k-mooney | ya they can | |
| 17:11:55 | dansmith | host123-dl360g1-legacy.old-building.example.com | |
| 17:12:04 | sean-k-mooney | i was more thinink about targeting a host form a different project | |
| 17:12:18 | sean-k-mooney | to land something on the same host intionally | |
| 17:12:34 | dansmith | right, like I said, there's some possibility for collusion between project admins, | |
| 17:12:45 | dansmith | but only to co-locate a thing, not to know infra details | |
| 17:13:00 | dansmith | and if you're granting the user the ability to target hosts, then you're kinda opening that up a bit anyway | |
| 17:13:10 | dansmith | you could do it covertly withou the uuid by measuring latency or something | |
| 17:13:10 | sean-k-mooney | what about using a semtric key instad of a hash for the host id | |
| 17:13:24 | sean-k-mooney | well rather a reversable key | |
| 17:13:32 | dansmith | sean-k-mooney: how is that better? it's reversible, but we still have to calculate it on every query | |
| 17:13:35 | sean-k-mooney | it can be asmetic | |
| 17:13:49 | sean-k-mooney | we will just have to decyprt it | |
| 17:13:51 | dansmith | we could just hash all the things in their aggregate as quick as reversing | |
| 17:14:15 | gmann | do not we return host name in GET /servers today? | |
| 17:14:15 | sean-k-mooney | we could yes | |
| 17:14:16 | dansmith | I bet md5 or whatever we use is fast enough to just do it forwards for every host in their aggregate if we're going to go to that trouble | |
| 17:14:33 | gmann | hostID is obfuscated | |
| 17:14:34 | dansmith | gmann: no, we return a project-scoped hash of the hostname for non-admins | |
| 17:14:36 | melwitt | gmann: we don't unless you're admin admin | |
| 17:14:46 | gmann | yeah i mean for admin | |
| 17:14:51 | gmann | project admin i mean | |
| 17:14:53 | dansmith | gmann: but that's system admin | |
| 17:14:55 | dansmith | right now | |
| 17:14:58 | sean-k-mooney | gmann: host id is a hach of the host uuid and the porject id | |
| 17:15:12 | melwitt | yeah, I would agree the admin of today is a system admin, they can do literally everything | |
| 17:15:39 | melwitt | go across projects and all that | |
| 17:16:18 | sean-k-mooney | dansmith: are you realisticaly think of adding a project-host mapping table in the nova-api | |
| 17:16:26 | gmann | ah right, i thought it is SYSTEM+ Project scoped https://github.com/openstack/nova/blob/master/nova/policies/extended_server_attributes.py#L27 | |
| 17:16:29 | dansmith | melwitt: and administer the system at things like the aggregate level | |
| 17:16:36 | dansmith | sean-k-mooney: no | |
| 17:16:45 | sean-k-mooney | just using the uuid un hased | |
| 17:16:51 | sean-k-mooney | *hashed | |
| 17:17:06 | dansmith | yeah, I think that's a reasonable compromise | |
| 17:17:30 | sean-k-mooney | how would they discover it? | |
| 17:17:31 | dansmith | if not, then I think we have to calculate the hash on the fly when we're using a obfuscated directed boot | |
| 17:17:35 | melwitt | gmann: yeah that's what I was saying earlier is the root question that would guide what to do here. I do note though that if it were SYSTEM + limited to a project, the hostnames wouldn't be any better than the host uuids right? since you're silo'ed within a project | |
| 17:17:49 | dansmith | sean-k-mooney: they can see it in the hypervisors list, that's what the spec is proposing.. to expose that in part to project admins | |
| 17:18:10 | sean-k-mooney | right i was wondering if we were going to keep that | |
| 17:18:16 | gmann | melwitt: i see | |
| 17:18:22 | dansmith | sean-k-mooney: and I'm saying we should do that, but not expose the hostname, and then make the requested_destination take either | |
| 17:18:24 | sean-k-mooney | so we would be retrunign only a subset of the columns to them | |
| 17:18:36 | dansmith | sean-k-mooney: as we do for server detail | |
| 17:18:55 | sean-k-mooney | ok i think that can work | |
| 17:19:00 | melwitt | gmann: like I mean, if you're not allowed to migrate a server across a project boundary, I'm not sure what additional the real hostname gets you. or rather do you "need" to know it | |
| 17:19:03 | sean-k-mooney | is the uuid the only feild we should show them | |
| 17:19:14 | sean-k-mooney | im not sure they need to see uptrime ectra | |
| 17:19:17 | dansmith | sean-k-mooney: s/show/hide/ you mean? | |
| 17:19:43 | dansmith | sean-k-mooney: they need most of what hypervisors show them in terms of used/free memory to make a decision I think, but yeah we could hide more in there | |
| 17:19:58 | dansmith | sean-k-mooney: you should go review the spec :) | |
| 17:20:08 | gmann | dansmith: sean-k-mooney we can show with 'None or 'Unknown' value and keep response field consistent | |
| 17:20:17 | sean-k-mooney | its on my list but i was also going to finish up soon | |
| 17:20:36 | dansmith | gmann: unknown isn't right, but maybe "<hidden>" or something | |
| 17:20:39 | sean-k-mooney | gmann: am i would prefer to not have the filed there | |
| 17:20:41 | gmann | melwitt: yeah but for booting server we need real name | |
| 17:20:53 | dansmith | sean-k-mooney: agree, I'd rather just exclude that field | |
| 17:20:54 | gmann | yeah <hidden> work | |
| 17:21:09 | dansmith | gmann: we would need to make it take hostname or host-uuid | |
| 17:21:14 | melwitt | gmann: today you do but we're talking about adding the ability to use the uuid | |
| 17:21:25 | gmann | sean-k-mooney: but we return those field for system admin and not for project admin is difficult way to read it | |
| 17:21:41 | sean-k-mooney | i dont think thats hard | |
| 17:21:44 | gmann | melwitt: dansmith yeah i get the point of uuid | |
| 17:21:48 | sean-k-mooney | we now have 9 personas | |
| 17:21:51 | sean-k-mooney | instead of 2 | |
| 17:21:52 | gmann | and obfuscated uuid right | |
| 17:22:09 | dansmith | gmann: no, can't be obfuscated | |
| 17:22:17 | sean-k-mooney | so we should expect that for some api system admin will see more then project admin | |
| 17:22:18 | dansmith | gmann: it's opaque, but not scoped or obfuscated further | |
| 17:22:20 | gmann | sean-k-mooney: 7 for nova | |
| 17:23:02 | sean-k-mooney | 7? | |
| 17:23:13 | sean-k-mooney | i was expecting 6 or 9 | |