Deploying solutions into Azure that rely on Role Based Access often involve us creating IaC automation for the assignment of roles, such as:

• A services access to Key Vault
• A services access to a Key Vault specific secret
• A services access to a storage account
• A services access to a Service Bus Queue or Topic

In many of these instances we may wish to leverage the source resource identity (System Assigned Managed Identity) for the assigned access.

But what happens when we delete the source resource, are the role assignments applied on the target resources removed?

The answer… No they are not.

Your target resources are left with orphaned role assignments. In many cases the use of User Assigned Managed Identity is used to avoid this particular issue as the identity exists regardless of the resource life cycle, at which point there is no orphaning.

But whats the big problem, just redeploy and everything should line up again right?

Unfortunately this is not the case. If you follow through with this sentiment, you will receive the following error from the Azure Resource Manager:

Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (code: RoleAssignmentUpdateNotPermitted)

The reasoning behind is role assignments require a globally unique identifier (GUID) of which out of good practices you have made deterministic for solution deployments. So when you have deleted and recreated the resource the underlying principal ID has now changed, but the role assignment name has not. This infers the problem, you cannot create two role assignments with the same name, even in different Subscriptions, followed with properties of an existing role assignment cannot be changed.

Surly there is a automated process in Azure that will remove these for me? Sadly this is not the case and it has pushed many in resulting to manually searching for and removing these orphaned assignments. This is tedious and time consuming, not to mention requiring the user to have User Access Administrator role access which you may not wish to grant to everyone.

Solution

The solution I came up with uses PowerShell and the az cli to retrieve all role assignments for a given subscription. This is then filtered down to any orphaned assignments scoped to resources in a specific resource group (scope can be changed to what you need). Given that there are orphaned assignments these are then removed through the az cli.

The script looks like this:

$ResourceGroupName = ""

$roleAssignments = az role assignment list --all | ConvertFrom-Json
$orphaned = $roleAssignments | Where-Object { ($_.principalName -eq "") -and ($_.scope -match "resourcegroups/$ResourceGroupName") }
$orphaned.Count
$orphaned | ForEach-Object { az role assignment delete --ids $_.id }

To run this script you will need the following Roles:

• Directory.Read.All
• User Access Administrator (At the respective Scope)

To avoid assigning User Access Administrator to anyone who may need to run this script, I placed this script into a CI/CD pipeline of which the Pipeline Identity has the roles applied as shown above. This way, the development team can remove orphaned role assignments with ease without the need for elevation of privilege.

⚠️ Best Practice of Least Privilege.

Hope this helps, and have fun

After setting up a Logic App (Standard) Backend in Azure API Management (APIM) in my last post, I wanted to try and see if I could create a Swagger definition from a Standard Logic App which could then be used to simplify the API authoring process in APIM. This post shows my methods of doing so.

If you haven’t already I would recommend reading my previous post as this one will be working off of the building blocks of the last.

As with my previous post, the high-level architecture has not changed and neither has the overall aim as shown below.

The design aims to abstract the backend from the api operations, i.e. the backend points to the Logic App and the individual operations point to the respective workflows. The design also specifies granular access to the workflow Shared-Access-Signature (sig) held in the applications specific KeyVault (to see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret). Furthermore, the additional required parameters that are necessary to call a workflow have been implemented through APIM policies to remove the need for callers to understand backend implementation.

I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have broken down the implementation of the diagram above into two parts, Application Deployment, and API Deployment.

Problem Space

Having come across the ARM REST API to generate a Swagger definition for a consumption Logic App, I went searching for the same functionality for Standard Logic Apps. Given a short time searching, I found the REST APIs situated under App Services with the Swagger generation API no where to be seen.

But would this stop me… No.

Knowing that I can retrieve a detailed definition of a Standard Logic App through the Azure Resource Manager, I started looking at methods of stripping out the detail that I would need to construct a Swagger Definition.

My chosen method to do this is through a PowerShell script using both ARM REST APIs and the az cli. This choice will allow me to run the script as non-interactive in future DevOps CI/CD pipelines.

Application Deployment

