Cluster Policies (Databricks): Definition und Beispiel

Cluster Policies (Databricks) sind Konfigurations-Vorlagen im Admin-Bereich einer Databricks-Umgebung, die einschränken, wie Nutzer Compute-Cluster anlegen dürfen. Administratoren legen fest, welche VM-Instanztypen (die Art des virtuellen Servers, auf dem der Cluster läuft), welche maximale Cluster-Größe, welche Databricks-Runtime-Version und welche Pflicht-Tags erlaubt sind; Nutzer wählen beim Anlegen nur noch aus den freigegebenen Optionen.

Was sind Cluster Policies?

Ein Databricks-Cluster ist eine Gruppe virtueller Server, auf denen Datenverarbeitung läuft (etwa das Verarbeiten großer Tabellen oder das Trainieren eines Machine-Learning-Modells). Ohne Regeln kann jeder berechtigte Nutzer im Databricks-Workspace einen solchen Cluster in beliebiger Größe, mit beliebigen VM-Typen und beliebiger Software-Version anlegen. Genau das schränken Cluster Policies ein: Sie sind Vorlagen, die vor der Cluster-Erzeugung greifen. Was die Policy nicht erlaubt, kann der Nutzer im Bedienfenster oder per Schnittstelle gar nicht erst auswählen.

