azure-dbx-cluster-init-script

id: azure-dbx-cluster-init-script
emits: CanModifyCode
description: Cluster init scripts run as root before user code; write access to the init-script URI +
  cluster edit = code injection on every node.
match:
- - principal: null
  - CanWrite
  - storage: null
where:
- 'node_type(?storage) in [ObjectStorage, FileStorage]  # ADLS Gen2 or Blob'
- the target cluster references ?storage as an init_scripts URI
- ?principal also has Databricks CAN_MANAGE or cluster create permission enabling them to SET the init_scripts
  URI on the cluster (POST /api/2.0/clusters/edit or /create)
emit:
  source_type: Identity
  source: <principal>
  target: <Databricks Cluster (BatchJob/GenericCompute)>
  permissions:
  - CanWrite on init-script storage URI
  - databricks:clusters:edit (CAN_MANAGE on cluster or cluster create policy)
  conditions:
  - service_state
  - trigger_exists
  state_logic: ACTIVE if the cluster is running (or can be started) and the principal controls both the
    init-script URI in storage AND has cluster edit capability; CONDITIONAL(service_state) if the cluster
    is stopped; CONDITIONAL(trigger_exists) if no cluster restart/start has been established.
  false_positive_note: Requires BOTH write to the init-script blob URI AND cluster-edit permission to
    set that URI on the cluster. Either alone is insufficient. The init script runs on cluster restart
    (not on an already-running cluster). Without a cluster restart -> CONDITIONAL(trigger_exists + service_state).
    Init scripts run as root, not as the cluster user, but they execute in the same IMDS context as the
    cluster MI.
  derived_from:
  - <CanWrite edge_id on ?storage>
  - <cluster edit permission>
  narrative: '{principal.name} can write the init-script blob for cluster {target.name} and set that init_scripts
    URI (cluster edit), injecting root-level code that runs as the cluster managed identity on next restart.'