Our first step toward generating the Swagger definition for our Logic App is to deploy an instance of our Logic App to Azure. The process has not changed from the last post apart from the addition of step 4. As shown in the diagram below, step 4 is where we will use the PowerShell script that I have written to extract the core details of our Logic App and workflows to construct a Swagger Definition.

The script has been designed to take a ControlFile.json that you update with one or more HTTP triggered workflows and API details to assist in the retrieval and generation of the definition. There is an example control file in my GitHub repository.

The SpecCreator.ps1 takes the following parameters:

<#
    .SYNOPSIS
	Creates a Swagger definition for a select Standard Logic App and its specified Workflows.

    .DESCRIPTION
	Uses a series of parameters to derive the Standard Logic App and the Workflows to include in the base Swagger definition template. 

    .PARAMETER SubscriptionId
    The ID of the Subscription that the Standard Logic App is Hosted in.

    .PARAMETER ResourceGroupName
    The Resource Group Name that the Standard Logic App is Hosted in.

    .PARAMETER LogicAppName
    The Name of the Standard Logic App to use for the Swagger Definition.

    .PARAMETER APITitle
    API Name used to define the set of operations.

    .PARAMETER APIDescription
    Description of the API and its set of operations.

    .PARAMETER APIVersion
    None-Mandatory - Specified version of the API. Default is 1.0.0.0

    .PARAMETER SpecTemplatePath
    None-Mandatory - Base path to the swagger definition template, doesn't include the name of the file.

    .PARAMETER ControlFile
    None-Mandatory - Base path to the json control file used to identify the set of Workflows to extract as operations for the swagger definition, doesn't include the name of the file.

	.PARAMETER InteractiveMode
	If specified will request the user to interactively login into Azure for az tooling.
    #>

The script then uses a series of ARM REST API calls to obtain the following detail:

• Request Schema (if one is provided).
• Workflow Definition.

Using the Workflow Definition, we can interrogate the Workflow Trigger for details such as:

• HTTP Method.
• Relative Paths.
  • Note: Path Parameters are expected to be wrapped with curly braces, for example:
    • /users/{id}
    • /cars/{carId}/drivers/{driverId}
    • cars/{carId}/drivers/{driverId}
    • /{carId}/{driverId}
    • {carId}

Once all the Workflow details have been obtained, the script uses an imported tokenised Swagger Definition to generate the respective Definition for your Standard Logic App and Workflows.

API Deployment

For the most part, the API Deployment has not changed. We are using the same Bicep to create the APIM Instance, APIM Backends/Named Values, and Policies. The main change to our Bicep Deployment occurs in step 2.1 as shown in the diagram below.

Rather than constructing the API and API Operations individually through Bicep Resources as done in the previous post, we are going to define the APIM API along with the generated Swagger Definition from earlier steps. APIM validates the Swagger Definition and uses it to construct the API and Operations on our behalf.

The three main differences to our API deployment are:

1. We need to make use of the loadTextContent Bicep function to load the generated Swagger Definition into our Bicep Template.

   var swaggerDefinition = loadTextContent('../../SwaggerGenerator/GeneratedSpec.json')
   

2. We need to change the Microsoft.ApiManagement/service/apis resource to accept our generated Swagger Definition:

   @description('Create the Logic App API in APIM - Loading in Swagger Definition')
   resource logicAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
     name: apiName
     parent: apimInstance
     properties: {
       displayName: apimAPIDisplayName
       subscriptionRequired: true
       path: apimAPIPath
       protocols: [
         'https'
       ]
       format: 'swagger-json'
       value: swaggerDefinition
     }
   }
   

3. We need to remove the following Bicep Module call to create the API Operations as this will now be done for us.

   @description('Deploy logic App API operation')
   module logicAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [for operation in apimAPIOperations :{
     name: '${operation.name}-deploy'
     params: {
       parentName: '${apimInstance.name}/${logicAppAPI.name}'
       lgCallBackObject: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01')
       operationDisplayName: operation.displayName
       operationMethod: operation.method
       operationName: operation.name
   
     }
   }]
   

Summary

The main benefit of using this method over constructing the API and Operations through Bicep is that we only need to define the backing API once.

If you would like to spin up a demo of this implementation or would like to use it as the basis of something you are working on, the source to all my work is in my GitHub repository along with a README that explains how to get started.

