rage.fail

enter-project-via-impersonation

Executing as a service account in a different GCP project = entering that project (GCP-scoped extension of can-control.yaml escalation logic).

derived gcp emits CanEnterProject

match

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

{'attacker': None} CanExecuteAs {'service_account': None}

where

project_of(?service_account) != project_of(?attacker) ?service_account has IAM role bindings in its project (elevation over attacker)

emit

source type	`Identity`
target type	`Project`
source	`?attacker`
target	`<project of ?service_account>`
conditions	`iam_permission`
state logic	inherit from CanExecuteAs

Raw rule rules/derived/gcp/can-control-gcp.yaml

id: enter-project-via-impersonation
emits: CanEnterProject
description: Executing as a service account in a different GCP project = entering that project (GCP-scoped
  extension of can-control.yaml escalation logic).
applies_to:
- gcp
match:
- - attacker: null
  - CanExecuteAs
  - service_account: null
where:
- project_of(?service_account) != project_of(?attacker)
- ?service_account has IAM role bindings in its project (elevation over attacker)
emit:
  source_type: Identity
  target_type: Project
  source: ?attacker
  target: <project of ?service_account>
  state_logic: inherit from CanExecuteAs
  conditions:
  - iam_permission
  derived_from:
  - ?attacker CanExecuteAs ?service_account (cross-project)
  evidence:
    narrative_template: '{attacker.name} can execute as {service_account.name}, which holds role bindings
      in project {project.name}, granting {attacker.name} access within that project. Execution as {service_account.name}
      with a Workflow, Cloud Function, or other GCP service in {project.name} establishes a project-level
      foothold.

      '