rage.fail

gcp-batch-can-create-job

derived gcp emits CanCreate

match (effective permission)

{ "action": "batch.jobs.create", "resource_type": "google.batch.Job" }

emit

source type	`Identity`
target type	`*`
source	`<principal>`
target	`<project/location Batch scope>`
permissions	`batch.jobs.create`

Narrative

{principal.name} can create Batch jobs in {scope.name} (batch.jobs.create); running attacker-supplied code as a runtime SA additionally requires iam.serviceAccounts.actAs on that SA.

Raw rule rules/derived/gcp/batch.yaml

id: gcp-batch-can-create-job
emits: CanCreate
match_effective_permission:
  action: batch.jobs.create
  resource_type: google.batch.Job
emit:
  source_type: Identity
  target_type: '*'
  source: <principal>
  target: <project/location Batch scope>
  permissions:
  - batch.jobs.create
  escalation: Submit a job with an attacker-controlled runnable. Turning creation into execution as a
    runtime SA additionally requires iam.serviceAccounts.actAs on that SA (default or custom); batch.jobs.create
    alone cannot start a job. See gcp-batch-execute-as-via-create / -via-default-sa for the actAs-gated
    execution edge. No invoke/trigger needed once actAs is held.
  note: Batch has no batch.jobs.update and no per-job IAM policy; the runnable is fully attacker-controlled
    at create time only. This bare CanCreate edge is not execution on its own -- actAs on a usable SA
    (including the default Compute Engine SA) is required to run the job.
  narrative: '{principal.name} can create Batch jobs in {scope.name} (batch.jobs.create); running attacker-supplied
    code as a runtime SA additionally requires iam.serviceAccounts.actAs on that SA.'