aws-glue-attach-role-via-update

Change an existing Glue job's RoleArn to a passed privileged role via glue:UpdateJob + iam:PassRole; the next run executes as the new role.

derived aws emits CanAttachIdentity

match

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

where

emit

source type	`Identity`
target type	`Compute`
source	`?principal`
target	`?job`
permissions	`glue:UpdateJob` `iam:PassRole`
conditions	`iam_permission` `role_compatibility` `condition_expression`
state logic	if ?role trust policy or iam:PassedToService is unknown/unresolved: POTENTIAL(role_compatibility). Else ACTIVE for the attach step (the job's RoleArn is now the passed role). Full execution-as-new-role still requires a start path (glue:StartJobRun or an existing trigger): this edge feeds aws-glue-execute-as-update-script once the role is attached.

source type

Identity

target type

Compute

source

?principal

target

?job

permissions

glue:UpdateJob iam:PassRole

conditions

iam_permission role_compatibility condition_expression

state logic

if ?role trust policy or iam:PassedToService is unknown/unresolved: POTENTIAL(role_compatibility). Else ACTIVE for the attach step (the job's RoleArn is now the passed role). Full execution-as-new-role still requires a start path (glue:StartJobRun or an existing trigger): this edge feeds aws-glue-execute-as-update-script once the role is attached.

Narrative

{principal.name} can re-point Glue job {job.name} to run as {role.name} (glue:UpdateJob + iam:PassRole to glue.amazonaws.com), so the next run executes as {role.name}.

Raw rule rules/derived/aws/glue.yaml

id: aws-glue-attach-role-via-update
emits: CanAttachIdentity
description: Change an existing Glue job's RoleArn to a passed privileged role via glue:UpdateJob + iam:PassRole;
  the next run executes as the new role.
applies_to:
- aws
match:
- - principal: null
  - CanModifyConfiguration
  - job: null
- - principal: null
  - CanPassIdentity
  - role: null
where:
- node_type(?job) in [BatchJob]
- CanModifyConfiguration comes from glue:UpdateJob
- ?role trust policy allows glue.amazonaws.com
- iam:PassRole for ?role permits iam:PassedToService including glue.amazonaws.com
emit:
  source_type: Identity
  target_type: Compute
  source: ?principal
  target: ?job
  permissions:
  - glue:UpdateJob
  - iam:PassRole
  conditions:
  - iam_permission
  - role_compatibility
  - condition_expression
  state_logic: 'if ?role trust policy or iam:PassedToService is unknown/unresolved: POTENTIAL(role_compatibility).
    Else ACTIVE for the attach step (the job''s RoleArn is now the passed role). Full execution-as-new-role
    still requires a start path (glue:StartJobRun or an existing trigger): this edge feeds aws-glue-execute-as-update-script
    once the role is attached.'
  confidence: min(contributing_confidences)
  derived_from:
  - <CanModifyConfiguration(principal, job) edge_id>
  - <CanPassIdentity(principal, role) edge_id>
  false_positive_note: "Requires iam:PassRole for the NEW role scoped to glue.amazonaws.com; when the\
    \ new role's trust or iam:PassedToService is unknown, downgrade to POTENTIAL(role_compatibility).\
    \ The attach step is ACTIVE once trust/ PassedToService admits Glue, but privilege gain only materializes\
    \ on the next run \u2014 this edge chains to CanExecuteAs via aws-glue-execute-as-update-script after\
    \ the role is attached AND a run path exists."
  narrative: '{principal.name} can re-point Glue job {job.name} to run as {role.name} (glue:UpdateJob
    + iam:PassRole to glue.amazonaws.com), so the next run executes as {role.name}.'