Eine Policy wird als JSON-Definition gespeichert und beschreibt pro Konfigurationsfeld, welche Werte zulässig sind. Für jedes Feld ist einer von mehreren Regel-Typen möglich: fixed erzwingt einen festen Wert, allowlist gibt eine Auswahl-Liste vor, blocklist schließt Werte aus, regex prüft ein Muster (etwa erlaubte Instanz-Namen), range begrenzt Zahlen zwischen Minimum und Maximum, unlimited lässt das Feld frei. Typische Felder sind der VM-Instanztyp, die minimale und maximale Zahl der Worker (also der virtuellen Server neben dem Steuer-Knoten), die Databricks-Runtime-Version (das vorbereitete Software-Paket auf dem Cluster), die Auto-Termination-Zeit (nach wie vielen Minuten Leerlauf der Cluster automatisch stoppt), die Photon-Nutzung (Databricks' beschleunigte Abfrage-Engine), der Cluster-Access-Mode (Single-User, Shared, No Isolation) und Pflicht-Tags wie Kostenstelle und Owner.

Cluster Policies existieren aus drei Gründen. Erstens Kosten-Kontrolle: Ein einzelner Cluster mit 100 Workern über ein Wochenende kann eine fünfstellige Databricks-Rechnung erzeugen; eine Range-Regel auf num_workers schließt das aus. Zweitens Compliance: Wenn nur bestimmte Runtime-Versionen supportet sind (etwa Long-Term-Support-Versionen für produktive Jobs) oder wenn Pflicht-Tags für Cost-Center-Reporting nötig sind, erzwingt die Policy das an der Quelle. Drittens konsistente Betriebs-Standards: Auto-Termination wird zur Pflicht, Init-Scripts (Start-Skripte, die auf jedem Cluster-Knoten laufen) werden auf freigegebene Pfade begrenzt, unsichere Netzwerkoptionen werden geblockt.

Cluster Policies werden Nutzern über Compute-Berechtigungen zugewiesen. CAN_USE erlaubt das Anlegen von Clustern nach der Policy, CAN_MANAGE erlaubt zusätzlich die Bearbeitung der Policy selbst. In der Regel werden diese Rechte an Gruppen aus dem Identity Provider (Entra ID, Okta, Google Workspace) vergeben, nicht an einzelne Nutzer. Wer die Standard-Berechtigung Unrestricted Cluster Creation nicht (mehr) hat, kann Cluster ausschließlich über die Policies anlegen, für die er über CAN_USE freigeschaltet ist. Cluster Policies gelten für All-Purpose-Cluster (interaktive Notebooks) und Job-Cluster (kurzlebige Cluster pro Job) im klassischen Compute-Modell. Für SQL Warehouses existiert eine getrennte, konzeptionell ähnliche Warehouse-Policy-Schicht.

Abgrenzung zu Cluster Configuration, Compute-Berechtigungen, Job-Clustern und Serverless

Cluster Policies werden häufig mit verwandten Begriffen vermischt, weil in der Databricks-Oberfläche Vorlage, Instanz, Berechtigung und Serverless-Steuerung im selben Menü liegen.

Begriff	Was er bezeichnet	Verhältnis zur Cluster Policy
Cluster Configuration	konkrete Cluster-Instanz mit gewählten Werten	Instanz einer Policy; die Policy ist die Vorlage, die Configuration ist der laufende Cluster, der sie erfüllt
Compute-Berechtigung (RBAC)	wer eine Policy nutzen oder verwalten darf (CAN_USE, CAN_MANAGE)	steuert Zugang zur Policy; die Policy selbst steuert die erlaubten Cluster-Werte
Job-Cluster	transienter Cluster, der an einen Job gebunden ist und danach beendet wird	Job-Cluster können ebenfalls einer Policy unterliegen; der Unterschied liegt in der Lebensdauer, nicht in der Governance-Schicht
Serverless SQL Warehouse	verwalteter Pool, in dem Databricks Instanzen bereitstellt	Cluster Policies greifen nicht; Steuerung läuft über Warehouse-Policies, Serverless-Budget-Policies und Workspace-Berechtigungen
Init-Script-Allowlist	erlaubte Pfade für Start-Skripte auf Cluster-Knoten	ist ein Regel-Feld innerhalb einer Cluster Policy, keine eigene Schicht

Cluster Policy und Cluster Configuration sind das häufigste Verwechslungspaar. Die Policy ist ein Admin-Objekt, das nichts kostet und keine Ressourcen belegt; die Configuration ist die konkrete Cluster-Instanz, die auf Cloud-Infrastruktur läuft und [DBUs](/insights/glossar/dbu/) sowie Cloud-Kosten erzeugt.

Cluster Policy und Compute-Berechtigung liegen auf unterschiedlichen Ebenen. Die Berechtigung ist eine Zugriffsentscheidung im Sinne einer [rollenbasierten Zugriffskontrolle](/insights/glossar/rbac/): Sie beantwortet, ob eine Gruppe die Policy überhaupt nutzen darf. Die Policy selbst beantwortet, welche Cluster-Werte innerhalb dieser Nutzung erlaubt sind. Beide Schichten wirken zusammen.

Job-Cluster sind kurzlebige Cluster, die pro Job gestartet und nach Job-Ende beendet werden. Sie unterliegen denselben Cluster-Policy-Feldern wie All-Purpose-Cluster, tragen aber im Betrieb typischerweise eine eigene Policy (etwa job-standard), weil sie andere Auto-Termination- und Größen-Profile haben.

Für [Serverless SQL Warehouses](/insights/glossar/sql-warehouses/) und [Serverless-Compute](/insights/glossar/serverless-computing/) greifen Cluster Policies nicht. Bei Serverless-Compute-Modellen verwaltet Databricks die zugrundeliegenden virtuellen Server selbst; die klassischen Policy-Felder (VM-Instanztyp, Worker-Zahl, Auto-Termination) sind nicht mehr sichtbar. Die Kontrolle verschiebt sich in Warehouse-Policies (Größe des Warehouses, Cluster-Skalierung, Auto-Stop), Serverless-Budget-Policies und Workspace-Berechtigungen.

Beispiel: Drei Policies für ein Analytics- und ML-Team

Ein Plattform-Team richtet in einem Analytics-Workspace drei Policies ein und entzieht allen Nutzern die Standard-Berechtigung Unrestricted Cluster Creation. Jede Policy adressiert ein Workload-Profil.

job-small deckt nächtliche Batch-Jobs ab. Die Policy fixiert die Runtime auf die aktuelle LTS-Version, aktiviert [Photon](/insights/glossar/photon/), begrenzt den Instanztyp auf i3.xlarge bis i3.4xlarge, setzt num_workers per Range auf 1 bis 4, erzwingt Auto-Termination nach 10 Minuten und macht das Tag cost_center zur Pflicht. Die Data-Engineering-Gruppe erhält CAN_USE.

analytics-shared deckt interaktive Notebooks im Team ab. Access Mode ist auf Shared fixiert, damit [Unity Catalog](/insights/glossar/unity-catalog/) mit Zeilen- und Spaltenfiltern greifen kann. Runtime ist LTS, num_workers per Range 2 bis 6, Auto-Termination 30 Minuten, Pflicht-Tag cost_center. Die Analytics-Gruppe erhält CAN_USE.

ml-training-gpu deckt Trainings-Läufe ab. Der Instanztyp ist per Allowlist auf GPU-Instanzen (g5.2xlarge, g5.4xlarge) begrenzt, num_workers per Range 0 bis 8, Auto-Termination 2 Stunden, Pflicht-Tag cost_center plus experiment_id. Die ML-Gruppe erhält CAN_USE.

Im Ergebnis kann kein Nutzer im UI oder per API einen Cluster außerhalb dieser drei Profile anlegen. Ein Runaway-Cluster mit 50 Workern über das Wochenende ist strukturell ausgeschlossen. Das Cost-Reporting über die Databricks-System-Tables findet die Pflicht-Tags konsistent auf jedem Cluster; die Zuordnung zu Kostenstellen und Experimenten ist ohne manuelle Nacharbeit möglich.