Even now – after all this time – passwords are hard.
Yes, I know we should all be using Cloud with its fancy KeyStore/Key Vaults or enterprise store such as CyberArk. We all know we should not be chosing them. However, like it or not ‘things’ still need passwords. Whether its for an encryption key, wireless network or just a plain and simple password.
Vendors are also part of the problem, placing restrictions on types of characters or even positioning of them within a password. Still. In 2020! (VMware and Cisco are pretty horrific at this)
Also when you are building stuff in automation, its inevitable you will need some sort of password generating. I use PowerShell a lot and found methods that could be used to do this.
This is based on using the Psuedo Random Number Generator (PRNG) which is a feature provided by the Windows Cryptographic Service Provider (CSP) which generates randomness in a ‘good enough’ manner. If you need more than this then well you know why and what to do about it but for most uses this is pretty good.
It uses vendor safe methods and arrangments out of the box with a pretty good 16 character length. You can append flags to make it stronger, output a number of them or make them readable. Its up to you. Your choice.
# Import the module
PS > import-module .\Password-Functions.psm1
# Run the function
PS > New-Password
LC*ATg2F0CFmh-r4
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.
One thing I have been working on for a long time is to create a set of PowerShell modules for Cisco ACI.
For those that don’t know ACI is Cisco’s Next Generation DataCentre switching fabric. Kind of the next step after Nexus in NX-OS mode. It uses modern tecnniques such as hardware controllers (APIC’s – C220 servers) along with Nexus 9500 and Nexus 93xxx switches to form a leaf-spine deployment.
Whilst ACI has a GUI, MO and NX-OS like CLI (not perfect at all !) along with Python and even Ansible, these quickly run out of steam. Whilst Python is a great language it still takes some learning. Its also not so intuative when passing results between methods.
I realised there is nothing for ACI to utilise PowerShell in a similar way that VMware’s NSX has the most excellent PowerNSX
Hence, my first cut of ACI-PoSH published to GitHub. There is a ton of work to do on this – documentation being a biggie – but it works.
Development Process
I am quite lucky to have been involved in some large scale ACI deploments however when offline from these I have two enviroments that I use.
The Cisco DevNet ACI Sandbox availible at https://developer.cisco.com/site/sandbox/ This is a site that contains working examples of most Cisco products, one being the ACI Simulator (Always on) which in an Internet connected APIC. No charge but you do need to register or login. Just the job for testing, learning and development.
The Cisco ACI Simulator (see here) You need a valid CCO account and ACI software support to download. It will run in most Hypervisors (I use VMware Workstation and ESXi) but need at least 80GB HDD, 8 cores and 16GB RAM availble. You will also need your friendly Cisco Account Manager to authorise the activation code
Ill be adding more info here in later posts about just how to use it.
Recent Comments