azure-auto-create-workload-as-via-attach-mi

Attach a privileged managed identity to a new or existing Automation Account and trigger a runbook - equivalent to creating a new workload bound to that identity.

derived azure emits CanCreateWorkloadAs

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

{'principal': None} CanAttachIdentity {'account': None} {'principal': None} CanTrigger {'runbook': None}

where

node_type(?account) == AutomationService node_type(?runbook) == GenericCompute ?runbook is in ?account ?principal also has EFFECTIVE CanModifyCode on ?account (or can create a new account with automationAccounts/write)

emit

source type	`Identity`
target type	`Identity`
source	`?principal`
target	`<managed identity attached to ?account>`
permissions	`Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` `Microsoft.Automation/automationAccounts/write` `Microsoft.Automation/automationAccounts/jobs/write`
conditions	`role_compatibility`
state logic	ACTIVE when the principal can attach a privileged MI to an account (CanAttachIdentity) AND can trigger a runbook in that account (CanTrigger) AND either the account already has executable code or the principal can also modify/create code (CanModifyCode). CONDITIONAL(role_compatibility) if MI attachment is unconfirmed or the MI is not compatible with the account. This is the CanCreateWorkloadAs primitive: create/modify a workload (Automation Account) and bind a privileged identity to it.

Narrative

{principal.name} can attach a privileged managed identity to Automation Account {account.name} and trigger a runbook in that account; this yields CanExecuteAs the attached identity (via can-execute-as execute-as-via-new-workload).

Raw rule rules/derived/azure/automation.yaml

id: azure-auto-create-workload-as-via-attach-mi
emits: CanCreateWorkloadAs
description: "Attach a privileged managed identity to a new or existing Automation Account and trigger\
  \ a runbook \u2014 equivalent to creating a new workload bound to that identity."
match:
- - principal: null
  - CanAttachIdentity
  - account: null
- - principal: null
  - CanTrigger
  - runbook: null
where:
- node_type(?account) == AutomationService
- node_type(?runbook) == GenericCompute
- ?runbook is in ?account
- ?principal also has EFFECTIVE CanModifyCode on ?account (or can create a new account with automationAccounts/write)
emit:
  source_type: Identity
  target_type: Identity
  source: ?principal
  target: <managed identity attached to ?account>
  permissions:
  - Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
  - Microsoft.Automation/automationAccounts/write
  - Microsoft.Automation/automationAccounts/jobs/write
  conditions:
  - role_compatibility
  state_logic: 'ACTIVE when the principal can attach a privileged MI to an account (CanAttachIdentity)
    AND can trigger a runbook in that account (CanTrigger) AND either the account already has executable
    code or the principal can also modify/create code (CanModifyCode). CONDITIONAL(role_compatibility)
    if MI attachment is unconfirmed or the MI is not compatible with the account. This is the CanCreateWorkloadAs
    primitive: create/modify a workload (Automation Account) and bind a privileged identity to it.'
  confidence: min(contributing_confidences) * 0.88
  derived_from:
  - 'azure-auto-attach-user-mi: ?principal CanAttachIdentity ?account'
  - 'azure-auto-jobs-write: ?principal CanTrigger ?runbook (or CanModifyCode via azure-auto-runbook-write)'
  - 'can-execute-as.yaml: execute-as-via-new-workload (CanCreateWorkloadAs => CanExecuteAs)'
  false_positive_note: 'Requires both CanAttachIdentity (assign/action + automationAccounts/write) and
    a run path (CanTrigger or CanModifyCode). CanAttachIdentity alone is not sufficient without a confirmed
    way to run code as the attached MI. Only emit when all three edges are verified: MI assignment permission,
    account write, and run path.'
  narrative: '{principal.name} can attach a privileged managed identity to Automation Account {account.name}
    and trigger a runbook in that account; this yields CanExecuteAs the attached identity (via can-execute-as
    execute-as-via-new-workload).'