Databricks Secrets: Scopes, Key Vault & Unity Catalog im Vergleich

Wenn Sie mit Databricks arbeiten, kennen Sie dieses Szenario: Eine neue Pipeline muss mit SAP sprechen, und SAP verlangt dafür ein Passwort. Irgendjemand im Plattform-Team muss entscheiden, wo dieses Passwort landet: in einem Databricks-backed Secret Scope, einem Azure Key Vault-backed Scope oder dem neueren Unity Catalog Secret, das zwar seit einem Release existiert, an das sich aber noch niemand herangetraut hat. Für welche Variante die Wahl auch fällt, sie wird zur Blaupause, die die nächsten fünf Pipelines kopieren.

Wir haben bereits darüber geschrieben, wie man Unity-Catalog-Berechtigungen mit Terraform und Databricks-Bundles konsistent hält, und darüber, wie YAML Anchors das Copy-Paste von Grant-Blöcken über Bronze, Silber und Gold hinweg beendet. Secrets sind Teil desselben Governance-Modells, bekommen aber kaum Aufmerksamkeit, dabei braucht jede Pipeline ein Credential, um überhaupt laufen zu können.

Aktuell bietet Databricks drei Wege, ein Secret zu speichern. Der dritte behebt fast alles, was an den ersten beiden hakt, ist aber noch kein vollwertiger Ersatz.

Drei Wege, ein Secret zu speichern

Ein Databricks-backed Secret Scope speichert Key-Value-Paare in einem verschlüsselten Store, den Databricks selbst besitzt und verwaltet: Erstellung, Befüllung und Berechtigungsvergabe passieren vollständig innerhalb von Databricks, über die CLI oder die Secrets API.

Ein Azure Key Vault-backed Secret Scope ist ein reines Lesefenster in einen bestehenden Key Vault. Databricks speichert den Wert nie selbst, sondern liest ihn live aus Azure, sodass Rotation, Versionierung und das Secret-Material selbst genau dort bleiben, wo Ihre Key-Vault-Governance sie ohnehin schon regelt.

Ein Unity Catalog Secret ist keins von beidem: Es handelt sich um ein securable object mit einem dreistufigen Namen, catalog.schema.secret, gesteuert über gewöhnliche Unity-Catalog-Privilegien, die es von Catalog und Schema erbt, genau wie das SELECT-Grant einer Tabelle. Für Secrets liefert der Catalog Explorer eine echte UI zum Erstellen, Vergeben und Auflisten, ganz ohne CLI.

Auf den ersten beiden Scope-Typen läuft der Großteil der bestehenden Umgebungen, und genau daran zeigt sich auch, warum Teams sie irgendwann hinter sich lassen.

Klassische Scopes: Eine ACL für den gesamten Scope

Sowohl der Databricks-backed als auch der Key-Vault-backed Scope-Typ teilen dieselbe Einschränkung: ACLs sitzen auf dem Scope, nicht auf dem einzelnen Secret darin. Databricks selbst empfiehlt, einen Scope an eine Rolle oder eine Anwendung auszurichten statt an einzelne Personen, etwa einen Scope pro Quellsystem, damit der Zugriff grob genug bleibt, um handhabbar zu sein. Die direkte Konsequenz: Die Anzahl der Scopes richtet sich jetzt nach der Granularität Ihrer Berechtigungen, nicht nach der Anzahl Ihrer Credentials. Ein Workspace ist bei 1.000 Scopes gedeckelt, ein Soft Limit, das sich über den Account-Ansprechpartner anheben lässt. Jeder weitere Scope braucht eigene Grants, pro Umgebung wiederholt, jedes einzeln von Hand per databricks secrets put-acl my-scope data-engineers WRITE. Einen Bulk-Grant gibt es nicht, ebenso wenig etwas wie eine Desired-State-Datei, gegen die man abgleichen könnte.

Die Key-Vault-backed-Variante bringt eine zusätzliche Governance-Ebene mit: Rotation, Versionierung und Access Logging übernehmen einfach den Prozess, der schon für Ihre anderen Vaults gilt, was ein echter Vorteil ist, sofern dieser Prozess solide ist. Trotzdem überraschen drei Dinge Teams immer wieder. Key-Vault-backed Scopes unterstützen ausschließlich das ältere Access-Policy-Modell des Vaults, kein Azure RBAC, und wenn Ihre Landing Zone auf RBAC standardisiert ist, was inzwischen für die meisten gilt, müssen Sie den Vault erst zurückdrehen, bevor Databricks ihn überhaupt anfasst. Die ACL bleibt Scope-basiert, und ein Scope bildet immer den gesamten Vault ab: Wer einem Team Zugriff gewährt, gewährt ihm damit automatisch jedes Secret darin (der dokumentierte Workaround: ein eigener Vault pro Abgrenzung). Und einen solchen Scope anzulegen heißt, die URL https://<workspace-url>#secrets/createScope aufzurufen, auf die nirgendwo in der UI verlinkt wird, und dann DNS-Namen sowie Resource ID von Hand aus dem Azure-Portal abzutippen. Geht dabei etwas schief, sagt die Fehlermeldung, Authorization_RequestDenied, so gut wie nichts darüber aus, was zu beheben ist.

Für ein Team und eine Handvoll Admins ist das durchaus vertretbar. Sobald Secrets-Management aber über mehrere Teams und drei Umgebungen hinweg läuft, funktioniert das Modell nicht mehr, weil jede Lücke darauf angewiesen ist, dass sich noch jemand an sie erinnert.

