| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 17:43:39 | sean-k-mooney | why so? the format so the image and root disk may not be the same. | |
| 17:44:17 | sean-k-mooney | are you suggesting that we shoudl require the instance to be encypted if the image is | |
| 17:44:52 | dansmith | yes and especially that we should not *decrypt* the image if you boot from it without that requirement | |
| 17:45:15 | sean-k-mooney | so i see that as being in conflict with allowing you to take an unecypted snapshot | |
| 17:45:19 | dansmith | that's kinda like having FDE enabled and dropping it because you upgraded to the next version of your OS and forgot to opt-in again | |
| 17:45:42 | dansmith | why? you're specifically asking to have it de-crypted in that case | |
| 17:45:59 | sean-k-mooney | and you explcitly ask to not encypt the instance in the other | |
| 17:46:05 | sean-k-mooney | well implictly | |
| 17:46:16 | dansmith | very implicitly :) | |
| 17:46:17 | sean-k-mooney | but unless we make it a tristate | |
| 17:46:25 | sean-k-mooney | i think that equivlent | |
| 17:46:58 | dansmith | well, the other option would be to require your hw_ to be set to either match the format of the image, or explicitly request cleartext and we refuse to boot if it's not set to match | |
| 17:47:08 | dansmith | but I think that's just adding an extra hoop for people | |
| 17:47:38 | sean-k-mooney | well i wasd thinking that you might want to upload the image in gpg format to glance | |
| 17:47:47 | sean-k-mooney | but boot form a vm in luks format | |
| 17:47:58 | melwitt | I thought the debate here is whether or not to allow a change in encryption format going from image => root disk. because otherwise afaict hw:ephemeral_encryption (the bool) provides everything else? | |
| 17:48:03 | sean-k-mooney | after all we cant boot form an image in gpg format right | |
| 17:48:11 | dansmith | as I said in my reply, I think this is getting to the point of unnecessary layers that users don't care about (i.e. the distinction between glance and nova and cinder's notion of the encrypted-ness) | |
| 17:49:11 | dansmith | sean-k-mooney: gpg format is useless.. it was added before and only because there wasn't userspace tooling for LUKS | |
| 17:49:22 | dansmith | I think they're mostly using it as an example at this point and I thought they were going to drop that anyway | |
| 17:49:31 | sean-k-mooney | ok but we cant boot form that | |
| 17:49:36 | dansmith | correct | |
| 17:50:08 | sean-k-mooney | we could boot form it if we decypt or convert | |
| 17:50:19 | dansmith | melwitt: one or more of us is implying too much about the format of the image and the intent for booting new instances I guess.. the boolean doesn't really matter, it's the default we assume | |
| 17:51:03 | sean-k-mooney | well the bool is ment to be (should this instance have encypted ephemeral storage) | |
| 17:51:28 | dansmith | my concerns are that (a) we should never implicitly decrypt something and (b) we should not design something that requires us to do a (very expensive) format/encryption conversion for the usual case | |
| 17:51:29 | sean-k-mooney | that is indepenent of if its BFV or boot form image | |
| 17:52:20 | sean-k-mooney | well the only way to avoid the format conversion would be luks iamge and luks encyption for qemu | |
| 17:52:48 | sean-k-mooney | we cant store dmcypt_plain images in glance can we? | |
| 17:52:55 | sean-k-mooney | if we can that woudl also be valid | |
| 17:53:10 | melwitt | I agree we should never implicitly decrypt something | |
| 17:53:26 | sean-k-mooney | cant we boot form encypted iamges today? | |
| 17:53:34 | sean-k-mooney | i tought we always decypted them? | |
| 17:53:46 | dansmith | eh? | |
| 17:53:48 | sean-k-mooney | maybe thats not a thing? | |
| 17:54:13 | melwitt | (don't want any surprises) | |
| 17:54:15 | melwitt | "today" meaning in the proposed patch series? | |
| 17:54:15 | sean-k-mooney | i might be mixing that up with signed images | |
| 17:54:22 | melwitt | in the series there is support for booting from encrypted images | |
| 17:54:28 | melwitt | oh, yeah you might be thinking of signed | |
| 17:54:29 | sean-k-mooney | no today meaning Caracal/master | |
| 17:54:34 | dansmith | that's kinda the whole point right? | |
| 17:54:46 | dansmith | (booting from encrypted images" | |
| 17:55:38 | sean-k-mooney | not entirely. so i tought the gap we were trying to solve is booting vms with encypted local storage | |
| 17:55:52 | sean-k-mooney | irriespective of the encyption state in glance | |
| 17:56:14 | melwitt | I think the main point is booting encrypted from unencrypted but booting from encrypted quickly becomes an expectation bc of snapshotting imho | |
| 17:56:16 | dansmith | what's the point of local storage encryption if snapshots are clear? | |
| 17:56:36 | sean-k-mooney | they wernt clear in the previosu iteration of the spec | |
| 17:56:53 | dansmith | maybe I'm completely off base here, but in a cloud snapshots are like the #2 most important unit of measure behind instances themselves | |
| 17:56:55 | melwitt | because the user might add private data after that (I thought?) | |
| 17:56:59 | dansmith | you need snaps for basically everything in the cloud workflow | |
| 17:57:16 | sean-k-mooney | i dont think that is true | |
| 17:57:28 | melwitt | but like for example my laptop, the OS image was not encrypted but my disk is encrypted | |
| 17:58:11 | sean-k-mooney | * i dont think snapshots is the #2 most imporant thing in a cloud workflow | |
| 17:58:16 | dansmith | melwitt: it's a bit different there because the OS is read-only and your user data is transportable separately from the OS image, whereas we don't really support that | |
| 17:58:27 | melwitt | that's what I think the most common case probably is. but like I said I think if snapshot is a basic feature available in the cloud, I think users would expect to be able to boot from an encrypted snapshot as well | |
| 17:58:29 | dansmith | sean-k-mooney: okay well, we disagree there then | |
| 17:59:25 | sean-k-mooney | melwitt: right but lest take an example | |
| 17:59:45 | sean-k-mooney | i boot a vm form an unencypted ubuntu image with a flavor that enabel instance encyption | |
| 18:00:18 | sean-k-mooney | if we take a snapshot of that then i would expect you to set the hw_ephemeral_encyption image property in the snapshot | |
| 18:00:35 | sean-k-mooney | and the OS_GLACE_* properties to recored the format | |
| 18:01:14 | dansmith | what about cinder? | |
| 18:01:27 | sean-k-mooney | can you elaberate? | |
| 18:01:30 | dansmith | you want them to set that property on an encrypted image they upload just in case someone wants to boot from it? | |
| 18:01:43 | sean-k-mooney | no | |
| 18:01:56 | dansmith | because if they don't you'll decrypt their data when you boot from it if you don't know to go set that intent flag | |
| 18:02:03 | sean-k-mooney | but if we were taking a snapshot of a BFV volume we could | |
| 18:02:07 | melwitt | I think that's where I differ in my thought, I don't think hw_ephemeral_encryption (the boolean) on the snapshot. only the secret uuid (os_glance_encrypt_key_id) which implies it is encrypted | |
| 18:02:27 | sean-k-mooney | it imples the image is | |
| 18:02:39 | sean-k-mooney | but not that only encypted guest can be crated form it | |
| 18:03:06 | melwitt | right | |
| 18:03:24 | sean-k-mooney | weither we set hw_ephemeral_encyption on the snapshot is a design choose we can make | |
| 18:03:53 | sean-k-mooney | but to me hw_ephemeral_encyption is the only thing on an image that says the resulting vm must be booted with encypted local storage | |
| 18:04:01 | dansmith | melwitt: wait, you think that if you snapshot an encrypted instance to an encrypted image and then create another instance from that, it should be de-crypted? | |
| 18:05:17 | melwitt | dansmith: no, I don't.. but somewhere along code review someone commented that I should not assume encrypted if the source is encrypted. originally I did assume encrypted if source encrypted | |
| 18:05:29 | gmann | sean-k-mooney: yes, we can use the "files" (files is correct name of var, not relevent-files ) variable to define the files we want to run the job when they are changed. | |
| 18:05:44 | dansmith | okay, I missed that I guess.. I definitely do not think we should ever decrypt unless specifically asked | |
| 18:06:13 | sean-k-mooney | dansmith: so to me that means we shoudl reject booting form an image with OS_GLACE_* options | |
| 18:06:17 | dansmith | so if we have the hw_ boolean on the image, I think that either we take the default to match the format, or we *require* it be set to something before we agree to use the image (i.e. tell me what you want me to do with this) | |
| 18:06:21 | sean-k-mooney | if the flavor or iamge does not have hw_ephemeral_encyption=True | |
| 18:06:36 | melwitt | ok. I might have misunderstood what the person said. and tbh I need to double check what it's doing at the moment because I don't remember off the top of my head | |
| 18:06:37 | dansmith | sean-k-mooney: we could, but I think we could also punch the users in the face | |
| 18:06:51 | sean-k-mooney | i think the glance feature is currently broken | |
| 18:07:04 | dansmith | there is no glance feature (now or in the future) to be clear | |
| 18:07:05 | sean-k-mooney | becuase to mean the exisitng option are only about the format of the image at rest | |
| 18:07:15 | sean-k-mooney | without condiering the extra requiremns for nova/cinder | |
| 18:07:56 | sean-k-mooney | im confuges but someones at my door brb | |
| 18:08:09 | gmann | sean-k-mooney: and when we have less number of files we want job to run it is better and much readable to define those via "files" var instead of excluding a lot of others via "irrelevant-files" | |
| 18:08:14 | melwitt | I think the comment was about the fetch_to_raw method, I originally made it base the destination format on the source format. i.e. if image is encrypted then created disks should be encrypted | |
| 18:09:04 | dansmith | melwitt: right and that's definitely what I think we should do.. I commented on that method, so I hope I didn't mis-convey that I thought decrypting was the right thing to do | |
| 18:09:22 | dansmith | fetch_to_raw shouldn't really be making that policy decision | |
| 18:10:01 | dansmith | IIRC, that comment was about assuming plain if the source was plain or something, in support of my argument here | |
| 18:10:23 | melwitt | dansmith: I may have misinterpreted. I can see the point that it shouldn't make the decision. I hadn't thought of that. either way I'll go back and fix it if it needs fixing because I'm not 100% sure at the moment | |
| 18:11:02 | melwitt | *make the policy decision | |
| 18:11:04 | dansmith | melwitt: I think my comment was about what happens if you don't pass in explicit requirements to it, but not about what we should do at the high-level as a "policy" | |
| 18:11:11 | dansmith | ack | |
| 18:11:19 | melwitt | gotcha | |
| 18:11:29 | sean-k-mooney | gmann: ya so the issue is we currently use a negitive regex and zuul has change the regex lib they use and that is not supproted | |
| 18:11:51 | sean-k-mooney | gmann: so we will need to remove all our usages of negitive regex regardlels of which is shorter | |
| 18:12:31 | sean-k-mooney | melwitt: dansmith would it help to hop on a meet call?. | |