13:00:36 #startmeeting image_encryption 13:00:36 Meeting started Mon Aug 19 13:00:36 2024 UTC and is due to finish in 60 minutes. The chair is Luzi. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:36 The meeting name has been set to 'image_encryption' 13:00:46 #topic Roll Call 13:01:16 I'll wait a few minutes for people to show up 13:03:18 ohai 13:03:26 o/ 13:03:26 hi fungi 13:04:03 i wrote a mail to the ml, i hope some people from cinder and glance will also show up 13:05:48 i saw, thanks for the update too 13:08:00 well it seems, we are the only ones 13:08:16 #topic Image Encryption Patches 13:08:41 while i had PTO, mhen thankfully started (and nearly finished) the implementation 13:08:46 rosmaita was around in irc earlier, though not sure if he's been following the glance parts of this effort 13:08:49 https://review.opendev.org/q/topic:%22LUKS-image-encryption%22 13:09:04 er, cinder i meant 13:09:28 thanks mhen! 13:11:04 o/ 13:11:06 hi 13:11:33 hi :) 13:11:46 here is an update: while i was on PTO mhen implemented nearly everything: https://review.opendev.org/q/topic:%22LUKS-image-encryption%22 13:12:18 we discussed one thing, were we have a question for Cinder and Glance: 13:12:49 a transition is needed from the old Glance image metadata naming (cinder_encryption_*) to the new one (os_encrypt_*) 13:13:32 so, how should we proceed with this topic?, because there will be images in the database with the old metadata names 13:15:12 i talked about this a bit with Rajat (who has a holiday today) on friday 13:15:35 oh good 13:15:40 i think you'll need a deprecation period like you outlined in your email 13:16:24 okay, we already identified the places, which we need to adjust. 13:16:27 and you can possibly write an extension to the glance-manage tool that could migrate the metadata keys in the glance database 13:17:35 one thing i'm not sure about is that the cinder_encryption_deletion_policy has been documented for a while 13:18:14 documentation is on my list 13:18:14 so, if someone puts cinder_encryption_key_deletion_policy = no_delete (or whatever the real value is) 13:18:42 and there is also os_encryption_key_deletion_policy == on_deletion already on the image 13:19:18 do we need to worry about that? i.e., should we respect what the person is trying to do? because they won't get an error message 13:19:59 that's the only reason i can think of for honoring the cinder_encryption_* metadata beyond a one or 2 cycle deprecation period 13:20:46 sorry, what i meant about the documentation comment, is that the old name cinder_encryption_... has been documented a while back, and is in the current docs (i think) 13:20:56 It is here: https://docs.openstack.org/glance/latest/user/common-image-properties.html 13:21:08 our patchset will update this page with the new attributes 13:21:20 maybe we should mention the old names in the descriptions? 13:22:17 yes, say something about them being silently ignored 13:23:04 and maybe backport a doc change saying something about the metadata key will no longer be functional starting with the 2025.1 release or something 13:24:08 okay that sounds good 13:24:36 i guess the main issue is whether it is a good user experience to have the os_encryption_* override the cinder_encryption_* if both are present 13:26:28 should we implement some safeguards preventing the creation of images with both or the addition of the other when one is already present? 13:27:18 not sure, we don't want to to get too complicated (which opens an opportunity for bugs) 13:27:35 right 13:27:48 honestly, the cinder encrypted volume workflow was designed so that the end user didn't need to know about this stuff 13:28:01 so i'm not sure that a lot of people are hacking into the workflow 13:28:24 we had to document it in glance since we had one service deleting a resource created by another service 13:29:06 you'd have to know about the hexlify tweak in order to actively use it, which is not documented afaik 13:30:01 yeah, although you could use the barbican secret for something else, and not know about the hexlify 13:31:45 ah you mean consuming the cinder-created secret for something else as a user` 13:31:51 ? 13:32:09 exactly 13:32:33 looking at the cinder docs now to see if we say "do not mess with the cinder_* metadata on images" 13:32:33 is there somewhere documented to not use secrets created by OpenStack for something else, but to create a new one? 13:33:38 or that you should not re-use secrets, e.g. one secret for 2 or 3 images? 13:36:14 i don't see anything 13:36:41 gimme a minute to grep the docs instead of using a web search engine 13:38:09 don't see 'cinder_encrypt' showing up anywhere in the current cinder docs 13:39:00 okay, I will take a look into the docs 13:39:05 i think the idea was that since encrypted volumes were supposed to "just work" for end users, we don't explain the details anywhere (i guess to keep people from getting ideas) 13:40:08 so let me summarize: we add a deprecation period for the old metadata name and adjust the patches accordingly 13:41:07 i will take a look into the glance-manage tool and write an extension to change names in the database 13:42:12 that way we will only have the problem with users creating new images with the old metadata names, so we provide documentation 13:42:21 did i get everything? 13:43:39 i think so ... the upgrade path for operators is: 1. install 2024.2 or later, new resources get os_encrypt* metadata, legacy cinder_encrypt* metadata is still honored for a deprecation period 13:44:00 2. run the glance-manage to update all the legacy encrypt metadata to os_encrypt* 13:44:37 3. at this point, no openstack service will create cinder_encrypt* metadata ... so if you still see some being created, must be by a user 13:44:56 4. reach out to the user and notify them that shortly the cinder_encrypt* will no longer work 13:45:08 yeah 13:45:53 3 & 4 sounds like a pain for operators, but we don't really think so, because it would mean that end users are making use of an undocumented "feature" 13:46:06 so we don't expect that this will happen a lot 13:47:14 then it would be nice to have someone beside us, reviewing and/or testing the patches - to tell us if we missed something important 13:47:18 might be a good idea to run that upgrade path by operators (i think put "[ops]" in the subject) and see if anyone objects 13:48:21 it sounded like some of the operators in the scs community had an interest in these features, maybe they could provide feedback? 13:48:32 ok, i will put reviewing these patches on my to-do list ... feel free to bug me on wednesday if you haven't seen any action 13:48:34 I will ask them too 13:48:40 fungi: ++ 13:48:43 thank you rosmaita 13:48:52 well, don't thank me yet! 13:49:24 :D 13:49:43 okay, does anyone of you have any other questions or concerns? 13:49:51 regarding the image encryption 13:50:14 i did not 13:52:07 i think we're good 13:52:16 okay, thank you for joining this meeting and have a nice week :) 13:52:23 #endmeeting image_encryption