file based disk images do not get scrubbed on delete

Bug #1218994 reported by Alan Meadows
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Wishlist
Unassigned

Bug Description

Right now, LVM backed instances can be scrubbed (overwritten with zeros using dd) upon deletion. However, there is no such option with file backed images. While it is true that fallocate can handle some of this by returning 0s to the instance when reading any unwritten parts of the file, there are some cases where it is not desirable to enable fallocate.

What would be preferred would be a similar the options cinder has implemented, so the operator can choose to shred or zero out the file, based on their organizations own internal data policies. A zero out option satisfies those that must ensure they scrub tenant data upon deletion, and shred would satisfy those beholden to DoD 5220-22.

This would of course make file backed disks vulnerable to https://bugs.launchpad.net/nova/+bug/889299 but that might not be a bad thing considering its quite old.

Attached an initial patch for nova/virt/libvirt/driver.py that performs the same LVM zero scrub routine to disk backed files, however it lacks any flags to enable or disable it right now.

Tags: libvirt
Revision history for this message
Alan Meadows (alan-meadows) wrote :
Revision history for this message
Michael Still (mikal) wrote :

Thanks for the patch Pentheus. We use an online code review process for review patches. Could you please follow the steps at https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer to register and then propose your patch? Thanks!

tags: added: libvirt
Changed in nova:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Sean Dague (sdague) wrote :

So, honestly, I think the scrub approach is too error prone, because it requires an active thing later to get rid of the data. However, the encrypted disk work that's been coming in, especially if there is a per instance generated key, means the data is useless if someone goes and physically removes the server from the cluster. So my $0.02 would be focus on the encrypted data path instead.

Revision history for this message
Max Lobur (max-lobur) wrote :

I would like to raise this up again. We have a willingness to commit this functionality upstream. Anybody still thinks this would be useful?

An option called
wipe_vm_disk_with_zeros_before_delete=True
and corresponding change in libvirt driver for file-backed images.

Revision history for this message
Sean Dague (sdague) wrote :

Marking as Opinion because the solution here really needs to be encryption at rest so that a crashed nova compute doesn't leave customer data out there.

Changed in nova:
status: Triaged → Opinion
Darla Ahlert (da741q)
Changed in nova:
assignee: nobody → Darla Ahlert (da741q)
Darla Ahlert (da741q)
Changed in nova:
status: Opinion → In Progress
Darla Ahlert (da741q)
Changed in nova:
assignee: Darla Ahlert (da741q) → nobody
Changed in nova:
status: In Progress → Confirmed
Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote :

Closed as "Opinion" in comment #5 and wrongly re-opened by follow up updates of this bug report.

Changed in nova:
status: Confirmed → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.