Have a go and see if this simplifies your Standard Logic App APIM Configurations.

Be Careful: Adding customisations will bring latency to start-up

One customisation that I came across that I really like is the cloud-native-azure theme using Oh My Posh. The theme gives context to the following:

• Path.
• Git status summary with changing colours and glyphs depending on status.
• Command execution status.
• Terminal Type (pwsh, shell, etc.)
• Battery Status.
• Date and Time.
• Kubernetes Context.
• The part I really like | Azure Subscription Context.

For me, this theme really ticks the box, having both context of git status information and the Azure context in which I may be working is a real productivity assist.

Oh My Posh Theme Install

To install and enable the theme for your command prompt for PowerShell, you will need to do the following:

1. Install a font.
   • Often these customisations will make use of glyphs (graphic symbols) to assist in conveying information quickly.
   • I made use of Nerd Font - 0xProto Nerd Font
   • Simply:
     • Install the font.
     • Unzip the download.
     • Right Click and Install the .ttf files.
2. Enable the font in Windows Terminal.
   • Open the Windows Terminal.
   • Press ctrl+, to get to Windows Terminal Settings.
   • Under Profiles, select Windows PowerShell.
   • Under Additional Settings, select Appearance.
   • Select the drop-down for Font Face and select your downloaded font. For me this is 0xProto Nerd Font.
3. Install Oh My Posh.
4. Apply your theme of choice, or in this case cloud-native-azure.
   • Simply:
     • Load your PowerShell profile through your editor of choice:
       • > code $PROFILE / > notepad $PROFILE
       • If you receive a path error, a profile may not have been setup for you yet. To sort this, use the following PowerShell command:
         • > new-item -type file -path $profile -force
         • Then run the previous command to open the profile for editing.
     • Add the following initiation line for oh-my-posh for your given choice of theme
       • oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\cloud-native-azure.omp.json" | Invoke-Expression

Now the next time you load up your PowerShell terminal, you can enjoy the awesome customisation and hopefully get some productivity benefits too.

Around June 2020 a change was made to Azure API Management whereby any deletion of the instance via the Azure portal, Azure PowerShell, Azure CLI, and REST API version 2020-06-01-preview or later will result in the instance being soft-deleted.

This is to allow for recoverability of a recently deleted API Management instance, and therefore protecting against accidental deletion of the instance.

The problem with this is that not all the Azure Resource Management tooling currently supports the management of soft deleted API Management Instances. Currently the only management tooling that supports this feature are the REST API and Azure CLI. You cannot at this point in time list, show, or purge a soft deleted instance in the Management Portal or Azure PowerShell.

Solutions

Azure CLI

As of the 5th of July 2022, you can use the Azure CLI to manage soft-deleted APIM instances. Specifically CLI version 2.38.0 and above.

Documentation on the relative management actions that can be applied are shown here.

To purge a deleted instance, you can use the following commands:

az login

az account set --subscription "{SubscriptionId}"

// Using the list command and query argument you can obtain the name and location of your soft deleted APIM Instances

az apim deletedservice list --query "[].[name, location]"

// Since you now know the name and location of all the potential instances you wish to purge, you can now issue the purge command for each instance.

az apim deletedservice purge --service-name "{APIMInstanceName}" --location "{RegionDeployedTo}"

Rest API

In-order to purge a soft-deleted APIM instance, you will need to execute the Delete REST API for API Management as per Microsoft Documentation.

To make this simpler, here is some PowerShell using the 2021-08-01 REST API version and az tooling:

$SubscriptionId = '{SubscriptionId}'
$Region = '{Region}'
$APIMInstanceName = '{APIMInstanceName}'

Connect-AzAccount -Subscription $SubscriptionId

$accessToken = Get-AzAccessToken

$request = @{
    Method = 'DELETE'
    Uri = "https://management.azure.com/subscriptions/$($SubscriptionId)/providers/Microsoft.ApiManagement/locations/$($Region)/deletedservices/$($APIMInstanceName)?api-version=2021-08-01"
    Headers = @{
        Authorization = "Bearer $($accessToken.Token)"
    }
}

Invoke-RestMethod @request