A Single Partner for Everything You Need Optiv works with more than 450 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.
Breadcrumb Home Insights Source Zero Tearing Down Azure Resources and Replying to Emails Using Power Automate Flows and Azure Runbooks November 04, 2020 Tearing Down Azure Resources and Replying to Emails Using Power Automate Flows and Azure Runbooks Microsoft Power Automate Flows, UI Flows, & Automation Runbooks: Part Seven of a series In this last post of the blog series, I will cover how I used Power Automate flows and Azure runbooks to tear down my Azure resources and reply, with proof, to the original flow requester that execution was successful. There are two parallel branches that complete the flow. These actions include deleting all of the resources used by the UI flow in the test environment and responding to the original flow requester by email. All of the resources used for testing were deleted so that I did not incur any additional Azure charges for the test environment. The easiest way to do this was to delete the entire resource group. To do this, I used the Az PowerShell command Remove-AzResourceGroup. Once authenticated, Remove-AzResourceGroup only requires only the Resource Group parameter in order to execute. The runbook, with service principal authentication, looks like this: Param( [Parameter (Mandatory= $true)] [string]$ResourceGroup ) #Service Principal Authentication $Thumbprint = 'YOURTHUMBPRINTHERE' $TenantId = 'YOURTENANTIDHERE' $ApplicationId = 'YOURAPPLICATIONIDHERE' Connect-AzAccount -CertificateThumbprint $Thumbprint - ApplicationId $ApplicationId -Tenant $TenantId -ServicePrincipal #Remove Resource Group Remove-AzResourceGroup -ResourceGroupName $ResourceGroup -Force The screenshot below shows the flow action with variable Vendor as a prefix to -ResourceGroup, which is the only required parameter in the runbook shown above. As this action is taking place, a parallel branch is also running. The parallel branch sends an email reply to the original flow requestor of the email notifying them that the flow has completed successfully. In the email reply, I wanted to add evidence that the user workflow tested was successful. I could have just added the paths to the Azure blob, but I decided to attach the screenshot zip file from the Azure storage container to the email. To accomplish this, first I needed to initialize a variable which was the container location of the WinAutomation screenshots. The value of the blob is the path to the container and blob. The initialize variable action is necessary because at the time of the flow creation, the winautomation.zip file, which is the storage blob, does not exist. The file is not created until after the UI flow action is run. With the variable configured, I used the Get blob content action under the Azure Blob Storage service connector. The blob value in the Get blob content action is the blob variable that is defined under initialize variable. The blob variable represents /winautomation-logs/WinAutomation.zip. Now that the blob content is established in the flow, I was able to use the Reply to email (v3) action from Office 365 Outlook to respond to the sender of the original email trigger and add the blob content as an attachment. The only required value in this action is message id. The required message id is the dynamic value of the message id found in the “When a new email arrives (V3)” original flow trigger seen in the image below. The body is not a required value, but I wanted to add some text with the Vendor variable selected for parts of the body that may change, based on the vendor software being upgraded or patched. With the message id and body of the email defined, the last step was to attach the blob content as an attachment to the email. First, I needed to define what the attachment name was. I used the (vendor variable) _Flow_Screenshots.zip as the name attachment. Note: it is important to define the extension. The attachments content is the dynamic value of File Content from the Get blob content action or it will not be attached correctly. Below is an example reply that the original email requestor receives: Parallel Actions Final Flow The final flow steps: Email is received as the trigger. Email body is searched for separate regex matches for Owner, Vendor and IP using the Plumsail connection. In parallel, the Flow checker workaround VM is turned OFF. Separate variables are initialized for Owner, Vendor and IP. Each matching regex pattern is set as separate variables for Owner, Vendor and IP. Azure Resources are created, and the Resource Group is tagged with the Owner name. Resource Group Virtual Machine (from an existing snapshot) Network Subnet NIC Network Security Group and Rules Public IP Address The VM public IP is replaced with a specific IP from a different resource group that is allowed to access Salesforce. The WinAutomation Database (with any new processes) is copied to the VM from an Azure Blob A delay of four minutes takes place to allow the VM’s On-premises Data Gateway to register as Online with Power Automate. The custom WinAutomation UI Flow (RPA) for Salesforce case creation runs. Screenshots are captured to the VM desktop. Screenshots are zipped as Screenshots.zip and uploaded to an Azure storage container. The blob variable (container and blob) for the Screenshots.zip file is initialized. The blob content of the Screenshots.zip file is retrieved. Parallel Branches The test resource group and all resources are deleted from Azure. An email is sent to the original flow requestor notifying them that there were no errors during the flow, with the Screenshots.zip file attached to the email. Note: There are several conditional statements that provided errors by email if the overall flow or UI flow failed. This flow proves out the use case that through Flows, UI Flows, and Automation Runbooks, Microsoft provides the platform to create and test user workflows in order to gain efficiency and confidence in the patch and software update process. Additional Information and Links: Initialize a Variable: https://www.youtube.com/watch?v=fBS3wyWZo6Q Az PowerShell: https://docs.microsoft.com/en-us/powershell/azure/new-azureps-module-az?view=azps-4.6.1 Stop Azure V2 VMs: https://gallery.technet.microsoft.com/scriptcenter/Stop-Azure-ARM-VMs-1ba96d5b Graphical Runbooks: https://docs.microsoft.com/en-us/azure/automation/automation-graphical-authoring-intro Remove-AzResourceGroup: https://docs.microsoft.com/en-us/powershell/module/az.resources/remove-azresourcegroup?view=azps-4.6.1 Azure Blob Storage: https://us.flow.microsoft.com/en-us/connectors/shared_azureblob/azure-blob-storage/ https://github.com/optiv/azure_runbooks Here's a review of related posts on this series: Part 1: Using Microsoft Flows and UI Flows for Patch and Software Testing Part 2: Provisioning RPA Test Environments With Azure Automation Runbooks Part 3: Assigning Specific Public IP Addresses With Azure Automation Runbook Part 4: Robotic Process Automation with WinAutomation Part 5: Copying Updated WinAutomation Databases for RPA With Azure Custom Script Extensions Part 6: Uploading WinAutomation Screenshots to Azure Container Storage Using Invoke-AzVMRunCommand Part 7: Tearing Down Azure Resources and Replying to Emails Using Power Automate Flows and Azure Runbooks By: Dan Kiraly Senior Research Scientist | Optiv Dan Kiraly is senior research scientist on Optiv’s R&D team. In this role he's responsible for use case development and the vetting of security products for Optiv. Share: Microsoft Power Automate Power Automate Flows UI Flows Robotic Process Automation RPA Azure Automation Automation Runbooks CDX Patch Management Orchestration Automation Blue Team Source Zero® Copyright © 2024 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
Copyright © 2024 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