rage.fail

azure-vm-contributor

derived azure emits CanAdminister

match (effective permission)

{ "action": "Microsoft.Compute/virtualMachines/*", "scope_type": "resource|resourceGroup|subscription" }

where

principal effectively holds the Microsoft.Compute/virtualMachines/* wildcard (Virtual Machine Contributor / Contributor / Owner) at the scope

emit

source type	`Identity`
target type	`*`
source	`<principal>`
target	`<virtualMachine in scope>`
permissions	`Microsoft.Compute/virtualMachines/*`

Narrative

{principal.name} has full control of VM {target.name} (Microsoft.Compute/virtualMachines/*).

Raw rule rules/derived/azure/vm.yaml

id: azure-vm-contributor
emits: CanAdminister
match_effective_permission:
  action: Microsoft.Compute/virtualMachines/*
  scope_type: resource|resourceGroup|subscription
where:
- principal effectively holds the Microsoft.Compute/virtualMachines/* wildcard (Virtual Machine Contributor
  / Contributor / Owner) at the scope
emit:
  source_type: Identity
  target_type: '*'
  source: <principal>
  target: <virtualMachine in scope>
  permissions:
  - Microsoft.Compute/virtualMachines/*
  false_positive_note: CanAdminister requires the Microsoft.Compute/virtualMachines/* wildcard (VM Contributor/Owner).
    A custom role granting only .../virtualMachines/write (without runCommand/extensions/start) does NOT
    get CanAdminister here; it is instead covered by azure-vm-write-config (CanModifyConfiguration). The
    wildcard grants full control of the VM object but NOT Microsoft.Authorization/*/write and NOT the
    login/loginAsAdmin data actions; it is still sufficient for code execution via runCommand/extensions.
  narrative: '{principal.name} has full control of VM {target.name} (Microsoft.Compute/virtualMachines/*).'