underlying fog lib does not securely destroy digitalocean VMs!
sneak opened this issue · comments
There is a scrub_data parameter that can be passed to the digitalocean API that will overwrite a root with zeros on destroy. It does not appear that the fog gem is doing this, so AFAICT this driver is leaving cookbooks and potentially sensitive data/configs on the blockdev on digitalocean for the next customer.
This is also a bug in fog, but I'm filing it here because fog's issue isn't really relevant to a test-kitchen user.
confirmed - i am able to recover previous customer data off of digitalocean blockdevs (dd if=/dev/vda bs=1M | strings -n 100 > out.txt) so any digitalocean VM ('droplet') created and then had sensitive data copied to it and then destroyed via test-kitchen will leave that data on the SSD for the next customer to read.
I don't currently have the fog version locked so just updating fog on your system should be enough to fix the problem. I can lock fog to the new version if it's out yet if you prefer?
@sneak it appears digitalocean has made this the default now. Fog has also updated their code, I'm going to go ahead and close this, if it's still a issue please reopen.