13:00:32 #startmeeting image_encryption 13:00:33 Meeting started Mon Dec 2 13:00:32 2019 UTC and is due to finish in 60 minutes. The chair is Luzi. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:36 The meeting name has been set to 'image_encryption' 13:00:41 #topic Roll Call 13:00:46 welcome back, Luzi! 13:00:59 hi and thank you fungi 13:01:33 o/ 13:02:01 o/ 13:02:31 lets wait a few more minutes for other people 13:05:16 it seems no one else wants to show up 13:05:19 #topic Barbican Consumer API Update 13:05:35 redrobot, are there news from the Barbican side? 13:06:23 Mornin' ... no news on our end that I can think of. 13:06:54 okay thank you :) 13:07:13 #topic Image Encryption Specs 13:08:11 i started updating the glance spec according to the conclusions from the ptg 13:11:27 last week it came up that the nova team wants to hold off implementing local image encryption support until they have working luks support for ephemeral disks 13:11:37 i was curious to understand the reasons behind that, so followed up with some nova reviewers in #openstack-nova on it 13:11:46 this is because nova's local storage for instances uses the ephemeral disk mechanism to boot the image, and to be able to boot an encrypted image natively qemu only supports luks, not the pgp encryption previously implemented for nova's ephemeral disks 13:12:46 so without that prerequisite, images would end up decrypted onto the host's filesystem, eliminating the benefit of encrypting them elsewhere 13:13:38 given their objection, i agree focusing on the boot-from-volume case is reasonable for now, because nova can hand off luks-encrypted cinder volumes to qemu just fine 13:14:53 fungi, I believe this only applies when you use 'use_cow_images' flag in Nova config 13:15:42 i think its difficult because we are talking about images and mean images at different stages or so (hard to say in english without knowing a proper word)) 13:16:01 however, lacking copy-on-write support means a substantial amount of additional disk used on the host, so i can see why they wouldn't want to give up cow 13:17:39 fungi, as far as i know from mdbooth that still would be a problem even with LUKS encrypted ephemeral storage, because libvirt/nova is not able to write on encrypted cow 13:18:25 but yes it is the same outcoming. We will postpone the nova implementation and thus abandon the spec. 13:19:10 oh, got it. so no cow at all for encrypted local storage instances, needs luks support for ephemeral disk mechanism to support booting them without decrypting 13:19:44 i get what you mean about stages/phases. i think the nova team wants to be able to avoid exposing images unencrypted on the host first because that's the most precarious/dangerous place for sensitive data (what with hypervisor breakout bugs and the like) 13:20:26 fungi, yes. That's a valid reason from the nova side. 13:20:29 so they're more worried about leaking image content on the hypervisor host than elsewhere in the chain 13:22:55 it would just make no sense to protect the image everywhere and then have it plain on the compute host 13:24:30 yes 13:24:36 do we need another to reshape the scope of the pop-up-team or should we just wait and hope nova would implement ephemeral storage encryption :D 13:25:00 that's an open question, i don't have the answer unfortunately 13:25:47 i suspect getting the boot-from-volume case solved first might at least increase interest from others in working on the missing pieces to do the same in nova local storage 13:27:39 fungi, you are right - i think we can leave it as it is right now - it is only mentioned in the disband criteria 13:28:03 #topic Open Discussion 13:28:20 are there any other topics you would like to discuss? 13:29:57 i don't have any 13:30:34 thank you all for joining this meeting today :) 13:30:44 #endmeeting image_encryption