-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AzureRM Builder: private_virtual_network_with_public_ip assigns a Basic SKU Public IP #458
Comments
@dan-hills-hrt I am working on fixing this now and was curious if you could provide some feedback on the approach, we have until the end of March before this becomes a breaking change, so ideally I hope to fix this in the next week or so. Standard SKU IPs require a network security group to allow ingress, currently whenever creating a Standard SKU Public IP the plugin creates a new NSG that allows ingress from any IP, or from a list of any allowed IP addresses the user specifies. My assumption would be that if a user has created there own subnet, it would be preferable for them to manage their own Network Security Group outside of the Packer build process, and that Packer would just try and create a Public IP with Standard SKU and assign it to the pre-existing subnet. However there is another recently opened issue #468 opened by @cailyoung who has requested the ability to set the client IP addresses when setting I could see an implementation where the plugin tries to create the NSG and assign it to the existing subnet, but there are risks to this as it involves us modifying an existing resource, which may likely already have an NSG, subnets can only have one. There is also risk here if the plugin unexpectedly halts or is SIGKILLed that we'd leave an orphaned uncleaned up NSG exposing the user's vnet, which seems like an unacceptable risk to me. Do you think that expecting the users to create their own NSG here is reasonable? |
@JenGoldstrich is there a reason the NSG isn't being applied to the NIC instead of the subnet? |
In our case the source IP restriction will float due to where we run Packer from. So a prebuilt NSG wouldn't work for us, however I can see the value in BYO NSG (similar to BYO VNet) |
There isn't a reason as far as I know @cailyoung from the docs you link it seems like that's the way to go to enable us to handle the problem of wanting Packer to manage the NSG for you in a private vnet with public IP scenario. IMO the default should probably be to expect users to configure their own NSG still, and then allow users to enable the new functionality (just to make it less of a disruptive change to people's existing network infra). I'll try wiring that up to test, thanks for the suggestion! |
Community Note
Overview of the Issue
When attempting to build using the AzureARM builder and using the property
private_virtual_network_with_public_ip
, the VM resource is being deployed with a public IP assigned with a Basic SKU.During the build process, if I attempt to associate the resource with an existing vnet which is using a NAT rule, this fails as it expects and supports only Standard SKU public ips.
The NAT gateway has been used as a way to access a separate, remote resources from the Packer VM using a trusted IP address.
Reproduction Steps
Steps to reproduce this issue
private_virtual_network_with_public_ip
andvirtual_network_name
to a resource declaration.Packer version
1.11.2
Simplified Packer Template
Operating system and Environment details
Windows 11
Log Fragments and crash.log files
The trimmed log received:
This error repeats a few more times but the errors seems to be consistent.
After a build attempt, I was also able to confirm that the public ip resource is of a Basic SKU type:
This SKU will also need to be updated to Standard as the Basic SKU for public IPs is planned to be retired and may not function in the future: https://azure.microsoft.com/en-us/updates?id=upgrade-to-standard-sku-public-ip-addresses-in-azure-by-30-september-2025-basic-sku-will-be-retired
The text was updated successfully, but these errors were encountered: