ximon18
commented
4 years ago FYI my current way of automating the work around for this problem is to run the following command after launching Packer:
doctl compute droplet list --format "ID,Name" | fgrep packer | awk '{print $1}' | xargs doctl compute firewall add-droplets XXXX --droplet-idsWhere XXX is the ID of a firewall I created whose only rule is to permit SSH only from my public IP address.
It is possible that the Droplet is attacked between the invocation of the DigitalOcean Marketplace
cleanup.shwhich truncates the logs andimg_check.shscripts which checks the logs, resulting inimg_check.shwarning about non-empty logs due to logged intrusion attempts, and thus failing the Packer build.Or at least I assume that is what was happening in my case, see below. I could not otherwise explain the sudden appearance of firewall related log entries after the log had been cleared.
Stopping UFW isn't an option as then
img_check.shcomplains. Stopping UFW logging only prevents some logging, not all. Stoppingrsyslogdidn't help either.My solution was to apply a DigitalOcean firewall to the Droplet created by Packer that allowed SSH only from my IP address, thereby preventing the unwanted communication attempts from reaching the VM and thus being logged.
Automating this is non-trivial as the Packer DigitalOcean builder doesn't support enabling a DO firewall on the Droplet, nor does Packer expose the Droplet ID to the template. In theory one can use the
cloud-init query instance_idcommand in a shell provisioner to write the Droplet ID to a file, then download it using a file provisioner and then use a shell-local provisioner to executedoctl compute firewall createto create the firewall, and then delete the firewall at the end. However, Packer doesn't have the notion of steps to always run and so the teardown of the firewall will not happen if any of the prior build steps fail, and runningshell-localcommands assumes the host hasdoctlinstalled and configured with the right DO API token, and brittle assumptions about which command syntax will work on the host have to be made (is it Linux, is it Windows?).If you have any advice on how to avoid this issue that would be most appreciated. Alternatively, extending the DigitalOcean Packer builder to be able to add a firewall to the created Droplet limiting SSH to "my ip" (perhaps via a Packer user variable) would help work around this problem.
Here is an example of the problem that I encountered:
img_check.shwarnings:Actual log file contents at the time: