gcp-deploy-target-update-attach-identity

clouddeploy.targets.update + actAs(execution SA) re-points all future Cloud Deploy job runs on this target to execute as the chosen SA.

derived gcp emits CanAttachIdentity

match

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

where

emit

source type	`Identity`
target type	`BuildWorker`
source	`?principal`
target	`<Cloud Deploy job run (BuildWorker) on this target, after the execution SA is updated>`
permissions	`clouddeploy.targets.update` `iam.serviceAccounts.actAs`
conditions	`iam_permission`
state logic	ACTIVE when ?principal holds clouddeploy.targets.update AND CanPassIdentity(?principal -> ?exec_sa) is ACTIVE. BLOCKED when an IAM deny policy denies either permission.

source type

Identity

target type

BuildWorker

source

?principal

target

<Cloud Deploy job run (BuildWorker) on this target, after the execution SA is updated>

permissions

clouddeploy.targets.update iam.serviceAccounts.actAs

conditions

iam_permission

state logic

ACTIVE when ?principal holds clouddeploy.targets.update AND CanPassIdentity(?principal -> ?exec_sa) is ACTIVE. BLOCKED when an IAM deny policy denies either permission.

Narrative

{principal.name} can update target {target.name}'s executionConfigs (clouddeploy.targets.update + iam.serviceAccounts.actAs on {exec_sa.name}), re-pointing all future Cloud Deploy render/deploy job runs to execute as {exec_sa.name}. Subsequent rollouts via this target run with {exec_sa.name}'s GCP permissions.

Raw rule rules/derived/gcp/clouddeploy.yaml

id: gcp-deploy-target-update-attach-identity
emits: CanAttachIdentity
description: clouddeploy.targets.update + actAs(execution SA) re-points all future Cloud Deploy job runs
  on this target to execute as the chosen SA.
applies_to:
- gcp
match:
- - principal: null
  - CanPassIdentity
  - exec_sa: null
where:
- ?principal has effective clouddeploy.targets.update on the target
- ?exec_sa is the SA ?principal will set as executionConfigs.serviceAccount
- ?exec_sa is bound via CanPassIdentity through iam.serviceAccounts.actAs (gcp-sa-act-as)
emit:
  source_type: Identity
  target_type: BuildWorker
  source: ?principal
  target: <Cloud Deploy job run (BuildWorker) on this target, after the execution SA is updated>
  permissions:
  - clouddeploy.targets.update
  - iam.serviceAccounts.actAs
  conditions:
  - iam_permission
  state_logic: ACTIVE when ?principal holds clouddeploy.targets.update AND CanPassIdentity(?principal
    -> ?exec_sa) is ACTIVE. BLOCKED when an IAM deny policy denies either permission.
  confidence: 0.92
  derived_from:
  - ?principal CanPassIdentity ?exec_sa (gcp-sa-act-as)
  - clouddeploy.targets.update effective permission
  false_positive_note: "This edge re-points future job runs; it does NOT immediately execute code. The\
    \ actual CanExecuteAs chain fires when a rollout is subsequently created on the updated target (gcp-deploy-rollout-create-modifies-code\
    \ or cicd-chains cicd-modify-buildspec-executes-as). Do NOT emit CanExecuteAs directly from this rule\
    \ \u2014 it attaches identity to the Compute surface (the BuildWorker job runs); execution requires\
    \ the downstream rollout creation edge. The target node must be the BuildWorker node (Compute class)\
    \ that represents the future job runs, not the Target resource itself (ManagementService)."
  narrative: '{principal.name} can update target {target.name}''s executionConfigs (clouddeploy.targets.update
    + iam.serviceAccounts.actAs on {exec_sa.name}), re-pointing all future Cloud Deploy render/deploy
    job runs to execute as {exec_sa.name}. Subsequent rollouts via this target run with {exec_sa.name}''s
    GCP permissions.'