On 28/10/2025 14:10, Markus Hentsch wrote:
Dear OpenStack community,
in preparation for the vPTG discussion slot for the image encryption (Thursday 30th at 16:00 UTC) I collected a summary explaining the key points and state of the contribution and gathered some discussion topics below. Since this spans multiple projects (mainly Glance, Cinder and Nova) and has been ongoing for quite some years, I tried my best to briefly summarize the most important aspects of the current state so that all those who wish to participate have the latest information.
The text below can also be found on the etherpad: https://etherpad.opendev.org/p/2026.1-ptg-glance-planning#L128
Summary:
- historically, only Cinder has been able to create and use encrypted images (as a side effect) by dumping LUKS-encrypted volumes 1:1 into images, for exclusive use in Cinder - this contribution aims to introduce encrypted image functionality for the end user: images can be encrypted/decrypted outside of OpenStack and resulting (encrypted) image is stored in Glance and the key in Barbican - goal: standardize encrypted image formats and handling across Glance, Cinder and Nova - it introduces two formats: raw LUKS and qcow2-wrapped LUKS (native qcow2 feature) - it introduces new key handling: if Barbican secret is of type 'passphrase' it is used as the LUKS key as-is; if it is of any other secret type, it is assumed to be binary and converted via 'binascii.hexlify()' (preserves Cinder behavior and compatibility) - it makes use of the new secret consumer API in Barbican to prevent accidental key deletion (since keys may be managed by users, not OpenStack), registering images as consumers to their keys - note: the image encryption feature focuses on Glance and Cinder for now, Nova has been largely excluded so far due to ephemeral storage encryption not being ready yet
Implementation State (note: aside from os-brick this is not merged yet!):
- os-brick: implemented outsourced utility function to discern encryption between passphrase and binary (hexlify conversion) for shared usage by Nova and Cinder - Glance: implemented new encryption-specific image formats and properties as well as secret consumer handling - Cinder: implemented encrypted image usage for volumes: LUKS is handled as raw (like before) and qcow2+LUKS is converted; image creation from volume stays limited to raw LUKS - Nova: implemented only compatibility with os-brick and Cinder changes so far - barbican-tempest-plugin: full scenario tests (image > volume > server > SSH) for 4 permutations of the image encryption
Patchsets: https://review.opendev.org/q/topic:%22LUKS-image-encryption%22
Discussion Topics:
1) Image inspection: related to CVE-2024-32498 concerns were brought up about encrypted image payload containing malicious formats triggering unintended QEMU behavior; how to screen encrypted image payload and reject undesired formats? 1a) limiting to specific formats has consequences for Cinder: attached (secondary) encrypted volumes might contain arbitrary binary data in VMs (user choice), when uploading as image to Glance it might be rejected as prohibited format; additionally, such image vanishes without trace because there is no error state for images (bad Glance <-> Cinder interaction) - how to address this? 1b) how deep do we want to look into encrypted image payload? decrypting a 1TB image might be very costly (CPU load, disk space) - problem: "qemu-img convert" cannot stream to stdout (see https://blogs.igalia.com/berto/2025/07/15/converting-qemu-qcow2-images-direc... ); in the worst case we have to wait for the full 1TB to be decrypted, consuming almost twice the amount of disk space in the process, instead of being able to only read the payload header and abort
honestly i think inspecting the content of the image violates one of the primary usecase for this which is confidential computing where we do not trust the infra hence why we are encyprting the image. so to me the only thing that feels reasonable for the luks image type is to assert that the final image has an a valid luks header but don't try and look inside for the presence fo a gtp partion table for example that would require decryption. for luks in qcow with an embedded luks partition then we shoudl aslo assert the qcow headers and ensure that non of the problematic feature like datafile or backing file fail the saftey check but again we should not be decrypting the content of the image. for qcow in luks that should not be supported. if it was supported that would only be reasonable if the disk type was luks but then qemu should really reject that because we should be explicitly telling qemu that the file is in raw format in this case not qcow. i don't think we can really protect form this by default but i we can mitigate this in 2 ways. one glance has a list of supported image type, admin can remove luks form that list. nova could/should have a similar list fo image type each compute node will allow to be used. that can simiarly allow use to reject luks images finally we coudl also have a polciy rule for luks image in nova/glance that default to member but could be restricted by an operator that would allow them to restrict it to the service role so that luks image could only be created and uploaded by nova or cinder not an end user. this is my preferred way to lock down the ability to create a malicious image by allowing operator to restrict creating luks images to services or admin. my less preferred option would be to default the new luks policy for nova/glance to requrie the manager or the admin roles. that woudl require the admin to use custom policy or grant enduse more permission then they likely shoudl have to use this feature. this to me feel like a featur that normal enduser shoudl be able to use out of the box so the default should be `member` IMO
2) Nova integration: how to approach future interoperability with ephemeral storage encryption? 2a) can we handle this as separate future expansion to this feature, i.e., merging Glance+Cinder functionality short-term with only compatibility changes in Nova for now and addressing full Nova integration as a next step with dedicated patchsets based on the current work?
this work is currently paused so while i don't think we should do something intentional incompatible i don't think you should have to go out of your way to explicitly support it provide you do not break the existing lvm backend supprot.
3) Better organization: would there be any interest in reviving the image encryption popup-team meeting? https://meetings.opendev.org/#Image_Encryption_Popup-Team_Meeting
Best regards,
Markus Hentsch