Configuring role-based access control (RBAC) for runbooks in Azure Automation

When setting up runbooks in Azure Automation to invoke automation of a process through PowerShell or Python runbooks, the ability to assign permissions per runbook for user types such as power users is something we missed in the early days of Azure Automation.

When working with permissions in Azure, we have the concept of RBAC available:

Role-based access control (RBAC) enables access management for Azure resources. Using RBAC, you can segregate duties within your team and grant only the amount of access to users, groups, and applications that they need to perform their jobs.

During the past year, the ability to configure RBAC for runbooks was added to the service.

When I initially tested this feature, I granted 1 single test user permissions to an existing user.


# Resource Group name for the Automation Account
$rgName = "AutomationWestEurope-Rg"
# Name of the Automation Account
$automationAccountName ="AutomationWestEurope"
# Name of the runbook
$rbName = "Invoke-RobocopyBackup"
$userId = (Get-AzureADUser -ObjectId '').ObjectId 

# Gets the Automation Account resource
$aa = Get-AzureRmResource -ResourceGroupName $rgName -ResourceType "Microsoft.Automation/automationAccounts" -ResourceName $automationAccountName

# Get the runbook resource
$rb = Get-AzureRmResource -ResourceGroupName $rgName -ResourceType "Microsoft.Automation/automationAccounts/runbooks" -ResourceName "$automationAccountName/$rbName"

# The Automation Job Operator role only needs to be run once per user
New-AzureRmRoleAssignment -ObjectId $userId -RoleDefinitionName "Automation Job Operator" -Scope $aa.ResourceId

# Adds the user to the Automation Runbook Operator role to the runbook scope
New-AzureRmRoleAssignment -ObjectId $userId -RoleDefinitionName "Automation Runbook Operator" -Scope $rb.ResourceId

I then logged into the Azure subscription using that user. As expected, the only resource the user has access to is the single runbook where permissions are assigned:

This means the user is unable to see the whole Automation account, including resources such as global variables, credentials and other shared resources.

After starting a runbook job, everything looked like expected, except for the Output stream being unavailable (“No access”):

After reaching out to the Automation team, I got in touch with Chris Sanders which determined that the Microsoft.Automation/automationAccounts/jobs/output/read permission seemed to be missing.

I was recently asked to test again, since the bug is now fixed.

This time, the required permissions was in place and the Output stream was visible:

The ability to assign runbook permissions for users and groups is a very useful feature, making it possible to use the Azure Portal as the user interface for an automated process. It is then possible to perform tasks without granting the end user permissions directly to backend services such as a SQL database or local administrator permissions on a server.

About the author: Jan Egil Ring

Jan Egil works as a Lead Architect on the R&D Team at Crayon, Norway. He mainly works with automation, and has a strong passion for PowerShell. Products and services he works with includes Microsoft infrastructure products such as Windows Server, System Center and Microsoft Azure. He is a multiple-year recipient of Microsoft Most Valuable Professional Award for his contributions in the Windows PowerShell and Cloud & Datacenter Management technical communities. He speaks regularly at user groups and conferences, such as Nordic Infrastructure Conference (NIC), PowerShell Conference Europe and PowerShell Summit. He is a co-founder of the Norwegian Microsoft Technology User Group (MTUG), which is an association of local MTUG user groups in Norway. He is also co-organizing the MTUG Script Club which focuses mainly on PowerShell. You can follow him on Twitter @JanEgilRing.

Related Posts

%d bloggers like this: