Die Integration besteht aus drei Bausteinen, die du bereits selbst kontrollierst: einem Databricks-Service-Principal, der Databricks CLI, die über einen Environment-Blueprint installiert wird, und (optional) dem Databricks Skills Plugin. Databricks, die Workspaces und sämtliche Berechtigungen bleiben in deinem Account.
Authentifizierungsmethode für Devin wählen
Beginne mit Option A, wenn Devin schon heute mit Databricks arbeiten soll. Du kannst später zu Option B wechseln, ohne den Service-Principal oder dessen Berechtigungen anzupassen.
Warum Devin mit Databricks verbinden?
- Devin arbeitet dort, wo Ihre Datenplattform lebt. Die meiste Arbeit in Databricks besteht nicht nur darin, Notebooks in einem Repo zu bearbeiten. Es geht darum zu prüfen, warum ein Job fehlgeschlagen ist, das Schema einer Tabelle zu lesen, eine Query gegen ein Warehouse auszuführen oder eine Pipeline zu untersuchen. Mit der CLI werden daraus Aufgaben, die Devin selbst erledigen kann, statt Fragen an einen Menschen.
- Eine einzige prüfbare Identität. Devin agiert als ein von Ihnen erstellter Service-Principal, sodass jeder API call, jede Query und jeder Job-Lauf in den Databricks-Audit-Logs und in der Unity-Catalog-Lineage unter dieser Identität erscheint – und nicht unter dem persönlichen Token eines Entwicklers.
- Unity Catalog entscheidet, worauf Devin zugreifen darf. OAuth entscheidet, ob Devin sich authentifizieren kann. Unity-Catalog-Grants und Workspace-Berechtigungen entscheiden, was gelesen oder geändert werden darf. Sie können in der Produktion schreibgeschützt starten, Devin einen Sandbox-Catalog zum Entwickeln geben und den Geltungsbereich erst erweitern, wenn Sie gesehen haben, wie Devin sich verhält.
- Ein Weg ganz ohne gespeichertes Secret. Mit OIDC-Token-Föderation (Option B) speichert Devin zu keinem Zeitpunkt ein Databricks-Token oder ein Client Secret. Jede Sitzung tauscht ein 60 Sekunden gültiges Devin-Identitäts-Token gegen ein kurzlebiges Databricks-OAuth-Token.
Übersicht
Das Databricks Skills Plugin ist eine fünfte, optionale Schicht: Es vermittelt Devin zusätzlich zur CLI Databricks-spezifische Workflows (Asset Bundles, Jobs, SQL, Unity Catalog).
Voraussetzungen
- Ein Databricks-Konto auf AWS, Azure oder GCP mit Account-Admin-Zugriff für die Person, die das Setup durchführt. Das Erstellen von Service-Principals, OAuth-Secrets und Federation-Richtlinien erfolgt auf Account-Ebene.
- Ein oder mehrere Workspaces mit aktiviertem Unity Catalog. Diese Anleitung geht davon aus, dass Unity Catalog die Daten verwaltet, auf die Devin zugreifen soll.
- Die Databricks CLI auf der Maschine des Admins für die folgenden Befehle auf Account-Ebene. Dafür genügt jede aktuelle Version. Devins eigene Installation erfolgt separat in Schritt 2.
- Berechtigung zum Bearbeiten des Environment-Blueprints Ihrer Organisation (Settings > Environment > Blueprints).
- Für Option A: Berechtigung zum Hinzufügen von Devin Secrets.
- Für Option B: Ihre Devin-OIDC-Issuer-URL und Organization ID. Schritt 2 zeigt, wie Sie beides aus einem Token innerhalb einer Devin-Sitzung auslesen. Hintergrundinformationen finden Sie unter Cloud Authentication with OIDC.
- Devin-Sitzungen müssen Ihren Workspace-Host über HTTPS erreichen können (zum Beispiel
https://dbc-xxxx.cloud.databricks.com,https://adb-xxxx.azuredatabricks.netoderhttps://xxxx.gcp.databricks.com). Wenn Ihre Organisation eine Devin-Netzwerkrichtlinie verwendet, fügen Sie den Workspace-Host hinzu sowie – für Befehle auf Account-Ebene – den Account-Host (accounts.cloud.databricks.com,accounts.azuredatabricks.netoderaccounts.gcp.databricks.com). - Für Option B muss Databricks Devins JWKS unter
https://<your-devin-host>/.well-known/jwks.jsonüber das öffentliche Internet abrufen können, um Token-Signaturen zu verifizieren.
Schritt 1: Service-Principal erstellen
Weisen Sie den Service-Principal anschließend jedem Workspace zu, den Devin verwenden soll. Das können Sie in der Account-Konsole unter User management → Service principals oder über die CLI erledigen:
USER, nicht ADMIN. Devin benötigt keine Workspace-Adminrechte.
Schritt 2: Devin mit dem Service-Principal verbinden
- Option A: OAuth Client Secret. Standardmäßiges OAuth M2M: Der Service-Principal erhält ein Client Secret, das Sie in Devin Secrets hinterlegen. Der schnellste Einstieg.
- Option B: OIDC-Token-Föderation. Jede Devin-Sitzung kann ein kurzlebiges, von Devin signiertes OpenID-Connect-Token ausstellen. Die Token-Föderation von Databricks ermöglicht es dem Service-Principal, diesem Issuer zu vertrauen, sodass Devin sein eigenes Identitätstoken gegen ein Databricks-OAuth-Token eintauscht. Dabei wird nie ein Databricks Secret erstellt oder gespeichert – deshalb empfiehlt Databricks diese Variante ausdrücklich für automatisierte Workloads.
Option A: OAuth Client Secret
1. Ein OAuth-Secret generieren
sql, jobs und unity-catalog. Wählen Sie nicht alle Geltungsbereiche aus.
2. Die Devin Secrets hinzufügen
Die CLI wählt OAuth M2M automatisch, sobald eine Client ID und ein Client Secret vorhanden sind;
DATABRICKS_AUTH_TYPE ist daher nicht erforderlich. Setzen Sie den Wert nur dann auf oauth-m2m, wenn Sie alle anderen Methoden explizit ausschließen möchten.
Secrets werden zu Beginn jeder neuen Sitzung als Umgebungsvariablen bereitgestellt, sodass die CLI keine Profildatei benötigt. Ein rotiertes Secret greift ohne Rebuild ab der nächsten neuen Sitzung.
3. Blueprint hinzufügen
initialize nicht in eine Datei; alles, was dort geschrieben wird, landet fest im Snapshot.
4. Snapshot erstellen
Option B: OIDC-Token-Föderation
iss, sub, aud), und eine Föderationsrichtlinie am Service-Principal weist Databricks an, diesen zu vertrauen. Der Blueprint installiert die devin-oidc-CLI, kapselt databricks so, dass jeder Aufruf ein frisches Token mitführt, und legt ein Profil an, das auf Ihren Service-Principal verweist. Anschließend lesen Sie die Claims des Tokens aus einer Sitzung aus und erstellen eine passende Richtlinie.
1. Blueprint hinzufügen
Das Profil enthält kein Secret und kann daher gefahrlos während
initialize geschrieben werden. Wenn Sie von Option A wechseln, entfernen Sie das Devin Secret DATABRICKS_CLIENT_SECRET, sobald die untenstehende Richtlinie eingerichtet ist, damit die CLI nicht zwei Anmeldedaten vorfindet.
2. Snapshot erstellen
3. Die Föderationsrichtlinie erstellen
1
Issuer und Subject auslesen
Starten Sie eine neue Devin-Sitzung und lassen Sie Folgendes ausführen. Ausgegeben werden ausschließlich die Identitäts-Claims des Tokens, niemals das Token selbst.Erwartete Form:Bei Enterprise-Deployments ist
iss Ihre eigene Devin-URL (zum Beispiel https://yourcompany.devinenterprise.com). Übernehmen Sie iss und sub exakt so, wie sie ausgegeben werden. Fügen Sie das rohe Token nicht in Tickets oder Dokumente ein; es ist für die nächsten 60 Sekunden ein gültiges Bearer-Credential.2
Die Föderationsrichtlinie schreiben
Speichern Sie Folgendes als Alle drei Felder werden exakt abgeglichen:
devin-federation-policy.json und setzen Sie dabei die Werte aus dem vorherigen Schritt ein:issuermuss demissdes Tokens entsprechen, einschließlich Schema und ohne abschließenden Schrägstrich.audiencesmuss die Audience enthalten, die Devin anfordert (in dieser Anleitungdatabricks).subjectmuss demsubdes Tokens entsprechen. Standardmäßig ist das Subject Ihre Organisations-ID, sodass sich jede Sitzung der Organisation als dieser Principal authentifizieren kann. Für Databricks ist das die richtige Granularität, da Föderationsrichtlinien das Subject als wörtliche Zeichenkette abgleichen. Sitzungsbezogene Claims wiedevin_idändern sich bei jeder Sitzung und lassen sich mit einer statischen Richtlinie nicht abgleichen.
subject_claim, jwks_uri und jwks_json leer. Databricks verwendet standardmäßig den sub-Claim und ermittelt die JWKS über /.well-known/openid-configuration des Issuers.3
Die Richtlinie an den Service-Principal anhängen
Rebuilds und Versions-Pinning
setup-devin-oidc@main folgen ihren Upstream-main-Branches, sodass ein vollständiger Build neue Releases übernimmt; ein differenzieller Build überspringt initialize und behält die bereits im Snapshot vorhandenen Versionen bei, bis sich der Blueprint ändert. Wenn Sie reproduzierbare Builds benötigen, laden Sie den Installer nicht von main, sondern von einem Release-Tag (zum Beispiel .../databricks/setup-cli/v1.17.0/install.sh) – damit wird genau diese CLI-Version installiert – und pinnen Sie die Action an einen Commit-SHA an (setup-devin-oidc@<sha>).
Schritt 3: Berechtigungen erteilen
Berechtigungsprofile
Grant-Statements adressieren den Service-Principal über seine Application-ID:
devin-agents hinzu und erteilen Sie die Berechtigungen stattdessen der Gruppe.
Step 4: Databricks Skills Plugin installieren (optional)
- Öffne Customize → Plugins und wähle Add plugin → From repository.
- Gib das Repository
databricks/databricks-agent-skillsund das Unterverzeichnisplugins/databricks/claudean. Das Plugin-Manifest liegt in diesem Unterordner – bei einer Installation aus dem Root-Verzeichnis erscheint daher die Meldung No plugin manifest found. - Installiere im Geltungsbereich Organization, falls du in Step 2 ein Organization Blueprint verwendet hast. Hast du ein Repository Blueprint verwendet, deklariere das Plugin stattdessen in der
.devin/config.jsondes jeweiligen Repositorys (siehe Vererbung und Ebenen), damit nur Sitzungen mit der CLI auch die Skills erhalten. - Pinne das Plugin an einen Commit an, sobald es funktioniert, damit Änderungen aus dem Upstream nicht ungeprüft in deinen Sitzungen landen.
databricks auth login auszuführen, um ein Profil einzurichten. Dieser interaktive Browser-Ablauf lässt sich in einer unbeaufsichtigten Devin-Sitzung nicht abschließen und ist hier auch nicht nötig: Der knowledge-Eintrag aus Step 2 teilt Devin mit, dass die CLI bereits authentifiziert ist.
Schritt 5: Überprüfen
current-user me sollte den Service-Principal zurückgeben, wobei userName seiner Anwendungs-ID entspricht. So prüfen Sie, welche Authentifizierungsmethode die CLI gewählt hat:
oauth-m2m gemeldet, bei Option B env-oidc.
Eine erfolgreiche Authentifizierung bedeutet nicht, dass Devin auch auf Ihre Daten zugreifen kann. Stellen Sie sicher, dass die Berechtigungen aus Schritt 3 greifen:
<catalog-name> durch einen Katalog, den du in Schritt 3 freigegeben hast (die Beispiele dort verwenden analytics). Bitte Devin anschließend, eine kleine schreibgeschützte Abfrage auf einem Warehouse auszuführen, für das Devin CAN USE hat, und – falls du ein Build-Profil eingerichtet hast – eine Tabelle in devin_dev zu erstellen und wieder zu löschen. Eine Abfrage auf eine Produktionstabelle, für die Devin kein SELECT hat, sollte fehlschlagen; genau dieser Fehler zeigt, dass die Berechtigungsgrenze greift.

