Add support for specifying optional network_security_group_name in Packer Azure ARM configuration

[gurumachupalli]

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

Add support for specifying optional network_security_group_name in the Packer Azure ARM configuration. This enhancement will allow users to specify these components if they have a pre-existing Network Security Group in their Azure environment.

Use Case(s)

• Allow an already created Azure Network Security Group (network_security_group_name) in the user’s Azure Cloud to be used by the temporary Network Interface Packer will create.

Potential configuration

Add the following fields to the Config struct in config.go:

type Config struct {
    // Existing fields...
    
    // Name of the network security group to use.
    NetworkSecurityGroupName string `mapstructure:"network_security_group_name" required:"false"`
}

Potential References

• Update template-factory.go and relevant functions to incorporate the new field network_security_group_name. This may involve modifying how the ARM template is generated and ensuring that these values are correctly referenced and used during the deployment process.
• Update resource_resolver.go and relevant functions to validate that the provided network_security_group_name exists in the provided Azure Cloud.

[gurumachupalli]

I'll be working on this issue but let me know if there is something in the works or if this feature is already implemented

[gurumachupalli]

@JenGoldstrich Have a question! Why is a deploy template used in the cases of creating virtualNetworks, networkInterfaces, networkSecurityGroups, publicIPAddresses, virtualMachines, and KeyVault instead of the Azure SDK?

Noticed that resource group creation uses it and the delete calls as well

• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_create_resource_group.go#L43
• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_deploy_template.go#L308
• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_deploy_template.go#L376
• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_deploy_template.go#L366
• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_deploy_template.go#L357
• https://github.com/hashicorp/packer-plugin-azure/blob/main/builder/azure/arm/step_deploy_template.go#L425-L434

[JenGoldstrich]

Hey @gurumachupalli, the short answer here is that it always has been this way, and its risky to change it, so we wouldn't likely do so without a missing feature in ARM templates, or some upcoming deprecation, which seems unlikely due to Microsoft's own internal support of it.

We look forward to your contribution, @tanmay-hc or myself will review it once its posted, feel free to open a draft PR if you run into any issues and ask for help, thanks for picking up this issue!

The long answer is the decision to use ARM templates was made at the initialization of builder over 10 years ago, this plugin was originally written by Microsoft engineers who made open source contributions to the main Packer repo, then the plugin split occurred many years ago and this repo was created.

As I understand it ARM templates are an encouraged format by Microsoft, especially 10~ years ago. In the intervening years many powerful solutions have become standards, like Terraform, but ARM is still used heavily at Microsoft, and fully supported. I think there is logic in using ARM templates to deploy multiple interconnected resources, but this does make it harder to add new features, and debug issues, as I'm sure you're seeing while working on your contribution.

There is a lot of logic and code that goes into our template builder, moving all of this into separate resource calls could easily lead to breaking changes, this requires substantial developer effort to move off of safely. Generally I think this risk is not something we'd want, unless there was a specific feature to gain from moving off of ARM templates, or if Microsoft deprecated ARM templates, neither of which seem likely to happen.

[gurumachupalli]

Thanks for the update! @JenGoldstrich
Here's my PR: #515

• Need to add unit tests
• Need to update docs and relevant READMEs
• Let me know if I need to make changes! Thanks!