An init script is a shell script that runs on every node of a cluster before the Spark driver or executor starts, so it can change anything on the machine. Databricks recommends cluster-scoped scripts over global ones, pinning OS package versions, and avoiding init scripts where a platform feature does the job.
What the docs say
Databricks documentation defines an init script as a shell script that runs during startup of each cluster node before the Apache Spark driver or executor JVM starts. It adds that init scripts are not supported on serverless compute, and recommends using other features where possible: compute policies for system properties, environment variables and Spark configuration, and compute policies for library installation. It says not to install libraries using init scripts.
Two kinds exist. Cluster-scoped scripts run on every cluster configured with the script, and are the recommended type. Global scripts run on all clusters in the workspace configured with dedicated access mode or no-isolation shared access mode, and the docs say they can cause unexpected issues such as library conflicts. Only workspace admins can create global scripts.
Why this is a security topic
A script that runs before Spark has the run of the node. Whoever controls the script controls what every job on that cluster runs on. Three risks follow.
- Broad reach. A global script touches many clusters at once, so a bad change spreads fast.
- Hidden changes. Scripts that install software outside your lockfiles create dependencies no scan of your repository will see.
- Unreviewed edits. Whenever you change any init script, all affected clusters must restart, and a change can slip in unnoticed if the file location has loose permissions.
Controls worth setting
| Control | How |
|---|---|
| Prefer cluster-scoped scripts | Limits blast radius to named clusters |
| Restrict who can create global scripts | The docs say admins only, so keep the admin group small |
| Pin OS package versions | The docs advise pinning, for example package equals version in apt, to keep environments reproducible |
| Store the script in a controlled location | Unity Catalog volumes, workspace files or cloud storage, per the runtime recommendations |
| Review changes like code | Keep the script in Git and deploy from there |
| Use policies for libraries | The docs say not to install libraries via init scripts |
On standard access mode, an admin must add scripts to an allowlist, which is a useful review point. Treat the allowlist as a change control rather than a formality.
Where scripts may be stored
The docs give location guidance by runtime: for Databricks Runtime 13.3 LTS and above with Unity Catalog, store scripts in Unity Catalog volumes; for 11.3 LTS and above without Unity Catalog, workspace files; for older runtimes, cloud object storage. Scripts on DBFS have reached end of life and can no longer be used, so migrate any that remain.
Whichever location you use, check who can write to it. A script that anyone in the workspace can edit is a path to code execution on every cluster that runs it.
A short audit
- List all global and cluster-scoped scripts in a workspace.
- For each, note the owner, the storage location and who can write there.
- Remove anything a compute policy or a library setting can do instead.
- Pin any OS packages the script installs.
- Add the scripts to version control and require review.
See also Databricks library scopes: who can install what.
Safeguard's asset discovery and dependency scanning can help list what your data platform depends on. A free scan is at gold.safeguard.sh/scan.
Quick check
Who can create a global init script?
According to the Databricks docs, only workspace admin users. Keep that group small and review what they add.
Should an init script install Python libraries?
The docs say not to. Use compute policies or library settings, which are easier to review and pin.
Sources
- Init scripts, Databricks documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
