gcp-dataflow-update-contents-modify-config
dataflow.jobs.updateContents also allows changing job configuration parameters (worker count, machine type, autoscaling) on running streaming jobs; configuration changes alone are lower-value escalation than code injection.
match (effective permission)
{
"action": "dataflow.jobs.updateContents",
"resource_type": "google.dataflow.Job"
}
where
?job is a STREAMING job (job type == JOB_TYPE_STREAMING or has no end time)
?job state is RUNNING (active streaming pipeline)
emit
| source type | Identity |
|---|---|
| target type | Compute |
| source | <principal> |
| target | <Dataflow streaming job (BatchJob)> |
| permissions | dataflow.jobs.updateContents |
| conditions | service_state |
| state logic | ACTIVE if dataflow.jobs.updateContents is confirmed in the effective grant at project scope AND the target job is a RUNNING streaming job. Configuration changes (worker count, machine type, autoscaling) do not require a restart. Note: changing environment.serviceAccountEmail is NOT supported after job creation — the worker SA is fixed at launch, so CanAttachIdentity does not apply to Dataflow post-creation. CONDITIONAL(service_state) if job state is unconfirmed. BLOCKED if denied. |
Narrative
{principal.name} can modify the configuration of running streaming pipeline {job.name} (dataflow.jobs.updateContents), including worker count, machine type, and autoscaling settings. Note that worker service account changes are not supported after job creation.
Raw rule rules/derived/gcp/dataflow.yaml
id: gcp-dataflow-update-contents-modify-config
emits: CanModifyConfiguration
description: dataflow.jobs.updateContents also allows changing job configuration parameters (worker count,
machine type, autoscaling) on running streaming jobs; configuration changes alone are lower-value escalation
than code injection.
match_effective_permission:
action: dataflow.jobs.updateContents
resource_type: google.dataflow.Job
where:
- ?job is a STREAMING job (job type == JOB_TYPE_STREAMING or has no end time)
- ?job state is RUNNING (active streaming pipeline)
emit:
source_type: Identity
target_type: Compute
source: <principal>
target: <Dataflow streaming job (BatchJob)>
permissions:
- dataflow.jobs.updateContents
conditions:
- service_state
state_logic: "ACTIVE if dataflow.jobs.updateContents is confirmed in the effective grant at project\
\ scope AND the target job is a RUNNING streaming job. Configuration changes (worker count, machine\
\ type, autoscaling) do not require a restart. Note: changing environment.serviceAccountEmail is NOT\
\ supported after job creation \u2014 the worker SA is fixed at launch, so CanAttachIdentity does\
\ not apply to Dataflow post-creation. CONDITIONAL(service_state) if job state is unconfirmed. BLOCKED\
\ if denied."
confidence: 0.7
derived_from:
- <dataflow.jobs.updateContents effective permission>
false_positive_note: This captures the documented configuration-change capability of updateContents.
However, the escalation value is lower than CanModifyCode (code injection) because configuration-only
changes do not inherently yield execution without an execution-injection edge already in place. Service-account
swaps are not supported post-creation. This edge surfaces configuration-change attack surfaces for
completeness.
narrative: '{principal.name} can modify the configuration of running streaming pipeline {job.name} (dataflow.jobs.updateContents),
including worker count, machine type, and autoscaling settings. Note that worker service account changes
are not supported after job creation.'