| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-24 | |||
| 19:22:24 | efried | Are you the only one who has ever wanted to work with encrypted images? | |
| 19:22:53 | efried | Is the image encrypted in glance, and then you want to decrypt it while/after you copy it to the instance's boot disk? | |
| 19:23:18 | karimull | may be :) | |
| 19:23:52 | karimull | efried : exactly | |
| 19:23:53 | efried | I guess what I'm getting at is, either what you're doing is wild and crazy and you shouldn't be doing it - upstream or down - or it's something that more people want to do and is either already supported or should be proposed formally upstream. | |
| 19:24:26 | efried | Me, I don't know anything about it, I'm afraid. | |
| 19:25:13 | efried | seems weird that you're maintaining the image encrypted in glance, but want it decrypted *before* you boot the instance. | |
| 19:25:24 | efried | It's as if you trust glance less than you trust instances | |
| 19:25:40 | karimull | efried :I could see volume encryption blue but nothing on image | |
| 19:28:51 | karimull | efried : I'm making sure if this is feasible before proposing a formal blue print | |
| 19:29:14 | efried | karimull: Okay, so you do intend to propose it upstream? | |
| 19:29:41 | karimull | efried : yes | |
| 19:29:51 | efried | I see. Have you talked to the glance folks about it? | |
| 19:30:50 | karimull | efried : not yet | |
| 19:31:19 | melwitt | we added support for trusted image certificate validation in rocky https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/nova-validate-certificates.html | |
| 19:31:45 | dansmith | presumably they want encryption | |
| 19:31:49 | dansmith | but that came before, AFAIK | |
| 19:32:01 | melwitt | but I don't know of any support for encrypted images in glance | |
| 19:32:34 | melwitt | yeah, was just mentioning it in case it might be useful | |
| 19:33:12 | melwitt | that's the extent of the handling of "untrusted glance" that I know about | |
| 19:33:16 | dansmith | oh I thought the encryption support was already there | |
| 19:33:36 | dansmith | maybe I'm thinking of encrypted block | |
| 19:34:46 | melwitt | I'm not sure, it might be there. trying to find out. an earlier iteration of the trusted certs stuff mentioned image encryption | |
| 19:35:02 | dansmith | yeah | |
| 19:35:24 | dansmith | looks like just signatures though in the tree | |
| 19:35:26 | efried | assuming the decrypt would happen chunk-wise, it's not in the nova glance code. | |
| 19:35:26 | karimull | I have not seen any support for encrypted image in glance.. | |
| 19:36:15 | karimull | wanted to support user defined encryption of image at nova compute for more flexibility | |
| 19:36:44 | efried | karimull: Point is, assuming it's not already there, you would likely be looking to make your changes in a lot of the same places as the bp melwitt mentioned ( https://review.openstack.org/#/q/topic:bp/nova-validate-certificates+(status:open+OR+status:merged) ) | |
| 19:39:12 | karimull | by using Castellan which support key manager interface and by having a plugin in nova to perform user defined decryption process it will be more transparent..just a thought still framing on all possibilities | |
| 19:39:53 | karimull | efried: will look into that blueprint.. | |
| 19:39:58 | melwitt | karimull: are you thinking this would be transparent to glance? like you would encrypt the image before uploading to glance using your nova keypair, for example, and then you'd like nova to decrypt it? we would need the private key for that though and we don't store them | |
| 19:40:16 | karimull | yes | |
| 19:40:47 | dansmith | that's where castellan or barbican comes in | |
| 19:41:04 | dansmith | nova gets a key the user provides there to decrypt | |
| 19:41:25 | melwitt | right.. ok | |
| 19:41:34 | dansmith | AFAIK, glance needs to look at the image when you upload it so it's not like you can do this without glance at all I think | |
| 19:41:43 | dansmith | unless there is some way to tell glance not to look at the image, but I'm not sure | |
| 19:42:17 | karimull | user will get the key from either barbican or from their own KMS and encrypt and upload the image with information in meta data , using that information and castellan libraries key will be retrieved for decryption of image | |
| 19:42:21 | dansmith | unless you care about hiding the boot content from everything other than nova, this is pretty easy to do internal to the image without a lot of fanfare | |
| 19:43:22 | dansmith | also, you'd probably want to make sure we don't cache the decrypted image, especially if the cache is on shared storage | |
| 19:43:27 | dansmith | gets out of hand pretty quick :) | |
| 19:43:44 | karimull | ok | |
| 19:46:29 | karimull | dansmith: wanted to decrypt the image at compute host before it is launched..is this possible?..if we can have hooks at libvirt or nova-compute level wanted to make it a plugin | |
| 19:46:43 | dansmith | karimull: we don't have plugins | |
| 19:47:02 | dansmith | we have some aging hooks that are slowly being removed from the code | |
| 19:47:35 | dansmith | but obviously doing the decryption on the compute host is where it would need to happen | |
| 19:49:28 | karimull | having a plugin kind of functionality will give user flexibility to use their own decryption process..hence look in that way..do we have any similar way to do it in Nova | |
| 19:50:00 | karimull | dansmith : looking* | |
| 19:50:24 | dansmith | we don't have plugins | |
| 19:55:39 | dansmith | mriedem: jaypipes: what's the fix for this? https://bugs.launchpad.net/nova/+bug/1793747 | |
| 19:55:40 | openstack | Launchpad bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] - Assigned to Neha Alhat (nehaalhat) | |
| 19:58:26 | dansmith | I don't even think I get what the problem is | |
| 19:59:14 | openstackgerrit | Merged openstack/nova stable/ocata: Cleanup RP and HM records while deleting a compute service. https://review.openstack.org/603749 | |
| 19:59:20 | dansmith | oh, I see, I was looking at the wrong thing.. we're lower()ing all the hostnames | |
| 20:02:12 | dansmith | s10: okay I got all those backports you tagged me on | |
| 20:04:08 | s10 | dansmith: thank you, finally we will get this fixes in queens after two month of waiting :) | |
| 20:04:27 | dansmith | s10: we just got a queens release this morning though right? | |
| 20:04:35 | dansmith | might already be time to queue up another one :) | |
| 20:06:43 | mriedem | and we just released that blazar regression https://review.openstack.org/#/c/585334/ | |
| 20:07:04 | jaypipes | dansmith: the fix for this is not having such fragile friggin code? :( | |
| 20:07:04 | mriedem | dansmith: i don't know what the fix is for that bug | |
| 20:07:16 | jaypipes | fix one thing, breaks another. :( | |
| 20:07:23 | dansmith | jaypipes: yeah we should totes just depend on our backend database ignoring case for us :) | |
| 20:07:41 | dansmith | mriedem: we could try to lower() the hostname everywhere else, but I kinda think the original "fix" was broken | |
| 20:08:01 | jaypipes | dansmith: the user expects a case-insensitive search. | |
| 20:08:02 | dansmith | if they pass a hostname that is different from what the machine reports, they should expect it to not work | |
| 20:08:32 | dansmith | jaypipes: I don't | |
| 20:08:42 | dansmith | the aggregate code must not be validating hostnames when you go to add one right? | |
| 20:09:03 | dansmith | in which case maybe the fix is just to make host-add fail if you specify something wrong? | |
| 20:09:04 | jaypipes | dansmith: this isn't about that. this is about the collection of host aggregate states in the scheduler (in Python, not in the DB) | |
| 20:09:27 | jaypipes | and Python is case-sensitive, as we know. | |
| 20:09:27 | dansmith | jaypipes: the original | |
| 20:09:44 | dansmith | fix and the new regression are all about us allowing you to add a host with a non-matching case, | |
| 20:09:58 | dansmith | and then us not also ignoring case when we go to join it up right? | |
| 20:10:20 | dansmith | if we just refuse to let them add non-matching hostnames in the first place, everything else can be consistent right? | |
| 20:10:22 | jaypipes | I need to look (again) at the code. it's a giant ball of turds. | |
| 20:11:02 | jaypipes | dansmith: I don't think this is about them adding non-case-matching hostnames. | |
| 20:11:06 | dansmith | I don't expect to have case ignored. what I do expect is for nova to tell me "that's, like, not a host maan" when I go to add one to an aggregate | |
| 20:11:11 | mriedem | non-matching by looking up the host from the compute_nodes table? | |
| 20:11:31 | dansmith | jaypipes: it is.. the original fix says "accidentally typed COMPUTE0 instead of compute0" | |
| 20:11:52 | openstack | bug 1793747 in OpenStack Compute (nova) "Fails to boot instance using Blazar flavor if compute host names are in uppercase" [High,Triaged] https://launchpad.net/bugs/1793747 - Assigned to Neha Alhat (nehaalhat) | |
| 20:11:52 | jaypipes | dansmith: no, I'm talking about the bug 1793747 | |
| 20:11:58 | dansmith | jaypipes: and the regression is that blazar is taking the mixed-case hostname from the hypervisors api, and using that to add the host to an aggregate | |
| 20:12:04 | jaypipes | dansmith: there's no indication that that bug reporter has used non-matching hostname... | |
| 20:12:05 | dansmith | jaypipes: they're the same thing | |
| 20:12:27 | dansmith | jaypipes: blazar is looking at hypervisors and using that value.. | |
| 20:12:39 | dansmith | blazar host-create Openstack-VirtualBox | |
| 20:12:39 | mriedem | fwiw, bug 1709260 wouldn't be possible by default if they were using postgresql :P | |
| 20:12:40 | openstack | bug 1709260 in OpenStack Compute (nova) queens "Addition of host to host-aggregate should be case -sensitive" [Low,Fix committed] https://launchpad.net/bugs/1709260 - Assigned to Rajesh Tailor (ratailor) | |
| 20:12:55 | jaypipes | dansmith: that's the correct hostname. | |
| 20:13:05 | dansmith | jaypipes: right exactrly | |
| 20:13:12 | dansmith | jaypipes: but we're mangling it internally by lower()ing it | |
| 20:13:16 | dansmith | and they can't see that | |
| 20:13:46 | jaypipes | dansmith: where are we mangling it internally other than the host manager's host aggregate state internal map? | |
| 20:13:58 | dansmith | exactly there | |
| 20:14:03 | dansmith | that's the problem right? | |
| 20:14:12 | jaypipes | dansmith: and how exactly would PG vs. MySQL "solve" this problem? | |
| 20:14:19 | dansmith | jaypipes: mriedem said that not me | |
| 20:14:25 | dansmith | I don't think it would | |