| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-27 | |||
| 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 | |
| 17:23:25 | sean-k-mooney | either domain has no menaing or it does | |
| 17:23:46 | gmann | actually 5. we do not have system member | |
| 17:23:55 | gmann | i counted the combination also | |
| 17:24:05 | sean-k-mooney | ideally nova itself woudl be runnign as system member but ok | |
| 17:24:33 | gmann | dansmith: and having mapping in DB? | |
| 17:24:52 | dansmith | gmann: no, no mapping. we'd have to map every project and every host | |
| 17:25:21 | sean-k-mooney | gmann: dansmith is suggesting just using the current uuid | |
| 17:25:32 | sean-k-mooney | which i think is an ok comprmise | |
| 17:25:35 | dansmith | gmann: using the uuid lets us look up t he host in O(1), which is what we want. It exposes a 1:1 identifier that the project admin can use, but without any details that are often embedded in hostnames | |
| 17:25:50 | sean-k-mooney | its slightly better then the hostname for the reason he gave above | |
| 17:26:03 | sean-k-mooney | but still allows effiecnt scheduling | |
| 17:26:25 | gmann | and with uuid non-admn or project admin cannot get host detail so make sense | |
| 17:26:34 | dansmith | right | |
| 17:26:48 | gmann | got it | |
| 17:26:59 | sean-k-mooney | ya we would reject a /hypervior/detail request with a project admin token | |