azure-bp-assignment-grant-perm

A blueprint definition containing a role-assignment artifact grants RBAC at the deployment scope when the assignment executes - the assigner effectively controls who gets RBAC at that scope.

derived azure emits CanGrantPermission

match

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

{'principal': None} CanModifyCode {'assignment': None} {'assignment': None} ExecutesAs {'mi': None}

where

node_type(?assignment) == BuildWorker the blueprint definition deployed by ?assignment contains at least one role-assignment artifact (kind=roleAssignment) ?mi holds EFFECTIVE Microsoft.Authorization/roleAssignments/write at the deployment scope (else the artifact fails at deploy time)

emit

source type	`Identity`
target type	`Identity`
source	`<principal>`
target	`<any principal that can be named in the role-assignment artifact>`
permissions	`Microsoft.Blueprint/blueprints/artifacts/write`
conditions	`iam_permission` `role_compatibility`
state logic	CONDITIONAL(trigger_exists) when the principal can modify the role-assignment artifact but must wait for the next assignment execution to realize the grant. ACTIVE when the principal also holds blueprintAssignments/write (trigger in same step). Inherit weakest with CanModifyCode contributor. BLOCKED if the assignment MI does not hold roleAssignments/write at the scope (grant would fail at deploy time -> CONDITIONAL(iam_permission) on the MI RBAC gate).

Narrative

{principal.name} can modify the role-assignment artifacts in the blueprint definition for {assignment.name}; on the next assignment execution, the assignment MI ({mi.name}) creates those role assignments at the deployment scope, effectively granting RBAC to any principal named in the artifact.

Raw rule rules/derived/azure/blueprints.yaml

id: azure-bp-assignment-grant-perm
emits: CanGrantPermission
description: "A blueprint definition containing a role-assignment artifact grants RBAC at the deployment\
  \ scope when the assignment executes \u2014 the assigner effectively controls who gets RBAC at that\
  \ scope."
match:
- - principal: null
  - CanModifyCode
  - assignment: null
- - assignment: null
  - ExecutesAs
  - mi: null
where:
- node_type(?assignment) == BuildWorker
- the blueprint definition deployed by ?assignment contains at least one role-assignment artifact (kind=roleAssignment)
- ?mi holds EFFECTIVE Microsoft.Authorization/roleAssignments/write at the deployment scope (else the
  artifact fails at deploy time)
emit:
  source_type: Identity
  target_type: Identity
  source: <principal>
  target: <any principal that can be named in the role-assignment artifact>
  permissions:
  - Microsoft.Blueprint/blueprints/artifacts/write
  conditions:
  - iam_permission
  - role_compatibility
  state_logic: CONDITIONAL(trigger_exists) when the principal can modify the role-assignment artifact
    but must wait for the next assignment execution to realize the grant. ACTIVE when the principal also
    holds blueprintAssignments/write (trigger in same step). Inherit weakest with CanModifyCode contributor.
    BLOCKED if the assignment MI does not hold roleAssignments/write at the scope (grant would fail at
    deploy time -> CONDITIONAL(iam_permission) on the MI RBAC gate).
  confidence: '0.85'
  derived_from:
  - <CanModifyCode edge_id (principal -> blueprint assignment)>
  - <ExecutesAs edge_id (blueprint assignment -> MI)>
  - azure/identity-escalation.yaml#azure-role-assignment-write (canonical roleAssignments/write -> CanGrantPermission)
  false_positive_note: "The grant only occurs at assignment-execution time; modifying the role-assignment\
    \ artifact without a subsequent assignment-execute produces no grant. The MI must independently hold\
    \ Microsoft.Authorization/roleAssignments/write at the deployment scope \u2014 if it does not, the\
    \ artifact creation fails (400 Bad Request). Role assignments created by blueprint artifacts PERSIST\
    \ after the blueprint assignment is deleted (they are NOT removed by deleting the assignment). Do\
    \ not model them as a deny assignment (deny assignments ARE removed by delete). The can-control linchpin\
    \ control-boundary-via-iam-admin rolls this CanGrantPermission into Controls(scope) when it is scoped\
    \ to a boundary \u2014 cite, do not duplicate."
  narrative: '{principal.name} can modify the role-assignment artifacts in the blueprint definition for
    {assignment.name}; on the next assignment execution, the assignment MI ({mi.name}) creates those role
    assignments at the deployment scope, effectively granting RBAC to any principal named in the artifact.'