When building automated processes, Microsoft Azure Automation just doesn’t always do the trick. Sometimes, you want third-party PowerShell modules, or you just need to be able to call some legacy application, or you just need access to on-premise resources such as a database server or file server, none of which are doable all that easily (if at all). This means that you need to run them from a physical machine or virtual machine, either on-premises or in the cloud. As our company has been moving to the cloud, the company has been moving to only PaaS services and has not put any virtual machines into Microsoft Azure (yes companies make this decision, we are working with one now). Because of this, we can’t just run a VM in Azure to run everything as we are doing everything possible to avoid VMs in Azure. But as part of the script, you want to connect to resources in Microsoft Azure using a Managed Identity. This becomes a bit of an issue as you can’t use Managed Identity with an on-premises machine… except that you can under one specific situation, which is to use Hybrid Worker Groups under an Azure Automation Account.
When you set up a runbook within an Automation Account and schedule it to run, you tell the runbook if it will run in Azure by default. This isn’t a setting you can change unless you have configured a Hybrid Worker Group within the Automation Account. When the Hybrid Worker Group is enabled, you specify which machines will be a part of the Hybrid Worker Group by installing the Hybrid Worker Group agent on the machines. This includes machines that are running on-premises.
Once you have enabled the agent and configured the machines to be in the Hybrid Worker Group, you can enable Managed Identity on the Automation Account, giving the Automation Account a Managed Identity. Now, when you run a script and specify that the script will run against the Hybrid Worker Group (which you can do when you schedule or manually execute the runbook), it will run the script within the runbook on the on-premises machine, but within the authentication context of the Automation Account.
Now, your script can run on a VM that you specify, including VMs that are on-premises under the context of a Managed Identity. This allows you to connect to Azure features such as Azure Key Vault, which require very specific permissions, and you don’t want to store credentials to connect to KeyVault somewhere where they can be potentially read. Now, the script can run under a Managed Identity account, which is then used to connect to KeyVault and get the information it needs, all from an on-premises virtual machine and without the risk of exposing any credentials.
Denny
