Will "waagent -deprovision[+user]" wipe the cloud-init data?

[yuxisun1217]

Hi there,

It seems that the cloud-init is going to be involved in the RHEL images. Do you think that the "waagent -deprovision[+user]" should wipe the data that generated by cloud-init during provisioning? Because if the cloud-init data is not cleaned, the cloud-init will not provision during the next boot.
Thanks!

Currently we found some cloud-init data like this:

1. /etc/sudoers.d/90-cloud-init-users
2. All the files in /var/lib/cloud/

[hglkrijger]

@yuxisun1217, I confirmed that cloud-init will still provision, since it uses the VM unique id, which ends up in /var/lib/cloud/instances/*. We should still cleanup old data which may be sensitive though, so I will leave this issue open as a feature request.

[yuxisun1217]

@hglkrijger, Sorry for the wrong understanding of this feature and thank you for your confirming. :)

[brendandixon]

@hglkrijger Are these safe to delete (e.g., shutil.rmtree('/var/lib/cloud'))?

[hglkrijger]

@brendandixon I don't think we should remove the root directory, but selectively under it, such as:

/var/lib/cloud/instance
/var/lib/cloud/instances/*
/var/lib/cloud/data/*

[brendandixon]

@paulmey Any comment? You know the cloud-init code better than the rest of us.

[paulmey]

from /usr/share/doc/cloud-init/var-lib-cloud.txt:

to clear out the current instance's data as if to force a "new run" on reboot
do:
( cd /var/lib/cloud/instance && sudo rm -Rf * )

but it's safe to delete all of /var/lib/cloud. It's not installed by the deb and stages.py recursively recreates the whole layout if it doesn't exist.

[brendandixon]

Addressed by #698

[cmelanson]

@brendandixon We are storing scripts in /var/lib/cloud/scripts/per-instance which are executed on the first boot, as we customize the image for our own purposes. This change breaks this functionality for us, and I believe this is a common use case. Would it be possible to not clear out /var/lib/cloud/scripts during this new cleanup procedure or make it configurable?

[brendandixon]

@cmelanson Happy to adjust it. I'll alter the code to remove the minimum needed.

[brendandixon]

@cmelanson Addressed in #702

[rjschwei]

I know this is a really late comment, just reviewing changes before pulling the latest release into SLES.

The idea that one process removes the files left behind by another process is IMHO fundamentally flawed and violates basic principles. In more modern browsers checks have been implemented to ensure one site does not scribble on cookies from other sites for security reasons. Now waagent removes files from cloud-init, sorry but that's just wrong.

First as already confirmed in the thread, cloud-init will recognize when re-provisioning is in order. Second any changes in cloud-init such as additional files in other locations will require work here.

[dsuth1]

Is there a way to disable this feature? This programmatically breaks how per-instance and per-once runs. With this in-place, you could actually never have per-once work as it blows away the contents of that directory when you "deprovision" a box before snapshot. Honestly waagent should not be touching the cloudinit data directories.

[arno01]

Good point, @rjschwei ; Another general point that I would like to highlight is that even if you happen to remove some files which you think might contain sensitive data, then you should not just remove it, but shred it.

Then, depending where the user-data came from, it may and likely still be available there. E.g. $ curl http://169.254.169.254/latest/user-data.