4 ms·

The issue I have with your statement is that whilst you are likely entirely correct, it was not the expectation defined by DigitalOcean when they built the inte

by nixgeek 13y ago

The issue I have with your statement is that whilst you are likely entirely correct, it was not the expectation defined by DigitalOcean when they built the interface. The interface clearly states: "This is irreversible. We will destroy your droplet and all associated backups" It is very reversible so that statement is plainly untrue. There are also nasty 'corner cases' (very unexpected) in the resuscitation of droplets, whether you had 'Scrub Data' checked or otherwise, wherein DigitalOcean is tampering with the snapshot contents and replacing the SSH host keys. Totally understand the point Moisey made about needing to poke in ~/.ssh/authorized_keys so a customer can gain access but that's very different to the /etc/ssh ones which are being replaced entirely unnecessarily, and with significant security detriment since you now have a harder job in verifying this is indeed the instance you think.

nwh 13y ago
I agree. I would have expected data to be nuked, not nuked on one volume and retained on another.
- derefr 13y ago
  Would you expect deleting a Docker container to delete a Docker image made from it?
  - nixgeek 13y ago
    That's not necessarily a good analogy since you're talking about a COW (copy-on-write) situation, not always, granted, but in this case it seems true. DigitalOcean admitted that in some cases they are using qcow, so I wouldn't say I expect the image (e.g. Ubuntu 13.10 x64) to disappear when I hit 'Destroy!' (with the appropriate bits set for secure destruction) but any changes which I have made should certainly be gone. Single Layer: http://i.stack.imgur.com/Riw7y.png http://i.stack.imgur.com/Riw7y.png Multi Layer: http://docs.docker.io/en/latest/_images/docker-filesystems-multilayer.png http://docs.docker.io/en/latest/_images/docker-filesystems-m... In Docker parlance I would not expect the base image to disappear forever, that's a separate layer, but I would expect that were DigitalOcean serving up containers with a 'Scrub Data' option then the contents of my writeable container would be securely erased.
derefr 13y ago
The "destroyed instance" snapshot is a template (just like everything else in the "spawn an instance" UI.) It's not meant to be used to "resuscitate the instance"; it's meant to be used spawn new children from a prepared state. This is what differentiates it from an instance's "backups", which, as DO says, are purged by secure-erase. Note a word above: children. As in multiple. If you're spawning multiple children from a template, each child needs its own identity and unique tokens (e.g. SSH keys.)
- nixgeek 13y ago
  I didn't ask them to make a template from an instance which I wanted to be securely, irrecoverably destroyed and one of the key lines of explanation for this entire issue by DigitalOcean was to allow customers to undo mistakes which to my mind reads more like resuscitation than templating.
pekk 13y ago
I'm not sure I criticize a service for not destroying my data by default when there is an easy way that I actually can destroy my data.

by nixgeek 13y ago

nwh 13y ago

I agree. I would have expected data to be nuked, not nuked on one volume and retained on another.

derefr 13y ago
Would you expect deleting a Docker container to delete a Docker image made from it?
- nixgeek 13y ago
  That's not necessarily a good analogy since you're talking about a COW (copy-on-write) situation, not always, granted, but in this case it seems true. DigitalOcean admitted that in some cases they are using qcow, so I wouldn't say I expect the image (e.g. Ubuntu 13.10 x64) to disappear when I hit 'Destroy!' (with the appropriate bits set for secure destruction) but any changes which I have made should certainly be gone. Single Layer: http://i.stack.imgur.com/Riw7y.png http://i.stack.imgur.com/Riw7y.png Multi Layer: http://docs.docker.io/en/latest/_images/docker-filesystems-multilayer.png http://docs.docker.io/en/latest/_images/docker-filesystems-m... In Docker parlance I would not expect the base image to disappear forever, that's a separate layer, but I would expect that were DigitalOcean serving up containers with a 'Scrub Data' option then the contents of my writeable container would be securely erased.

derefr 13y ago

The "destroyed instance" snapshot is a template (just like everything else in the "spawn an instance" UI.) It's not meant to be used to "resuscitate the instance"; it's meant to be used spawn new children from a prepared state. This is what differentiates it from an instance's "backups", which, as DO says, are purged by secure-erase. Note a word above: children. As in multiple. If you're spawning multiple children from a template, each child needs its own identity and unique tokens (e.g. SSH keys.)

nixgeek 13y ago
I didn't ask them to make a template from an instance which I wanted to be securely, irrecoverably destroyed and one of the key lines of explanation for this entire issue by DigitalOcean was to allow customers to undo mistakes which to my mind reads more like resuscitation than templating.

pekk 13y ago

I'm not sure I criticize a service for not destroying my data by default when there is an easy way that I actually can destroy my data.