Option 1
Run commands yourself
Your own account holds these.
-
Key Vault Secrets Officer— the vault -
Virtual Machine Contributor— each VM, or its resource group
AzureVMCredentialRotation
Prerequisites
Two ways to run this, and two different identities doing the work. Running a command yourself uses your own rights; the deployed orchestrator uses an identity the deployment creates.
Software
- PowerShell 7.2 or later
-
Az.Accounts,Az.Compute,Az.KeyVaultandAz.Resources - A Key Vault using RBAC authorisation, not access policies
- Azure CLI with Bicep, or Terraform, for the deployment only
Who needs which role
Option 2
Deploy the orchestrator
A managed identity holds these. The deployment creates it and assigns them.
-
Key Vault Secrets Officer— the vault -
Virtual Machine Contributor— the scopes you name -
Automation Job Operator— the automation account -
Log Analytics Reader— the workspace -
Monitoring Metrics Publisher— the data collection rule
To run the deployment: Owner or User Access Administrator on every scope you name. The vault must use RBAC authorisation, not access policies.
When not to use this
The first section of the README argues for using something else. Most machines have a better answer than this one.
| If your machines are | Use | Why |
|---|---|---|
| Domain-joined or Entra-joined Windows | Windows LAPS | Built in, free, rotates on use natively |
| Reachable with Entra login | Entra login for Azure VMs | A local credential you never issue is one you never rotate |
| Managed by a PAM product | That product | Session brokering and checkout are a different problem |
| Not in Azure at all | Something else | This drives the VMAccess extension, which is Azure-only |
| Linux, hardened so the account has no passwordless sudo | Keep them out of scope | Every rotation writes that grant back |