Sicher Snowflake von VS Code im Browser verwenden

29.03.2024

Stijn De Haes

Eine Hauptaktivität unserer Benutzer besteht darin, dbt innerhalb der IDE-Umgebung zu nutzen.

Wir haben jedoch Herausforderungen bei der Integration von Snowflake SSO mit dbt in unseren Conveyor IDEs festgestellt.

Unsere IDEs basieren auf VS Code im Browser, genauer gesagt verwenden wir das code-server Projekt. Der Ansatz, den wir verwendet haben, kann auf jede Konfiguration verallgemeinert werden, die VS Code im Browser verwendet. Daher wollte ich den Bauplan unserer Lösung in diesem Artikel teilen.

Securely use Snowflake from VS Code in the browser


Das Problem bei der Verwendung von VsCode, dbt und Snowflake SSO

Wie bereits erwähnt, ist die Integration von VS Code im Browser, dbt und Snowflake SSO derzeit nicht einfach.
Die Verwendung von SSO für Snowflake funktioniert großartig, es sei denn, man möchte sich über VS Code im Browser anmelden. Zum Beispiel funktioniert die externalbrowser Authentifizierung mit dbt so:

  • Ein Benutzer verwendet dbt run, was den Snowflake-Authentifizierungsfluss startet

  • Ein Webbrowser wird geöffnet, damit der Benutzer sich authentifizieren kann

  • Der Benutzer authentifiziert sich über SSO

  • Snowflake sendet ein Authentifizierungstoken an localhost:**** (dies ist ein zufälliger Port), das dbt auffangen muss

  • Aber es passiert nichts, da unser VS Code im Browser nicht auf localhost läuft (sondern auf Kubernetes, auf einer Domain wie http://app.conveyordata.com)

Example of the non-working flow

Das Problem dabei ist, dass unser aktuelles VS Code in der Cloud läuft und nicht auf unserem Laptop. Daher läuft dbt nicht auf localhost und die Anmeldeinformationen können nie an dbt übergeben werden. Es gibt auch keine Möglichkeit, diesen Callback auf etwas anderes als localhost und einen zufälligen Port zu ändern.

Der Port kann jedoch gewählt werden, sodass wir Software schreiben könnten, die auf dem Rechner der Benutzer läuft und nicht auf VS Code im Browser. Dies widerspricht jedoch dem Zweck der Verwendung von Cloud-IDEs. Die Benutzer müssen ihren lokalen Computer erneut konfigurieren.

Eine Alternative besteht darin, eine der vielen Sicherheitsintegrationen zu verwenden, die in Snowflake verfügbar sind und in dbt unterstützt werden. Wir haben uns entschieden, die OAUTH-Integration von Snowflake zu verwenden.

Diese Implementierung war ein dreistufiger Prozess:

  • Wir werden die benutzerdefinierte OAUTH-Sicherheitsintegration in Snowflake konfigurieren

  • Dann werden wir dbt konfigurieren

  • Zuletzt werde ich Ihnen den Bauplan geben, wie man eine CLI/API-Kombination erstellt, um Anmeldeinformationen von Snowflake SSO an dbt zu übergeben

Verwendung der benutzerdefinierten Snowflake OAUTH-Sicherheitsintegration


Um unser Problem zu lösen, können wir die benutzerdefinierte OAUTH-Sicherheitsintegration verwenden, die in Snowflake verfügbar ist. Sie können sie wie folgt aktivieren:


CREATE SECURITY INTEGRATION VS_CODE_BROWSER
TYPE = OAUTH
ENABLED = TRUE
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = 'PUBLIC'
OAUTH_REDIRECT_URI = 'https://UNSER_DOMAIN/snowflake-callback'
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 86400;

Es gibt ein paar Dinge, die hier zu beachten sind:

  • TYPE = OAUTH und OAUTH_CLIENT = CUSTOM bedeutet, dass wir eine OAUTH-konforme Sicherheitsintegration vom Typ benutzerdefiniert aktivieren. Benutzerdefinierte OAUTH-Integrationen werden für benutzerdefinierte Integrationen verwendet, Sie können Ihre eigene OAUTH-Integration mit Snowflake erstellen, indem Sie dies verwenden

  • OAUTH_CLIENT_TYPE = 'PUBLIC', gibt an, dass die OAUTH-Client-ID und das Geheimnis, die wir erhalten, öffentlich sichtbar sind. Dies schränkt die OAUTH-Flows ein, die wir verwenden können, damit das Teilen von Client-ID und Geheimnis öffentlich sicher ist. Zum Beispiel ist der Autorisierungscodefluss (den wir verwenden werden) weiterhin sicher, jedoch ist der Client-Anmeldeinformationenfluss nicht

  • OAUTH_REDIRECT_URI = 'https://UNSER_DOMAIN/snowflake-callback', in dem Autorisierungscodefluss, den wir verwenden werden, ist dies die URL, die den Autorisierungscode erhält. Dieser Code kann gegen ein Zugriffstoken eingetauscht werden. Das ist ein bisschen problematisch, da unsere Sicherheitsintegration nur einen Callback haben kann. Aber unsere VS Code IDEs sind nicht alle auf derselben URL gehostet

Integration mit dbt

Jetzt, da wir eine Sicherheitsintegration eingerichtet haben, müssen wir sie in dbt integrieren. Sie können dies mit den folgenden profiles.yml tun:

default:
target: vs_code_browser
outputs:
conveyor:
#Basis Snowflake-Setup
type: snowflake
account: YOUR_SNOWFLAKE_ACCOUNT
database: YOUR_DATABASE
warehouse: YOUR_WAREHOUSE
schema: YOUR_SCHEMA
threads: 1

#OAUTH-Setup
authenticator: oauth
oauth_client_id: OAUTH_CLIENT_ID
oauth_client_secret: OAUTH_CLIENT_SECRET
username: "{{ env_var("SNOWFLAKE_USERNAME") }}"
token: "{{ env_var("SNOWFLAKE_TOKEN") }}"

Die OAUTH_CLIENT_ID und OAUTH_CLIENT_SECRET müssen durch die Werte ersetzt werden, die wir aus unserer Sicherheitsintegration abrufen können:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('VS_CODE_BROWSER');
Nachdem dies erledigt ist, ist das dbt-Setup abgeschlossen, und wir können mit der nächsten Phase beginnen.

Abfragen des Snowflake-Benutzernamens und Tokens

Um dbt zum Laufen zu bringen, müssen wir die Umgebungsvariablen SNOWFLAKE_USERNAME und SNOWFLAKE_TOKEN festlegen, dies sind die Anmeldeinformationen, die dbt verwendet, um sich bei Snowflake zu authentifizieren.

Das ist der knifflige Teil! Um dies zum Laufen zu bringen, müssen wir sowohl eine CLI als auch eine API erstellen. Im nächsten Teil werde ich zeigen, wie Sie sie implementieren können.

The flow we are going to implement


1. Start des Authentifizierungsflusses mit CLI

Der Fluss beginnt mit einer CLI, die Sie in jeder Sprache implementieren können. Sie muss grundlegende Unterstützung für HTTP-Aufrufe haben, einen Browser öffnen und HTTP-Anfragen empfangen können. Wir verwenden intern Golang dafür, aber jede Sprache sollte funktionieren.

Um den Fluss zu starten, sollte der Benutzer der VS Code IDE Ihre CLI aufrufen, um den Authentifizierungsprozess zu starten, und die Parameter snowflake_client_id, snowflake_client_secret und snowflake_account übergeben.

Die CLI muss dann wissen, auf welchem HOST das VS Code im Browser derzeit läuft, und einen OAUTH-Fluss mit einem benutzerdefinierten Statusparameter starten. In diesem Statusparameter speichern wir eine base64-kodierte JSON-Nachricht, die Folgendes enthält:

  • Ein zufälliger String, zum Schutz gegen CSRF

  • Unser aktueller HOST, auf dem die VS Code-Umgebung läuft

  • Und ein Port. Dieser wird später von der API verwendet, um an unsere VS Code-Umgebung weiterzuleiten

Dann können wir mit dem Authentifizierungs-Flow zum Autorisierungspunkt von Snowflake beginnen. Wir müssen den Benutzer einen Browser mit der folgenden URL öffnen:

<snowflake_account_url>

Wir sollten die richtigen Abfrageparameter ausfüllen:

  • client_id, sollte die OAUTH_CLIENT_ID der Sicherheitsintegration sein

  • response_type, sollte code sein

  • redirect_uri, sollte die Umleitungs-URI sein, die wir in der Sicherheitsintegration angegeben haben

  • state, wie bereits erwähnt, eine base64-kodierte JSON-Nachricht, die einen zufälligen String, unseren aktuellen HOST und einen Port enthält

Jetzt müssen wir nur noch den Benutzer auffordern, einen Browser zu dieser URL zu öffnen.
Und wir müssen, dass die CLI ein HTTP-Server öffnet, um den Callback auf dem Port zu empfangen, den wir im Status gespeichert haben.

2. Benutzeranmeldung und Erfassung des Rückrufs

Nachdem der Benutzer die URL im Browser geöffnet hat, wird ihm ein Anmeldebildschirm angezeigt. Nach der Anmeldung werden sie an unsere API umgeleitet.

Erinnern Sie sich, dass wir nur eine Callback-URL haben können? Nun, das ist der Moment, in dem wir dieses Problem lösen werden. Wir werden eine API auf dieser Callback-URL hosten. Nach der Benutzeranmeldung werden sie mit einer GET-Anfrage an die Umleitungs-URL umgeleitet, die die folgenden Parameter enthält:

  • code, die kurzfristige Authentifizierung, die wir gegen ein echtes Zugriffs- und Aktualisierungstoken eintauschen können

  • state, dasselbe base64-kodierte JSON, das wir von der CLI übergeben haben

In der CLI können wir dann den Status überprüfen, um sicherzustellen, dass es derselbe Status ist, mit dem wir unseren Authentifizierungsfluss gestartet haben (dies ist ein Schutz gegen Cross-Site-Request-Forgery, mehr können Sie hier lesen), und wir können den Authentifizierungscode verwenden, um ihn gegen ein Zugriffstoken einzutauschen.

3. Festlegen der Anmeldeinformationen in der Umgebung

Jetzt, da wir den Authentifizierungscode haben, können wir ihn gegen ein echtes Zugriffstoken eintauschen.
Um dies zu tun, müssen wir den Token-Endpunkt verwenden. Ich werde nicht ins Detail gehen, da es sich um einen typischen OAUTH-Token-Endpunktaanruf handelt, und ziemlich standardisiert ist.
Nachdem Sie diesen Aufruf durchgeführt haben, erhalten Sie einen Body mit einigen Parametern. Wir sind an Folgendem interessiert:

  • refresh_token, dies ist das Token, das wir für dbt benötigen, wir müssen unsere CLI so einstellen, dass die Umgebungsvariable SNOWFLAKE_TOKEN auf diesen Wert gesetzt wird

  • username, dies ist der Benutzername des Benutzers, der sich gerade authentifiziert hat, unsere CLI muss die Umgebungsvariable SNOWFLAKE_USER auf diesen Wert setzen

Nachdem dies erledigt ist, können wir dbt run wie gewohnt verwenden!

Verbesserung der Benutzererfahrung

Es gibt einen zusätzlichen Schritt, den wir unternehmen können, um die Benutzererfahrung für unsere Benutzer zu verbessern. Bei Conveyor haben wir den dbt-conveyor-snowflake Adapter erstellt, es ist eine dünne Hülle um das dbt-snowflake, das automatisch unsere CLI aus den vorherigen Schritten aufruft, um einen Benutzer anzumelden. Auf diese Weise müssen die Benutzer nichts mehr manuell tun, um sich zu authentifizieren. Sie aktivieren diesen Adapter, indem Sie ihn installieren und die folgende profiles.yml verwenden:

default:
target: vs_code_browser
outputs:
conveyor:
#Basis Snowflake-Setup
type: conveyorsnowflake
account: YOUR_SNOWFLAKE_ACCOUNT
database: YOUR_DATABASE
warehouse: YOUR_WAREHOUSE
schema: YOUR_SCHEMA
threads: 1

#OAUTH-Setup
authenticator: oauth
oauth_client_id: OAUTH_CLIENT_ID
oauth_client_secret: OAUTH_CLIENT_SECRET


Die Hauptunterschiede sind:

  • Wir haben den Typ des Adapters von snowflake auf conveyorsnowflake gewechselt

  • Die Schlüssel token und username im Conveyor-Output wurden entfernt, da sie von unserem Adapter ausgefüllt werden

Zusammenfassung

In diesem Artikel haben wir gelernt, wie wir Snowflake SSO mit dbt innerhalb der VS Code IDE, die im Browser läuft, verwenden können. Wir haben gelernt:

  • Wie man die Sicherheitsintegration in Snowflake einrichtet

  • Wie man unser dbt profiles.yaml konfiguriert

  • Wie man eine CLI- und API-Kombination erstellt, die es der IDE ermöglicht, das Authentifizierungstoken von Snowflake abzurufen

  • Die Benutzererfahrung für unsere Benutzer zu erleichtern, indem wir einen benutzerdefinierten Snowflake-Adapter verwenden

Latest

When writing SQL isn't enough: debugging PostgreSQL in production
When writing SQL isn't enough: debugging PostgreSQL in production
When writing SQL isn't enough: debugging PostgreSQL in production

When writing SQL isn't enough: debugging PostgreSQL in production

SQL alone won’t fix broken data. Debugging pipelines requires context, lineage, and collaborationnot just queries.

Portable by design: Rethinking data platforms in the age of digital sovereignty
Portable by design: Rethinking data platforms in the age of digital sovereignty
Portable by design: Rethinking data platforms in the age of digital sovereignty

Portable by design: Rethinking data platforms in the age of digital sovereignty

Build a portable, EU-compliant data platform and avoid vendor lock-in—discover our cloud-neutral stack in this deep-dive blog.

Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten

Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten

Kann ein europäischer Cloud-Anbieter wie Ionos AWS oder Azure ersetzen? Wir testen es – und finden überraschende Vorteile in Bezug auf Kosten, Kontrolle und Unabhängigkeit.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Hinterlasse deine E-Mail-Adresse, um den Dataminded-Newsletter zu abonnieren.

Belgien

Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen


USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm,
Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland


© 2025 Dataminded. Alle Rechte vorbehalten.


Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen

USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm, Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland

© 2025 Dataminded. Alle Rechte vorbehalten.


Vismarkt 17, 3000 Leuven - HQ
Borsbeeksebrug 34, 2600 Antwerpen

USt-IdNr. DE.0667.976.246

Deutschland

Spaces Kennedydamm, Kaiserswerther Strasse 135, 40474 Düsseldorf, Deutschland

© 2025 Dataminded. Alle Rechte vorbehalten.