With the release of DCSv3, I was excited to give it a try at-scale but since it hasn’t been integrated into Azure Machine Configuration (yet…) I figured I’d try a different approach to deploying and testing it.
A lesser-known feature of Azure and Arc machines are Run Commands. Typically used for quick diagnoses or troubleshooting of a VM that isn’t accessible any other way (SSH/RDP), as long as it’s still able to communicate with Azure.
There are a few different ways to use run commands, most common being the Az CLI, Azure Powershell, or Bicep (there’s no interface for it within Azure (yet…)). Since I’ve been dabbling in Bicep recently, I wanted to see if I could do it through a Bicep template.
NOTE: This is purely for testing purposes and should not be used for production. Deploying DSCv3 through Bicep this way is a proof of concept.
While I’m using Bicep to deploy these Run commands, this isn’t actually using Bicep to generate the JSON input configurations required by DSCv3 to perform actions. This is currently an experimental feature that can be enabled within Bicep and will (hopefully) be integrated into Azure Machine Configuration at some point in the future by Microsoft.
Run commands are typically meant for short script and troubleshooting purposes if all other management access to the machine has been lost (such as RDP/SSH) but it has the distinct benefit that it requires no other extensions installed. This means that as long as a machine is Azure Arc onboarded and is actively connected (online), this will work.
NOTE: The Bicep Templates referenced below can be found HERE.
Deploying Bicep Templates
After logging in to Az CLI, I can simply execute the Bicep template:
az deployment group create --resource-group $resourcegroup --template-file .\Test-RunCommand.bicepMonitoring of the deployment can then be done from the Azure portal by looking at Deployments for the Resource Group:
Initially, I was curious as to what the Run command actually executes, running a brief test deployment with a simple ‘whoami, pwd, and $psversiontable’ script resulted in the above output in the deployment Instance view.
As we can see, by default it runs under system privilege (we can also specify credentials, these could be stored in an Azure Key Vault and pulled in dynamically using Bicep for example).
We can also see it’s running a standard PowerShell 5.1 session in a curiously labeled ‘Downloads’ folder.
Interestingly, opening that folder shows the scripts I’ve run using Run commands:
Deploying DSCv3
Now that we’ve established that Run commands can be used to trigger PowerShell, let’s see about getting DSCv3 into that session to be able to set a registry key. Using a bit of inspiration from DSCv3 Jedi Master Gijs Reijn: https://learndsc.guide/docs/getting-started/.
The DSCv3-SetReg.bicep script is now a bit more complicated, but the most important piece is here:
This will set a new registry key in HKLM:\Software\hsg and report it back:
The deployment looks good! Let’s see on the machine itself:
Similarly, I can now also remove it again, by simple calling DSC with a ‘delete’ action:
This is a fairly rudimentary way of deploying DSCv3 and this method won’t really provide any sort of reporting. However, this did showcase what can be possible by purely onboarding your servers to Azure Arc. It’s a sneak peek at what’s possible with DSCv3 and could even be expanded upon by providing a longer script from a storage account through a SAS token. That way, it could be possible to pull a DSC configuration compiled through Bicep as described by Gijs here.
Conclusion
In any case, it was a fun experiment to showcase how powerful Azure Arc can be even without any extensions installed. For the security conscious amongst you, this may be something you wish to disable locally (especially on your Tier-0 assets) or at the very least, limit access using RBAC.
In the future, I’m hopeful that Microsoft will implement DSCv3 into Azure Machine Configuration and add native Bicep support. Together, that will become a powerful tool to manage servers purely from Azure no matter where they are hosted.
In the meantime, the OpenSSH extension is a fantastic way to gain access to on-premises resources without requiring VPN or port-forwards (hint: it can also tunnel RDP!).
