| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 20:11:25 | mriedem | there is a spec proposed to remove peronality files from server create and rebuild | |
| 20:11:47 | cfriesen | jaypipes: thanks for the suggestions on https://review.openstack.org/#/c/46820 (proposing "hw:realtime_cpu_set"). I imagine we'd need to support both "set" and "mask" for a release or two? | |
| 20:11:52 | mriedem | the question came up if we should allow passing new user_data during rebuild if we're not going to allow passing personality files anymore, and the spec currently states that we will not allow that | |
| 20:12:03 | penick | Yeah, my concern was if I can rebuild your instance, and that rebuild pulls in your user ssh keys, and If I can do something to inject my user into your instance on rebuild then i'd gain access to your ssh keys. | |
| 20:12:29 | melwitt | penick: if two ppl are in the same project and one person A creates an instance with their --key_name in it and the second person B does a rebuild on person A's instance, what happens to the key | |
| 20:12:42 | cfriesen | penick: resources are owned by projects, not individual users | |
| 20:12:50 | mriedem | cfriesen: except keys | |
| 20:13:16 | mriedem | penick: i think your question belongs in https://review.openstack.org/#/c/375221/ | |
| 20:13:32 | cfriesen | penick: mriedem: logically though any keys should belong to the project, not the individual user | |
| 20:13:32 | mriedem | in the security impact section | |
| 20:14:04 | mriedem | i think what would happen here is if you specified a new key_name during rebuild, we are going to be looking up that keypair in the api to see if it exists, | |
| 20:14:11 | mriedem | that check is going to use the context.user_id, | |
| 20:14:32 | mriedem | and if you're rebuilding my server, and don't have access to my keys, that keypair lookup will fail and you'll get an error | |
| 20:14:54 | mriedem | now if user A and user B are in the same project, and both have a key named mykey, that could work, but the user A mykey and user B mykey should still be different | |
| 20:15:00 | penick | melwitt: yeah that's what i'm wondering | |
| 20:15:51 | cfriesen | mriedem: why did we ever tie keys to users? | |
| 20:16:39 | mriedem | you will have to ask someone else | |
| 20:16:48 | mriedem | but, why wouldn't we? | |
| 20:16:50 | mriedem | keys are private | |
| 20:16:55 | melwitt | probably bc when you create one via the API it gives you the private key | |
| 20:16:55 | penick | cfriesen: it makes sense for user ssh keys. Just not for headless keys or server keys | |
| 20:17:20 | mriedem | are we venturing into the application credentials hullabaloo? | |
| 20:17:20 | cfriesen | mriedem: instances are owned by the project. keys are used to access instances. therefore keys should be owned by the project | |
| 20:17:31 | sdague | it is only the public keys that we store | |
| 20:17:39 | sdague | so it's not really a security risk | |
| 20:17:47 | sdague | but it's funny that you can't list those keys for other users | |
| 20:18:01 | sdague | but they can be put on a server for you | |
| 20:18:04 | cfriesen | melwitt: sure, then you dump the private key into some local "project team storage area" with permission controls | |
| 20:18:44 | dansmith | does this matter at all? we'd have to do some pretty major surgery to change the ownership of keys, and it would be hard to support old microversions for them | |
| 20:18:48 | sdague | cfriesen: keys attached to users are from "the before time" | |
| 20:19:35 | dansmith | unless we're really going to change key ownership, we might as well talk about problems we're going to solve | |
| 20:20:21 | sdague | dansmith: yeh, it's just an interesting edge question about how the system works because of the scope mismatch | |
| 20:20:40 | dansmith | sure, | |
| 20:20:52 | dansmith | but then we can move on once identified right? :) | |
| 20:21:02 | sdague | anyway, I tried to build a summary email from all the conversations I saw today | |
| 20:21:03 | cfriesen | dansmith: fair enough...so in mriedem's scenario would we allow user B to replace user A's "mykey" with user B's "mykey" on a rebuild? | |
| 20:21:30 | dansmith | IMHO, if you specify a key, it's looked up based on your context, and if that's your key instead of the original one, then so be it | |
| 20:21:50 | sdague | dansmith: sure, I just think it might be an unexpected thing | |
| 20:21:53 | dansmith | if you don't, then we should keep the same I think | |
| 20:22:14 | dansmith | sdague: if you specify a key? you can't list other people's keys so what other intent could the user have if they specify one? | |
| 20:22:30 | penick | Well for preserving the host key, the private key will need to be stored as well | |
| 20:22:38 | sdague | penick: we don't do that | |
| 20:22:41 | penick | there's no point in keeping a public ssh host key, if you don't preserve the private key | |
| 20:22:43 | dansmith | penick: we do nothing with the host key | |
| 20:22:55 | penick | Oh hell, I completely misunderstood this spec. | |
| 20:22:55 | dansmith | these are all user access keys we're talking about | |
| 20:22:58 | sdague | this is all just the root ssh key | |
| 20:23:02 | sdague | root user | |
| 20:23:09 | dansmith | not even root, | |
| 20:23:14 | sdague | being configed on cloud init | |
| 20:23:17 | dansmith | whatever user the image has for access | |
| 20:23:22 | sdague | dansmith: yeh, right | |
| 20:24:35 | mriedem | cfriesen: ok, so i think what would probably need to happen for rebuild, is if another user does the rebuild, then we have to lookup the keypair by the instance.user_id, | |
| 20:24:38 | mriedem | not the context.user_id | |
| 20:24:56 | dansmith | and doesn't specify a key.. agreed | |
| 20:25:12 | dansmith | we just have to be careful not to expose non-project-user keys when we're doing that override, | |
| 20:25:17 | dansmith | since it happens deep in the db layer I think | |
| 20:25:28 | sdague | yeh, I just wonder what happens in the current code | |
| 20:25:34 | dansmith | sdague: we fail I think | |
| 20:25:46 | penick | ahhh ok. So not a security issue then. Usually people want to preserve the ssh host key between reimages. I do think this is an operability issue if keys stay scoped to only a user, instead of a tenant. | |
| 20:25:48 | mriedem | you can't specify a new key on rebuild today, so i'm lost as to what the concerns are about the current code | |
| 20:26:12 | dansmith | I thought we break if another user tries to rebuild today, no? | |
| 20:26:22 | sdague | dansmith: I don't know if we do, that was the question | |
| 20:26:35 | sdague | rebuild is an instance operation that's project scoped | |
| 20:26:43 | sdague | and keys are user scoped | |
| 20:27:20 | sdague | and I actually haven't checked if B rebuilds a server that A built with A's key if it: a) still has that key, b) has no key, c) errors out | |
| 20:27:53 | sdague | I'll do some testing around that in the morning, my end of day is now | |
| 20:28:06 | dansmith | sdague: right, I thought it was an oopsie on our part that other users couldn't rebuild successfully | |
| 20:28:09 | mriedem | on a rebuild today, we'll use the original key associated with the instance when it was created | |
| 20:28:20 | mriedem | regardless of who rebuilds the isntance | |
| 20:28:24 | dansmith | people want a key during rebuild for taking ownership I think, but that's a destructive operation and not a good argument, IMHO | |
| 20:28:25 | sdague | mriedem: ok, cool | |
| 20:28:52 | dansmith | mriedem: okay, i thought there was a whole big stink about us not being able to look up the key again on rebuild if triggered by another user | |
| 20:29:10 | sdague | dansmith: no, it was a question because of the scoping difference. | |
| 20:29:38 | mriedem | as far as i know, TODAY, we don't ever look up the key during rebuild, | |
| 20:29:48 | mriedem | because you can't change it | |
| 20:29:54 | dansmith | okay | |
| 20:30:17 | mriedem | the only thing i think that happens today, | |
| 20:30:21 | sdague | mriedem: well, it has to be looked up to go in the config drive, right? | |
| 20:30:32 | mriedem | is when driver.spawn happens, we rebuild config drive, and that's going to call the InstanceMetadata code to get the keypair | |
| 20:30:36 | mriedem | to shove into the config drive | |
| 20:30:41 | mriedem | sdague: yes | |
| 20:31:00 | mriedem | and that is the keypair that's stashed in the instance | |
| 20:31:01 | mriedem | just like a flavor | |
| 20:31:03 | dansmith | but we store that on the instance | |
| 20:31:04 | dansmith | right | |
| 20:31:13 | sdague | we store keypair name | |
| 20:31:13 | dansmith | maybe this was broken before and now isn't | |
| 20:31:18 | dansmith | sdague: no we store the whole thing | |
| 20:31:20 | mriedem | we store the whole gd thing | |
| 20:31:25 | sdague | oh | |
| 20:31:25 | dansmith | sdague: keypairs live in the api db and compute can't get them | |
| 20:31:35 | mriedem | https://github.com/openstack/nova/blob/cfff910b0d1a0d9f24b6c1596ceef8dd6b8b3ac6/nova/api/metadata/base.py#L355 | |
| 20:31:46 | sdague | ok, so yeh, maybe cells v2 did move this around and fix a thing | |
| 20:32:24 | dansmith | um, ya'll'er welcome? | |
| 20:32:52 | sdague | dansmith: so, the use case that people seem to want is because keeping IP and device model (mac address) is useful to folks | |
| 20:33:13 | dansmith | but changing ownership via key, yeah | |
| 20:33:14 | mriedem | you also keep your volumes attached | |
| 20:33:23 | sdague | mriedem: right | |
| 20:33:29 | dansmith | I get why people want that | |