Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 400 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
Provisioning RPA Test Environments With Azure Automation Runbooks
In the first part of this blog series, I outlined the use case, created the flow trigger and three parallel branches that defined three different variables. In this post, I will cover how to use an Azure Automation runbook to provision a test environment that will be used for robotic process automation.
With the email trigger defined and Owner, Vendor and IP variables defined, the next step in the process will be passing these variables into an Azure Automation Action in order to create the resources needed for the Azure test environment. The test environment will be used to run a user workflow, simulated with robotic process automation.
There are a few different ways within Azure to provision resources. One of them is through the use of Azure Automation runbooks. Azure Automation is separate from Power Automate and Logic Apps. Azure Automation provides an orchestration platform through PowerShell, Python or graphical runbooks. I decided I wanted to create all of the resources with some of type of command line entry for two reasons. One, I was curious and wanted to learn. Two, I needed to automate the process and anything done within the Azure console wasn’t going to work. After some research, I decided to use an Automation Account and custom runbook.
Azure provides a few different ways to create custom runbooks, but as someone familiar with PowerShell, it only made sense for me to use it to create my runbook. Other options are shown here.
The runbook I created to provision my resources has three mandatory parameters that are defined at the top of the script: the owner, vendor and source IP address. These parameters must be defined in order to successfully execute the runbook.
While I am not going to go into extreme detail on the script below, the runbook, using Az PowerShell cmdlets and a service principal, creates the following Azure resources for our test environment:
It is important to understand that the script uses a snapshot of an Azure virtual machine when creating the new virtual machine. The virtual machine has some preinstalled software required for parts of the use case. It was easy to have some of the software preinstalled to reduce the complexity of this flow. The snapshot includes PowerShell v7, Az Copy, WinAutomation, and an on-premises data gateway. PowerShell v7 and Az Copy are used to upload files to Azure Container Storage in a later action. WinAutomation is our RPA software and the on-premises data gateway is already registered with Power Automate, so that when the virtual machine is turned on, Power Automate UI Flows knows which host to execute the robotic process automation on. This software, properly configured, is crucial to the success of the flow.
With the script in place. I can use the Create job action (shown below) under the Azure Automation connector to trigger the PowerShell runbook above.
With Create job selected as the action, several additional sections are required by Power Automate. These are shown in red in the image below. A connection (below on right) needs to be selected and then each of the values needs to be selected. The resource group is the group that the runbook is located. This was selected under the automation account, which was shown above.
In the image above, each highlighted blue box shows the required parameters needed by the custom runbook I created. The values shown are the owner, vendor, and IP variables that I defined in earlier in the flow from the initialize and set variable actions. This was covered in part one of the series. Using the dynamic value button as seen in the smaller image below I am able to select these values.
When the action is reached in the flow, it will pass the owner, vendor, and IP values to the PowerShell runbook. Azure will create a resource group and resources based on the vendor value that was pulled from the body of the email trigger. It will also create a tag value Owner: Kiraly for the resource group. This can be seen in the image below.
Not only does the script above create all of the resources, but it also adds the IP address from the body of the email and places it in a security group called Microsoft-Edge-RDPSecurityGroup. This allows the requestor to RDP into the new Azure virtual machine from the IP address they submitted in the original email.
The next blog post will cover the next action in the flow, assigning the virtual machine an approved IP address.
Additional Reference Information:
Azure Automation: https://docs.microsoft.com/en-us/azure/automation/automation-intro
Automation Account: https://docs.microsoft.com/en-us/azure/automation/automation-create-standalone-account
Azure PowerShell Az module: https://docs.microsoft.com/en-us/powershell/azure/new-azureps-module-az?view=azps-4.7.0
Manage Modules in Azure Automation: https://docs.microsoft.com/en-us/azure/automation/shared-resources/modules
Application and service principal objects in Azure Active Directory: https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Az Copy: https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10
Softomotive WinAutomation: https://www.winautomation.com/
On-premises data gateway: https://docs.microsoft.com/en-us/power-automate/gateway-reference
Power Automate UI Flows: https://flow.microsoft.com/en-us/ui-flows/
Additional note: PowerShell Az Module Import
It is worth noting that the Azure Az modules needed to be imported from the Modules gallery in order for automation service to be made aware of the cmdlets and successfully execute the runbook. It can get a little confusing with the nuances between Az, AzureRM, and Azure CLI. It is also important to know that Azure cli commands are not available in the automation service. Az and AzureRM modules can be imported through the Modules gallery. The modules that an automation account has available can be found under Modules seen below.
Here's a review of related posts on this series:
Copyright © 2022 Optiv Security Inc. All rights reserved.
No license, express or implied, to any intellectual property or other content is granted or intended hereby.
This blog is provided to you for information purposes only. While the information contained in this site has been obtained from sources believed to be reliable, Optiv disclaims all warranties as to the accuracy, completeness or adequacy of such information.
Links to third party sites are provided for your convenience and do not constitute an endorsement by Optiv. These sites may not have the same privacy, security or accessibility standards.
Complaints / questions should be directed to Legal@optiv.com
November 04, 2020
Can user workflow verification be tested in an automated fashion using Microsoft Power Automate Flows, UI Flows and Automation Runbooks?
How to assign a specific public IP address using Azure Automation runbook. Part three in a series.
Part four in the series: setting up RPA with WinAutomation.
Let us know what you need, and we will have an Optiv professional contact you shortly.