So now we have discussed the issue of Public IP addresses as well as concepts around Azure ARM templates.
Next step is to remove their use. Its really quite a simple process of removing entries from both the parameters.json and template.json files.
Consider the Cisco ASAv deployment from the previous deployment.
Looking through the values a number of items relating to the devices Public IP address can be found. Luckilly Cisco used the string public to make things simple to find.
They set things like Public IP sku (Basic), Allocation method, the DNS name along with the address object name.
These values are referenced within the template.json file. Again looking at the ASAv version an excerpt is shown below
The first section is used to describe the varibles for interactive deploymentsor if they are not specified within the parameters.json or overwridden during deploment.
Further down each one is described as a resource. This is the main section that defines the underlying Azure resource. Consider the snip shown below showing a public IP address name object, along with the Azure ARM API that is called to create the object.
Lastly, towards the bottom of the file is an area where the public IP address is bound to the network adaptor. In this case its Nic0 the ASAv’s primary interface.
I’d love to tell you there is a magic way of editing this but sadly there is not. Using a little bit of search/delete my method is to:
Back all files up
Identify in parameters.json any entry relating to the Public IP address.
Search for those names within the deploy.json file.
Remove the entries and the regions around them, remembering to keep the json formatting.
Delete the entry from the parameters.json
Repeat until entries are removed.
Test a deployment, verifying using the Azure Activity Log for your subscription
I have successfully created these for the following infrastructure devices:
Cisco ASAv
Palo Alto NG Firewall
CheckPoint NGX Firewall
Pulse VPN appliance (used to be Juniper)
RSA Authentication Server
F5 BIG-IP
Ill add some links to some before and after examples, however be aware that the templates as well as Azure API’s could in theory change.
Good luck. As I say its not easy however is very possible.
For those who don’t know ARM, this is Azure Resource Manager. It is used for everything in Azure to submit changes, additions and deletions to Azure infrastructure. These are all made via a common API which takes the changes, validates, queues and reports on any change. Regardless of if you use the Azure Portal, Cloud Shell, API, PowerShell or other tools they all use ARM.
Lets take a look.
First of all visit portal.azure.com and authenticate to your subscription. Next click in the master search box at the top and type ‘Activity’ and select the Activity Log
You may then need to change your filter applied to see jobs or tasks that have occured.
Each item can be examined an a JSON representation of the job and actions can be seen.
For any deployment a set of files are required for deployment. When using the Azure Portal, these are created by the web pages and then used to deploy as a Job by Azure Resource Manager.
You can see this just before you hit deploy
Then at the bottom select the ‘download template and parameters’ link
This will display a template page (ill do another post on this) however for now select download.
This will download a ZIP file to your local machine. Save and Open it. From an example I deployed the following files were created
The key files are the parameters.json and template.json files. These are mandatory. The others are scripts and helpers to run the deployment task. (.PS1 for PowerShell/CloudShell, .sh for Bash, .rb for Ruby deployments etc.
All of the settings for the deployment are contained within the parameters.json file. Open it up with a suitable editor such as vsCode or Notepad++
As you can see, variables are well named and obvious and being is JSON format its easy to check its well formatted. Values can be changed and as long as they validate against your exisiting constructs (for instance subnets and vNets) then it should be OK
This file takes the parameters.json file’s values and uses them to create Azure components. The parameters.json being the ingredients and the template.json being the cook book if you like !
This can be deployed using an authenticated Powershell session thus:
#Assumes files are in current path
New-AzResourceGroupDeployment -Name TestASAdeploy -ResourceGroupName test_ASA01_Deployment -TemplateFile template.json `-TemplateParameterFile parameters.json
This will then deploy to a new Resource Group using the parameters and template file.
Follow my next post in the series about removing Public IP address from Azure deployments.
A typical organisations deployment usually will have existing infrastructure deployed such as Azure Firewalls, Load Balancers and Virtual Network Gateways (VPN termination) to front access into IaaS VM’s, App Services and other systems.
Larger organisations will have policies (or should!) around governance of configuration within their cloud deployments. Smaller ones should at least consider it. Common practice is to safeguard admins from creating things such as new Azure AD deployments in each subscription, deploying oversize or very costly VM’s, adding new vNets or even NSG’s. These can all be controlled with appropriate Azure Policy and AAD Roles.
A common policy is to stop admins from creating new Public IP addresses. Why do you need them when you have existing Express Route conections from your corprate sites, or other methods of connectivity. You can effectivly bypass layers of security controls and services by simply provisioning a new device. Hence its a sensible control.
This poses an issue however. Most 3rd party appliances from the store require a public IP address to be created. For instance the Cisco ASAv, Palo Alto NG Firewalls, F5 BIG-IP (although they have recently recoginsed the issue and make some templates availible without) and other services.
Consider the diagram below showing the relationship of key Azure constructs and components with a deployment.
It shows how a VM has components associated with it such as disks and Network Interfaces. The Network Interfaces are connected to a subnet, which is part of a Virtual Network (vNET). The Network Interface is also associated with a Public IP Address.
However, there is an important concept in Azure to grasp. That is that any service deployed in Azure with a public facing IP does not have knowledge of its public IP address. Even though a Network Interface may be associated with a Public IP address the host has no knowledge of it. Not its external IP address, routing, nothing. If it has a default route set, it will be via whatever subnet it is connected to. Unless it has a User Defined Route which allows an override of Azure routing.
The vendors do not make it easy to deploy devices without a Public IP address. In fact they may even state its not supported, although this would be difficult to prove. It is very possible to build devices this way. Luckilly, Azure and its fantasic ARM templates comes to the rescue.
Ill describe this in follow up posts (coming soon)
Recent Comments