Securing packer builds via allowed_inbound_ip_addresses

[seqdan]

Hi,

When we create images via self-hosted Azure Devops Agents, the packer machines are created with public IP addresses and accessible via the public internet. This has raised security concerns, as, with all publicly reachable machines, it did not take long for brute force attempts to start.

To make things safer, there seem to be three possibilities:
a) a combination of the building azure agents and the packer build machines being in the same vnet and packer parameters virtual_network_name + virtual_network_subnet_name + virtual_network_resource_group_name
b) a combination of the packer parameters virtual_network_name + virtual_network_subnet_name + virtual_network_resource_group_name + private_virtual_network_with_public_ip
c) A value set for allowed_inbound_ip_addresses, given the building agent knows its own public IP address

I would rate the security level of the a) higher than the one of b) and c). I think all three solutions have their place and use cases:
a) may be useful where high security standards apply
b) may be useful where a vnet solution is preferred
c) may be useful where the simplest possible solution is preferred

I had to rule out solution a) for myself due to missing privileges in Azure.
With solution b) I struggled, as even with parameters set the vnet was not used; the packer build machines had public IP addresses themselves and were fully exposed. It might be doable, but I gave up due to time constraints.
Solution c) worked immediately for me. It requires an additional parameter allowed_inbound_ip_addresses in the packer files, and I suggest to also add a new command line switch to the GenerateResourcesAndImage.ps1 file.

The proposed changes are quite small and isolated.

I will create a PR to suggest and clarify. Any suggestions or comments?

[miketimofeev]

@seqdan Hi! Thanks for your proposal. We use a) at the moment as the safest one. We will take a look at your PR.