AZURE VM EXTENSIONS: PART 3 Refactoring our code
In this last part of talking about Azure VM Extensions I will make a couple of changes to refactor and make things better. Once you have more time, go back and refactor your code, its a good feeling to go back and improve upon the code.
So in this case I wanted to use Managed Identities for the CustomScriptExtension and I couldn’t get it working at first and due to time pressures I resorted to using SAS tokens. The thing I soon realised was that this is not the best way to go and I really wanted to revisit the codebase and get Managed Indentites working.
I see a lot of people created System Assigned Managed Identities and I try my best not to use these as they are tied to a resource, I always create a Managed Identity from the Azure Portal or Bicep first and then use that.

So I refactor my Bicep code for the CustomScriptExtension to use the Managed Identity Ive created and now the code is no longer needing to make use of a new SAS token each time it ran and then use this, its more secure to use a User Assigned Managed Identity.
@description('Deploy required userManagedIdentity')
module userManagedIdentity './modules/Microsoft.ManagedIdentity/userAssignedIdentities/deploy.bicep' = {
scope: resourceGroup(multiTenantResourceGroupName)
name: userManagedIdentityName
params: {
name: userManagedIdentityName
location: location
tags: tags
}
dependsOn: resourceGroups
}
The above Bicep code creates our User Assigned Managed Identity and then we can make use of this within our CustomScriptExtension like so.
module virtualMachineName_ZabixxInstaller './modules/Microsoft.Compute/virtualMachines/extensions/deploy.bicep' = {
scope: resourceGroup(multiTenantResourceGroupName)
name: 'ZabixxInstaller'
params: {
enableAutomaticUpgrade: false
name: 'ZabixxInstaller'
publisher: 'Microsoft.Compute'
type: 'CustomScriptExtension'
typeHandlerVersion: '1.10'
virtualMachineName: virtualMachineNameBackend
location: location
autoUpgradeMinorVersion: true
settings: {
fileUris: [
'https://${storageAccountName}.blob.core.windows.net/${containername}/InstallZabbixAgent.ps1'
'https://${storageAccountName}.blob.core.windows.net/${containername}/zabbix.zip'
]
}
protectedSettings: {
commandToExecute: 'powershell.exe -ExecutionPolicy Unrestricted -File InstallZabbixAgent.ps1'
managedIdentity: {
objectId : userManagedIdentity.outputs.principalId
}
}
}
dependsOn: [
resourceGroups
virtualMachineBackend
]
}
Summary
In summary we went from generating a SAS token off of the Azure Storage account to changing this to use a User Assigned Managed Identity which is more secure.
- Part 1 – AZURE VM EXTENSIONS: PART 1 DSC EXTENSIONS https://gregorsuttie.com/2023/05/30/azure-vm-extensions-part-1-dsc-extensions/
- Part 2 – AZURE VM EXTENSIONS: PART 2 CUSTOMSCRIPTEXTENSION https://gregorsuttie.com/2023/06/05/azure-vm-extensions-part-2-customscriptextension/
Don’t forget to subscribe to my YouTube Channel. And my Newsletter
[…] Part 3 – AZURE VM EXTENSIONS: PART 3 REFACTORING OUR CODE https://gregorsuttie.com/2023/06/11/azure-vm-extensions-part-3-refactoring-our-code/ […]
It’s an interesting discussion on what is a more secure approach – I think a user managed identity is more secure but then shifts the lifecycle issue somewhere else i.e. we would have to manage the lifecycle of that instead as creds lying around could be used.
I’ve used short lived sas tokens before that are generated at the beginning of an operation on the assumption that it’s a single shot script and not one that runs every time a vm is started.
Security is interesting!