Databricks Apps: Autorisierung im Namen des Nutzers ist jetzt allgemein verfügbar

So funktioniert OBO in Databricks Apps

Mit Databricks Apps können Entwickler Daten- und KI-Anwendungen direkt auf der Databricks-Plattform erstellen und bereitstellen, von interaktiven Dashboards und operativen Werkzeugen bis hin zu eigenen KI-Agenten. Mit OBO handelt eine App, die unterstützte Databricks-APIs aufruft, als der angemeldete Nutzer. Unity Catalog setzt dann dessen bestehende Datenberechtigungen durch, einschließlich Zeilenfiltern und Spaltenmasken, während API-Scopes die Operationen begrenzen, die die App im Namen des Nutzers ausführen darf.

Für app-eigene Vorgänge, etwa das Lesen gemeinsamer Konfigurationen oder das Schreiben von Anwendungsmetriken, können Apps weiterhin ihren dedizierten Service Principal verwenden. Databricks beschreibt zwei sich ergänzende Modelle: die App-Autorisierung, die den Service Principal nutzt und sich für Vorgänge eignet, die für alle Nutzer dasselbe Ergebnis liefern sollen, sowie die Nutzerautorisierung, die greift, wenn die Berechtigungen des Nutzers einen Vorgang bestimmen sollen. Laut Unternehmen können die meisten Produktiv-Apps beide Modelle einsetzen und die Identität für jeden Anfragepfad gezielt wählen.

Als Beispiel nennt Databricks einen Vertriebsassistenten, der Fragen ausschließlich anhand der Konten und Felder beantwortet, auf die ein Vertriebsmitarbeiter zugreifen darf, ohne weitreichende SQL- oder Workspace-Administrationsfunktionen. Ein Regionalleiter sieht dann nur Konten seiner Region, ein nationaler Verantwortlicher alle Regionen, ohne dass diese Regeln im Code nachgebaut werden müssten. Wenn Administratoren Richtlinien in Unity Catalog ändern, spiegeln spätere App-Anfragen diese Änderungen wider.

Enge Scopes und das weitergeleitete Token

Databricks rät dazu, jeweils den engsten API-Scope zu verwenden, der zur Aufgabe passt. Für einen rein lesenden Analyse-Assistenten empfiehlt das Unternehmen sql:restricted-query statt des weiter gefassten Scopes sql. Der engere Scope erlaubt ausschließlich lesende SQL-Abfragen, sodass die App die Identität des Nutzers nicht als breit einsetzbare SQL-Betriebsberechtigung nutzen kann. Ruft eine App für den Nutzer zusätzlich Genie oder Unity Gateway auf, sollten laut Databricks nur die passenden Scopes angefordert werden, etwa genie oder ai-gateway, nicht aber files, model-serving oder vector-search, sofern die App diese nicht verwendet.

Scopes legen eine Obergrenze fest und gewähren keinen Zugriff. Der Nutzer muss weiterhin die Berechtigung für das Ziel-SQL-Warehouse und die erforderlichen Unity-Catalog-Privilegien besitzen. Entwickler können die Nutzerautorisierung in der Databricks-Oberfläche oder in einem Declarative Automation Bundle konfigurieren, und Nutzer werden beim ersten Öffnen einer nutzerautorisierten App aufgefordert, den angeforderten Scopes zuzustimmen.

Databricks leitet das aktuelle Zugriffstoken des Nutzers im HTTP-Header x-forwarded-access-token weiter. Die App liest es für die Anfrage aus, die einen Zugriff im Nutzerkontext benötigt, und übergibt es über access_token an den SQL-Connector. Das Beispiel des Unternehmens nutzt Flask und den Databricks SQL Connector für Python; dasselbe Prinzip gelte auch für Apps, die mit Databricks AppKit gebaut wurden. Das Token ist kurzlebig und gilt pro Anfrage. Die App sollte es bei jeder Anfrage neu auslesen und weder über Anfragen hinweg noch in einer Sitzung speichern.

Admin-Grenzen und getrennte Identitäten

Workspace-Administratoren können die Obergrenze für Scopes festlegen. Unter Settings > Development > Apps steht die Allowlist standardmäßig auf allen unterstützten APIs, lässt sich auf ausgewählte Scopes eingrenzen oder auf None setzen, um die Nutzerautorisierung zu deaktivieren. Entwickler können die Autorisierung einer App nicht über diese Grenze hinaus erweitern. Account-Administratoren können Scopes auch dann hinzufügen, wenn diese nicht in der Workspace-Allowlist stehen. Wird ein zugelassener Scope später entfernt, können laufende Apps, die ihn nutzen, weiterlaufen, sie lassen sich aber nicht starten, bereitstellen oder aktualisieren, bis der nicht mehr zugelassene Scope entfernt wurde.

Databricks empfiehlt zudem, app-eigene und nutzereigene Vorgänge im Code zu trennen, mit einem App-Client für Erstere und einem Nutzer-Client für Operationen unter Governance. Getrennte Abhängigkeiten, Namen und Tests helfen zu verhindern, dass ein App-Credential auf einem nutzerspezifischen Pfad verwendet oder ein Nutzertoken für Hintergrundaufgaben aufbewahrt wird. Benötigt eine Anfrage die Nutzerautorisierung und fehlt das weitergeleitete Token, sollte die App geschlossen scheitern (fail closed).

Was das für Entwickler und Administratoren bedeutet

Für Teams, die Daten-Apps und KI-Agenten auf Databricks entwickeln, bedeutet die allgemeine Verfügbarkeit: Bestehende Unity-Catalog-Regeln können bestimmen, was eine App für jeden Nutzer zurückgibt, statt in der Anwendungslogik neu geschrieben zu werden. Administratoren behalten die Kontrolle über die Scope-Allowlist des Workspace, während Entwickler die Mindest-Scopes festlegen, die ihre Apps benötigen.