Was Unity Catalog Secrets tatsächlich beheben

GRANT CREATE SECRET, USE SCHEMA ON SCHEMA main.sap TO `data-engineers`;
GRANT READ SECRET ON SECRET main.sap.bw_password TO `job-runner-sp`;

Sehen Sie sich die Aufzeichnung unseres Webinars an: "Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

Wie man tatsächlich zwischen Databricks Secret Scopes, Key Vault und Unity Catalog Secrets entscheidet

Für jeden neuen Workload, der sie nutzen kann, sind Unity Catalog Secrets die richtige Wahl: Berechtigungen pro Secret, ein Audit Trail und eine echte UI. Es gibt keinen Grund, Scope-basierte ACLs zu erben, wenn die Plattform alle drei Modelle zur Auswahl stellt. Die Ausnahmen sind klar umrissen: Alles, was ein SQL Warehouse, ein Init Script oder eine Runtime älter als 17.3 LTS betrifft, bleibt vorerst bei einem klassischen Scope, nicht als Übergangslösung, sondern weil UC Secrets von diesem Compute aus schlicht nicht erreichbar sind. Secrets, die auch andere Azure-Dienste lesen müssen, gehören in Key-Vault-backed Scopes. Die Access-Policy-Ausnahme und die Vault-Zersplitterung, die dabei je Abgrenzung entsteht, sollte man von vornherein einplanen. Die meisten realen Umgebungen werden für eine Weile alle drei Modelle parallel betreiben. Migration geschieht pro Workload, nicht auf einen Schlag. Und wer bereits über Databricks Bundles deployt, deklariert Scope oder Secret dort, nicht über die CLI.

Databricks Secrets bieten APIs und grafische Benutzeroberflächen für die Verwaltung von Secrets, die vollständig in die Governance von Unity Catalog integriert sind.

Databricks Secrets werden innerhalb eines Unity-Catalog-Schemas gespeichert und unterliegen einheitlichen Governance-Mechanismen für eine detaillierte Berechtigungsverwaltung und Zugriffskontrolle.

Bundles haben die deklarative Lücke geschlossen - größtenteils

Vor einem Jahr hätte an dieser Stelle noch gestanden, dass Databricks Bundles Secrets überhaupt nicht abbilden. Das stimmt inzwischen nicht mehr: Seit CLI v0.252.0 (Mai 2025) unterstützt databricks.yml eine secret_scope-Ressource (backend_type, keyvault_metadata für die Key-Vault-Variante, ein permissions-Block) sowie eine secret-Ressource für Unity Catalog Secrets mit einem grants-Block, in derselben Form wie die Catalog- und Schema-Grants an anderer Stelle im Bundle. Wer bereits über Bundles deployt, sollte Secrets dort deklarieren, nicht über die CLI.

Damit ist die Prozess-Lücke geschlossen, nicht die Berechtigungsmodell-Lücke. Ein permissions:-Block an einem secret_scope vergibt weiterhin MANAGE, WRITE oder READ auf den gesamten Scope, genau wie put-acl es immer schon tat. Das in YAML zu deklarieren, bringt einen Diff und einen PR-Review vor PROD, aber der Scope bleibt Scope-weit, und ein Key-Vault-backed Scope bleibt vault-weit. Ein bestehendes Setup ins Bundle zu bringen, verschafft Review und Konsistenz über DEV, QA und PROD; den Workload auf ein Unity Catalog Secret zu migrieren, verschafft tatsächliche Granularität pro Secret. Beides hat seine Berechtigung, nur lösen beide Ansätze unterschiedliche Probleme.

Secrets in Databricks verwalten: Unser Fazit

Databricks wird nicht auf Dauer drei Speichermodelle für ein und dasselbe Credential vorhalten. Die Richtung, in die die Plattform geht, ist eindeutig: Unity Catalog Secrets, mit Berechtigungen pro Secret, einer echten UI und einem Audit Trail inklusive. Die heutigen Lücken bei Runtime und SQL Warehouse werden sich weiter schließen. Die Entscheidung, die jetzt ansteht, ist nicht „welches Modell für immer", sondern welche Workloads schon heute umziehen können und welche bis auf Weiteres auf einem klassischen Scope festsitzen, bis die Plattform nachzieht.

Das schwierigere Problem liegt in der Lücke zwischen einer Plattform, die von Anfang an über Bundles deployt wurde, und einer, die zunächst jahrelang von Hand angelegte Scopes und ACLs angesammelt hat. Diese Historie aufzuarbeiten, ohne den Nachweis zu verlieren, wer wann was vergeben hat, und gleichzeitig die Azure-seitige Hälfte eines Key-Vault-backed Scopes zu koordinieren, die kein Databricks-Tool erreicht: Für genau diese Aufgabe wird ein dediziertes, organisationsspezifisches Databricks Management Toolkit benötigt, aufgebaut auf Bundles, Databricks APIs und CI/CD Pipelines.

Wenn Ihr Secrets-Setup älter ist als Ihr Umstieg auf Bundles oder sich gleichzeitig über Scopes, Key Vault und Unity Catalog erstreckt, ohne dass klar ist, welches Team worauf Zugriff hat, dann melden Sie sich: Wir gehen das gerne gemeinsam mit Ihnen durch.