{"id":690,"date":"2026-05-28T08:30:00","date_gmt":"2026-05-28T06:30:00","guid":{"rendered":"https:\/\/au2mator-consulting.com\/?p=690"},"modified":"2026-06-03T13:46:51","modified_gmt":"2026-06-03T11:46:51","slug":"secure-azure-automation-architecture","status":"publish","type":"post","link":"https:\/\/au2mator-consulting.com\/en\/secure-azure-automation-architecture\/","title":{"rendered":"How to Build a Secure Azure Automation Environment: Architecture Guide"},"content":{"rendered":"

\"Secure<\/p>\n

Azure Automation accounts often start as a convenience. Someone needs to schedule a script. They create an Automation Account, add a runbook, and it works. Six months later, that account runs 30 production runbooks with broad permissions, shared credentials, and no audit trail.<\/p>\n

We’ve audited Automation environments where a single account had Contributor access to the entire subscription. Where credentials were stored as unencrypted variables. Where anyone in the IT team could edit runbooks directly in the portal.<\/p>\n

None of this started as negligence. It started as “we’ll secure it later.” Later never came.<\/p>\n

This guide covers the architecture decisions that make an Azure Automation environment secure from the start. Not theoretical best practices. Concrete configurations we implement in consulting projects.<\/p>\n

Authentication: Managed Identity Over Everything<\/h2>\n

Run As Accounts are deprecated. Certificate-based service principals are complex to maintain. Application secrets expire and rotate awkwardly. Managed Identity eliminates all of these problems.<\/p>\n

System-Assigned Managed Identity<\/h3>\n

Every Automation Account should have a System-assigned Managed Identity enabled. It’s a single toggle in the Azure Portal. Once enabled, the Automation Account gets an identity in Entra ID that can be granted RBAC roles.<\/p>\n

In your runbooks, authentication becomes one line:<\/p>\n

Connect-AzAccount -Identity<\/code><\/pre>\n
No certificates. No secrets. No rotation. The identity is tied to the lifecycle of the Automation Account. Delete the account, the identity disappears.<\/p>\n
User-Assigned Managed Identity<\/h3>\n
For scenarios where multiple Automation Accounts need identical permissions, or where you need the identity to persist independently of the account, use a User-assigned Managed Identity.<\/p>\n
Create the identity once. Assign it RBAC roles. Attach it to multiple Automation Accounts. If you rebuild an Automation Account, reattach the same identity without re-granting permissions.<\/p>\n
In runbooks, specify which identity to use:<\/p>\n
Connect-AzAccount -Identity -AccountId \"client-id-of-user-assigned-identity\"<\/code><\/pre>\n
When You Still Need Service Principals<\/h3>\n
Sometimes Managed Identity isn’t enough. Cross-tenant access, third-party APIs that require OAuth client credentials, or legacy applications that only support certificate auth. In these cases, store credentials in Azure Key Vault and retrieve them at runtime. Never as Automation variables. Never in runbook code.<\/p>\n
See the most common Azure Automation mistakes including credential handling<\/a><\/p>\n
Least Privilege: Only What’s Needed<\/h2>\n
The most dangerous Automation Account is one with Contributor access to the subscription. It can create resources, modify configurations, delete entire resource groups. If a runbook is compromised, the blast radius is everything.<\/p>\n
Start with zero permissions.<\/strong> For each runbook, document exactly what it needs to do. Then grant the minimum RBAC role at the narrowest scope.<\/p>\n
Examples:<\/p>\n\n\n\n\n\n\n\n\n\n
Runbook Purpose<\/th>\nRBAC Role<\/th>\nScope<\/th>\n<\/tr>\n<\/thead>\n
Start\/Stop VMs<\/td>\nVirtual Machine Contributor<\/td>\nResource Group containing the VMs<\/td>\n<\/tr>\n
Read Log Analytics<\/td>\nLog Analytics Reader<\/td>\nSpecific workspace<\/td>\n<\/tr>\n
Manage DNS records<\/td>\nDNS Zone Contributor<\/td>\nSpecific DNS zone<\/td>\n<\/tr>\n
Create Entra ID users<\/td>\nUser Administrator<\/td>\nDirectory level<\/td>\n<\/tr>\n
Send email via Graph<\/td>\nMail.Send<\/td>\nSpecific mailbox<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Custom roles work well for Automation. If a runbook only needs to start and stop VMs (not delete or resize), create a custom role with just Microsoft.Compute\/virtualMachines\/start\/action<\/code> and Microsoft.Compute\/virtualMachines\/deallocate\/action<\/code>. Nothing more.<\/p>\n
Review permissions quarterly. Runbooks get decommissioned, but their permissions linger. We’ve found Automation Accounts with roles for resources that no longer exist.<\/p>\n
RBAC on the Automation Account Itself<\/h2>\n
Who can do what with the Automation Account matters as much as what the account can do to other resources.<\/p>\n
Azure provides three relevant built-in roles:<\/p>\n
Automation Operator:<\/strong> Can start jobs and view runbooks but not edit them. Perfect for operations teams who need to trigger runbooks without modifying code.<\/p>\n
Automation Contributor:<\/strong> Can create and edit runbooks, manage schedules, and configure the account. For the automation development team.<\/p>\n
Reader:<\/strong> Can view everything but change nothing. For auditors, managers, or anyone who needs visibility without control.<\/p>\n
Don’t give everyone Contributor access. In most organizations, 2\u00e2\u20ac\u201c3 people need Contributor. Everyone else should be an Operator or Reader.<\/p>\n
For sensitive runbooks (those handling user provisioning, financial data, or security operations), consider a dedicated Automation Account with tighter RBAC. Separation of duties isn’t just for compliance. It limits the damage if someone makes a mistake.<\/p>\n
Secrets Management with Key Vault<\/h2>\n
Azure Automation has built-in credential assets and encrypted variables. They work. But Key Vault is better.<\/p>\n
Why Key Vault over Automation credentials:<\/strong><\/p>\n