aws-opsworks-set-permission-grants-access

opsworks:SetPermission lets a principal grant any OpsWorks user admin or deploy rights on a stack, enabling self-escalation to deployment capability.

derived aws emits CanGrantPermission

match

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

where

emit

source type	`Identity`
target type	`Identity`
source	`?principal`
target	`<any OpsWorks user on ?stack (incl. ?principal itself)>`
permissions	`opsworks:SetPermission`
conditions	`iam_permission`
state logic	ACTIVE when ?principal has effective opsworks:SetPermission on the stack and the target user has an OpsWorks UserProfile in the account. CONDITIONAL if the target user does not yet have a UserProfile (requires opsworks:CreateUserProfile first). The downstream escalation (granted deploy rights -> CreateDeployment -> CanExecuteAs) is derived by rules 1 and 3 of this file feeding cicd-chains; not re-derived here.

source type

Identity

target type

Identity

source

?principal

target

<any OpsWorks user on ?stack (incl. ?principal itself)>

permissions

opsworks:SetPermission

conditions

iam_permission

state logic

ACTIVE when ?principal has effective opsworks:SetPermission on the stack and the target user has an OpsWorks UserProfile in the account. CONDITIONAL if the target user does not yet have a UserProfile (requires opsworks:CreateUserProfile first). The downstream escalation (granted deploy rights -> CreateDeployment -> CanExecuteAs) is derived by rules 1 and 3 of this file feeding cicd-chains; not re-derived here.

Narrative

{principal.name} can call opsworks:SetPermission to grant any OpsWorks user (including itself) admin or deploy rights on stack {stack.name}; these rights then allow opsworks:CreateDeployment, enabling code execution as the instance profile role.

Raw rule rules/derived/aws/opsworks.yaml

id: aws-opsworks-set-permission-grants-access
emits: CanGrantPermission
description: opsworks:SetPermission lets a principal grant any OpsWorks user admin or deploy rights on
  a stack, enabling self-escalation to deployment capability.
match:
- - principal: null
  - HasPermission
  - stack: null
where:
- node_type(?stack) == ApplicationPlatform
- ?stack.provider_type == 'AWS::OpsWorks::Stack'
- ?principal has effective opsworks:SetPermission on ?stack
emit:
  source_type: Identity
  target_type: Identity
  source: ?principal
  target: <any OpsWorks user on ?stack (incl. ?principal itself)>
  permissions:
  - opsworks:SetPermission
  conditions:
  - iam_permission
  state_logic: ACTIVE when ?principal has effective opsworks:SetPermission on the stack and the target
    user has an OpsWorks UserProfile in the account. CONDITIONAL if the target user does not yet have
    a UserProfile (requires opsworks:CreateUserProfile first). The downstream escalation (granted deploy
    rights -> CreateDeployment -> CanExecuteAs) is derived by rules 1 and 3 of this file feeding cicd-chains;
    not re-derived here.
  confidence: 0.9
  derived_from:
  - ?principal HasPermission ?stack (opsworks:SetPermission)
  false_positive_note: "SetPermission only grants OpsWorks-level access (IAM/SSH/admin/deploy flags within\
    \ the OpsWorks control plane). It does NOT grant IAM policies \u2014 OpsWorks access levels map to\
    \ which opsworks:* actions are allowed via the OpsWorks-managed IAM policy template. The escalation\
    \ path is: SetPermission -> target user gains opsworks:CreateDeployment on this stack -> cicd-chains\
    \ CanExecuteAs. Self-grant is the primary concern (attacker already has SetPermission; grants itself\
    \ deploy rights on the same stack). Only emit for targets where the escalation is meaningful."
  narrative: '{principal.name} can call opsworks:SetPermission to grant any OpsWorks user (including itself)
    admin or deploy rights on stack {stack.name}; these rights then allow opsworks:CreateDeployment, enabling
    code execution as the instance profile role.'