Snowpark Container Services: Zusätzliche Hinweise zu Diensten¶

Optionen für die Konfiguration der Anmeldeinformationen¶

Snowflake empfiehlt, dass Anwendungscontainer bei der Ausführung von SQL die von Snowflake bereitgestellten Anmeldeinformationen verwenden, um sich bei Snowflake zu authentifizieren. Obwohl es möglich ist, andere Anmeldeinformationen zu verwenden, indem Sie eine Verbindung über eine Integration für den externen Zugriff (EAI) herstellen, behandelt die Verbindung über eine EAI den Service so, als würde er außerhalb von Snowflake ausgeführt und stellte eine Verbindung zu Snowflake über das Internet her.

You have three options to connect to Snowflake from a service container:

• Verwenden Sie die von Snowflake bereitgestellten Anmeldeinformationen für den Service: Snowflake liefert jedem Service Anmeldeinformationen, die als Serviceanmeldeinformationen bezeichnet werden. Ein Service verwendet diese Anmeldeinformationen, um sich als Servicebenutzer mit Snowflake zu verbinden.

• Verwenden Sie von Snowflake bereitgestellte Aufrufer-Anmeldeinformationen (Aufruferrechte): Wenn Sie Ihren Service mit Aufruferrechten konfigurieren, stellt Snowflake auch Anmeldeinformationen bereit, damit der Service sich als aufrufender Benutzer mit Snowflake verbinden kann.

• Use other credentials: In this case, you use an external access integration (EAI) that allows your service to connect to Snowflake’s internet endpoint by using valid authentication credentials. This option requires an administrator to create the EAI, and then grant the USAGE privilege on the integration to the service owner role.

  Bemerkung

  Die Verwendung von Integrationen für den externen Zugriff auf Snowflake kann bedeuten, dass potenziell sensible Informationen über das Internet gesendet werden.

Beispiele für Code, der verschiedene Snowflake-Treiber verwendet, um eine Verbindung zu Snowflake herzustellen, finden Sie unter `Beispiele für Snowflake-Verbindungen<https://github.com/Snowflake-Labs/sf-samples/tree/main/samples/spcs/sf-connection>`_.

SNOWFLAKE_ACCOUNT = os.getenv('SNOWFLAKE_ACCOUNT')
SNOWFLAKE_HOST = os.getenv('SNOWFLAKE_HOST')

def get_login_token():
  with open('/snowflake/session/token', 'r') as f:
    return f.read()

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth'
)

ALTER USER my_user SET DEFAULT_SECONDARY_ROLES = ( 'ALL' );

-- Permissions to resolve the table's name.
GRANT CALLER USAGE ON DATABASE <db_name> TO ROLE <service_owner_role>;
GRANT CALLER USAGE ON SCHEMA <schema_name> TO ROLE <service_owner_role>;
-- Permissions to use a warehouse
GRANT CALLER USAGE ON WAREHOUSE <warehouse_name> TO ROLE <service_owner_role>;
-- Permissions to query the table.
GRANT CALLER SELECT ON TABLE T1 TO ROLE <service_owner_role>;

conn = snowflake.connector.connect(
  account = '<acct-name>',
  user = '<user-name>',
  password = '<password>'
)

Configuration of the database and schema context for executing SQL¶

Neben der Bereitstellung von Anmeldeinformationen stellt Snowflake auch den Datenbank- und Schemakontext bereit, in dem der Service erstellt wird. Der Containercode kann diese Informationen zur Ausführung von SQL im gleichen Datenbank- und Schemakontext wie der Service verwenden.

In diesem Abschnitt werden zwei Konzepte erläutert:

• Die Logik, mit der Snowflake Datenbank und Schema bestimmt, in dem Ihr Dienst erstellt werden soll.

• Die Methode, mit der Snowflake diese Informationen an Ihre Container weitergibt, sodass der Containercode SQL im gleichen Datenbank- und Schemakontext ausführen kann.

Snowflake verwendet den Dienstnamen, um die Datenbank und das Schema zu bestimmen, in denen ein Dienst erstellt werden soll:

• Beispiel 1: In den folgenden Befehlen CREATE SERVICE und EXECUTE JOB SERVICE gibt der Dienstname nicht explizit einen Datenbank- und Schemanamen an. Snowflake erstellt den Dienst und den Jobdienst in der aktuellen Datenbank und dem aktuellen Schema.

  -- Create a service.
  CREATE SERVICE test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = example_job_service ...
  

  Copy

• Beispiel 2: In den folgenden Befehlen CREATE SERVICE und EXECUTE JOB SERVICE enthält der Dienstname einen Datenbank- und einen Schemanamen. Snowflake erstellt den Dienst und den Jobdienst in der angegebenen Datenbank (test_db) und dem angegebenen Schema (test_schema), unabhängig vom aktuellen Schema.

  -- Create a service.
  CREATE SERVICE test_db.test_schema.test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = test_db.test_schema.example_job_service ...
  

  Copy

Wenn Snowflake einen Dienst startet, werden den ausgeführten Containern die Datenbank- und Schemainformationen über die folgenden Umgebungsvariablen zur Verfügung gestellt:

• SNOWFLAKE_DATABASE

• SNOWFLAKE_SCHEMA

Ihr Containercode kann Umgebungsvariablen im Verbindungscode verwenden, um die zu verwendende Datenbank und das Schema zu bestimmen, wie im folgenden Beispiel gezeigt:

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth',
  database = os.getenv('SNOWFLAKE_DATABASE'),
  schema = os.getenv('SNOWFLAKE_SCHEMA')
)

Beispiel

In Tutorial 2 erstellen Sie einen Snowflake-Jobdienst, der sich mit Snowflake verbindet und SQL-Anweisungen ausführt. Die folgenden Schritte fassen zusammen, wie der Tutorial-Code die Umgebungsvariablen verwendet:

1. Bei der grundlegenden Einrichtung (siehe Abschnitt Grundlegende Einrichtung) erstellen Sie Ressourcen, einschließlich einer Datenbank und eines Schemas. Sie legen auch die aktuelle Datenbank und das aktuelle Schema für die Sitzung fest:

   USE DATABASE tutorial_db;
   ...
   USE SCHEMA data_schema;
   

   Copy

2. Nachdem Sie einen Jobdienst erstellt haben (durch Ausführen von EXECUTE JOB SERVICE), startet Snowflake den Container und setzt die folgenden Umgebungsvariablen im Container auf die aktuelle Datenbank und das aktuelle Schema der Sitzung:

   • SNOWFLAKE_DATABASE ist auf „TUTORIAL_DB“ gesetzt.

   • SNOWFLAKE_SCHEMA ist auf „DATA_SCHEMA“ gesetzt.

3. Der Jobcode (siehe main.py in Tutorial 2) liest diese Umgebungsvariablen aus:

   SNOWFLAKE_DATABASE = os.getenv('SNOWFLAKE_DATABASE')
   SNOWFLAKE_SCHEMA = os.getenv('SNOWFLAKE_SCHEMA')
   

   Copy

4. Der Jobcode legt die Datenbank und das Schema als Kontext fest, in dem die SQL-Anweisungen ausgeführt werden (Funktion run_job() in main.py):

   {
      "account": SNOWFLAKE_ACCOUNT,
      "host": SNOWFLAKE_HOST,
      "authenticator": "oauth",
      "token": get_login_token(),
      "warehouse": SNOWFLAKE_WAREHOUSE,
      "database": SNOWFLAKE_DATABASE,
      "schema": SNOWFLAKE_SCHEMA
   }
   ...
   

   Copy

   Bemerkung

   SNOWFLAKE_ACCOUNT SNOWFLAKE_HOST, SNOWFLAKE_DATABASE, SNOWFLAKE_SCHEMA sind Umgebungsvariablen, die Snowflake für den Anwendungscontainer generiert, allerdings nicht SNOWFLAKE_WAREHOUSE (der Anwendungscode von Tutorial 2 erstellt diese Variable, da Snowflake keinen Warehouse-Namen an einen Container übergibt).

Angeben des Warehouses für Ihren Container¶

Wenn Ihr Dienst eine Verbindung zu Snowflake herstellt, um eine Abfrage in einem Snowflake-Warehouse auszuführen, haben Sie die folgenden Optionen für die Angabe des Warehouses:

• Warehouse in Ihrem Anwendungscode angeben. Geben Sie ein Warehouse als Teil der Verbindungskonfiguration an, wenn Sie eine Snowflake-Sitzung zum Ausführen von Abfragen in Ihrem Code starten. Ein Beispiel dazu finden Sie unter Tutorial 2.

• Specify a default warehouse when creating a service. Specify the optional QUERY_WAREHOUSE parameter in the CREATE SERVICE or EXECUTE JOB SERVICE command to provide a default warehouse. If your application code doesn’t provide a warehouse as part of connection configuration, Snowflake uses the default warehouse. Use the ALTER SERVICE command to change the default warehouse.

  Bemerkung

  Das Warehouse, das mit dem QUERY_WAREHOUSE-Parameter angegeben wurde, ist der Standard nur für Servicebenutzer. Wenn der Service im Namen eines anderen Benutzers eine Verbindung zu Snowflake herstellt – im Kontext des Szenarios der Aufruferrechte –, verwendet Snowflake das Standard-Warehouse des Benutzers.

If you specify a warehouse by using both methods, the warehouse that is specified in the application code is used.

Access service user query history¶

You can find queries executed by your service as the service user by filtering the Ansicht QUERY_HISTORY or QUERY_HISTORY function where user_type is SNOWFLAKE_SERVICE.

Beispiel 1: Abrufen von Abfragen, die von einem Dienst ausgeführt werden.

SELECT *
FROM snowflake.account_usage.query_history
WHERE user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
AND user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
order by start_time;

Für die WHERE-Klausel gilt:

• user_name = '<service_name>': Sie geben den Dienstnamen als Benutzernamen an, da ein Dienst Abfragen als Dienstbenutzer ausführt und der Name des Dienstbenutzers mit dem Dienstnamen identisch ist.

• user_type = 'SNOWFLAKE_SERVICE' und user_name = '<service_name>': Dies schränkt das Abfrageergebnis so ein, dass nur von einem Dienst ausgeführte Abfragen abgerufen werden.

• user_database_name und user_schema_name: Für einen Benutzer eines Dienstes sind dies die Datenbank und das Schema des Dienstes.

Sie können die gleichen Ergebnisse erzielen, indem Sie die Funktion QUERY_HISTORY aufrufen.

SELECT *
FROM TABLE(<service_db_name>.information_schema.query_history())
WHERE user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
AND user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
order by start_time;

Für die WHERE-Klausel gilt:

• user_type = 'SNOWFLAKE_SERVICE' und user_name = '<service_name>' schränken das Abfrageergebnis so ein, dass nur von einem Dienst ausgeführte Abfragen abgerufen werden.

• user_database_name- und user_schema_name-Namen (für einen Dienstbenutzer) sind die Datenbank und das Schema des Dienstes.

Beispiel 2: Von Diensten ausgeführte Abfragen und die entsprechenden Dienstinformationen abrufen.

SELECT query_history.*, services.*
FROM snowflake.account_usage.query_history
JOIN snowflake.account_usage.services
ON query_history.user_name = services.service_name
AND query_history.user_schema_id = services.service_schema_id
AND query_history.user_type = 'SNOWFLAKE_SERVICE'

Die Abfrage verknüpft die Ansichten QUERY_HISTORY und SERVICES, um Informationen über die Abfragen und die Dienste, die die Abfragen ausführten, abzurufen. Beachten Sie Folgendes:

• Bei Abfragen, die von Diensten ausgeführt werden, ist query_history.user_name der Name des Dienstbenutzers, der mit dem Dienstnamen übereinstimmt.

• Die Abfrage verbindet die Ansichten anhand des Schemas IDs (nicht des Schemanamens), um sicherzustellen, dass Sie sich auf dasselbe Schema beziehen. Denn wenn Sie ein Schema löschen und neu erstellen, ändert sich das Schema ID, aber der Name bleibt derselbe.

Sie können der Abfrage optionale Filter hinzufügen. Beispiel:

• query_history-Filter, um nur Dienste abzurufen, die bestimmte Abfragen ausgeführt haben.

• services-Filter, um nur Abfragen abzurufen, die von bestimmten Diensten ausgeführt wurden.

Beispiel 3: Abrufen von Dienstbenutzerinformationen für jeden Dienst.

SELECT services.*, users.*
FROM snowflake.account_usage.users
JOIN snowflake.account_usage.services
ON users.name = services.service_name
AND users.schema_id = services.service_schema_id
AND users.type = 'SNOWFLAKE_SERVICE'

Die Abfrage verbindet die Ansichten SERVICES und USERS im Schema ACCOUNT_USAGE, um Dienste und Benutzerinformationen abzurufen. Beachten Sie Folgendes:

• Wenn ein Dienst Abfragen ausführt, führt er die Abfragen als Dienstbenutzer aus, und der Name des Dienstbenutzers ist derselbe wie der Dienstname. Daher geben Sie die Join-Bedingung an: users.name = services.service_name.

• Dienstnamen sind nur innerhalb eines Schemas eindeutig. Daher gibt die Abfrage die Join-Bedingung (users.schema_id = services.service_schema_id) an, um sicherzustellen, dass jeder Dienstbenutzer mit dem spezifischen Dienst abgeglichen wird, zu dem er gehört (und nicht mit einem anderen gleichnamigen Dienst, der in verschiedenen Schemas läuft).

Timeout der eingehenden Verbindung¶

Eingangsendpunkte haben ein Timeout von 90 Sekunden. Wenn 90 Sekunden lang keine Aktivität bei einer Verbindung zu einem Endpunkt stattfindet, bricht Snowflake die Verbindung ab. Wenn Ihre Anwendung eine längere Konnektivität benötigt, verwenden Sie Polling oder WebSockets.

Eingangs-Webbrowser Authentifizierung Abmeldung¶

Wenn Sie eine Webanwendung erstellen, die als Dienst ausgeführt wird, haben Sie die Möglichkeit, Benutzern die Abmeldung von Ihrer Anwendung zu ermöglichen, indem Sie sie an /sfc-endpoint/logout weiterleiten.

Nach der Abmeldung muss sich der Benutzer erneut bei Snowflake authentifizieren, um auf den öffentlichen Endpunkt des Dienstes zuzugreifen.

Sicherheit von Eingangsdatenverkehr und Webanwendungen¶

Sie können einen Snowpark Container Services-Dienst für das Webhosting erstellen, indem Sie die Unterstützung für öffentliche Endpunkte (Netzwerkeingang) nutzen. Für zusätzliche Sicherheit setzt Snowflake einen Proxydienst ein, um eingehende Anforderungen von Clients an Ihren Dienst und ausgehende Antworten von Ihrem Dienst an die Clients zu überwachen. In diesem Abschnitt wird erklärt, was der Proxy tut und wie er sich auf einen Dienst auswirkt, der in Snowpark Container Services bereitgestellt wird.

Beispiel:

• Der Proxy leitet eine eingehende HTTP-Anforderung nicht weiter, wenn die Anforderung eine nicht zulässige HTTP-Methode verwendet.

• Der Proxy sendet eine 403-Antwort an den Client, wenn der Content-Type-Header in der Antwort angibt, dass die Antwort eine ausführbare Datei enthält.

Darüber hinaus kann der Proxy auch neue Kopfzeilen einfügen und bestehende Kopfzeilen in der Anforderung und der Antwort ändern, wobei Ihr Container und Ihre Datensicherheit berücksichtigt werden.

Beispielsweise könnte Ihr Dienst nach Erhalt einer Anforderung in der Antwort HTML-, JavaScript-, CSS- und andere Inhalte für eine Webseite an den Client-Browser senden. Die Webseite im Browser ist Teil Ihres Dienstes und dient als Benutzerschnittstelle. Wenn Ihr Dienst aus Sicherheitsgründen Einschränkungen unterliegt (z. B. bezüglich des Herstellens von Netzwerkverbindungen zu anderen Standorten), möchten Sie vielleicht auch, dass die Webseite Ihres Dienstes denselben Einschränkungen unterliegt.

Standardmäßig haben Dienste nur begeschränkte Berechtigungen für den Zugriff auf das Internet. Der Browser sollte auch verhindern, dass die Clientanwendung auf das Internet zugreift und möglicherweise in den meisten Fällen Daten freigibt. Wenn Sie eine Integration des externen Zugriffs (EAI) eingerichtet haben, um Ihrem Dienst den Zugriff auf example.com zu ermöglichen (siehe Konfigurieren des Netzwerkausgangs), sollte die Webseite für Ihren Dienst auch über Ihren Browser auf example.com zugreifen können.

Der Snowflake-Proxy wendet dieselben Netzwerkbeschränkungen auf den Dienst und die Webseite an, indem er einen CSP-Header (Content-Security-Policy) in die Antwort einfügt. Standardmäßig fügt der Proxy eine Baseline-CSP in die Antwort ein, um Schutz vor allgemeinen Sicherheitsbedrohungen zu bieten. Bei der Browser-Sicherheit geht es darum, ein Gleichgewicht zwischen Funktionalität und Sicherheit zu finden. Es liegt in der gemeinsamen Verantwortung sicherzustellen, dass diese Basis für Ihren Anwendungsfall geeignet ist. Wenn Ihr Dienst so konfiguriert ist, dass eine EAI verwendet wird, wendet der Proxy außerdem dieselben Netzwerkregeln von der EAI auf die CSP der Webseite an. Diese CSP ermöglicht der Webseite im Browser auf dieselben Standorte zuzugreifen, auf die auch der Dienst zugreifen kann.

Snowflake bietet CORS-Unterstützung, die Sie in der Dienstspezifikation konfigurieren.

Der Snowflake-Proxy gibt die in der Dienstspezifikation definierten CORS-Einstellungen zurück. Beachten Sie, dass der Proxy alle vom Dienst zurückgegebenen CORS-Header entfernt.

Die folgenden CORS-Header sind standardmäßig eingestellt:

• Access-Control-Expose-Headers-Header meldet immer die folgenden Header-Namen, zusätzlich zu den in der Dienstspezifikation für den Endpunkt konfigurierten Headern.

  • X-Frame-Options

  • Cross-Origin-Opener-Policy

  • Cross-Origin-Resource-Policy

  • X-Content-Type-Options

  • Cross-Origin-Embedder-Policy

  • Content-Security-Policy-Report-Only

  • Content-Security-Policy

• Access-Control-Max-Age ist auf zwei Stunden eingestellt.

• Access-Control-Allow-Credentials auf „true“ gesetzt ist.

Außerdem setzt Snowflake den Header Vary mit dem Wert Origin, um dem Browser anzuzeigen, dass der Wert für Access-Control-Allow-Origin je nach dem Wert von Origin unterschiedlich sein kann.

Der Header Authorization ist erforderlich, um die CORS-Anforderung zu erstellen. Sie können ein programmgesteuertes Zugriffstoken angeben (PAT) – in diesem Header (Authorization: "Snowflake Token=\"${patToken}\""). Informationen zum Generieren eines programmgesteuerten Zugriffstokens finden Sie unter Verwenden von programmatische Zugriffstoken für die Authentifizierung.

In den folgenden Abschnitten wird erläutert, wie der Snowflake-Proxy eingehende Anforderungen für Ihren Dienst verarbeitet und die ausgehenden Antworten Ihres Dienstes an die Clients modifiziert.

Überlegungen zum Zugriff und CORS¶

Standardmäßig verhindern Browser, dass Webanwendungen, die auf einem Server gehostet werden, Anfragen an einen anderen Server mit einem anderen Hostnamen senden. Wenn Sie beispielsweise eine Webanwendung außerhalb von Snowpark Container Services hosten, die mit einem in Snowpark Container Services bereitgestellten Backend-Dienst interagieren muss, gilt diese Einschränkung.

CORS (Cross-Origin Resource Sharing) ermöglicht es einem Snowpark Container Services-Dienst, den Browsern mitzuteilen, dass er Anfragen von Webanwendungen zulässt, die außerhalb seiner Umgebung gehostet werden. Sie können jeden öffentlichen Endpunkt konfigurieren, um festzulegen, wie er sowohl auf CORS Preflight-Anfragen als auch auf Standard-Anfragen reagiert.

Snowflake-Proxy setzt die folgenden Antwort-Header immer außer Kraft:

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

Der Snowflake-Proxy nimmt keinen dieser CORS-Header in die Antwort auf, wenn einer der folgenden Punkte zutrifft:

• CORS ist nicht für den Dienstendpunkt konfiguriert. Das heißt, es gibt kein corsSettings in der Dienstspezifikation

• CORS ist für den Dienstendpunkt konfiguriert, aber der Origin-Header in der Anfrage stimmt nicht mit dem angegebenen Feld Access-Control-Allow-Origin in der Dienstspezifikation überein

In der Dienstspezifikation können Sie CORS-Einstellungen für jeden öffentlichen Endpunkt konfigurieren. Wenn der origin-Header in der Anfrage mit dem Feld Access-Control-Allow-Origin übereinstimmt, das in der Spezifikation für den Endpunkt angegeben ist, fügt der Proxy in die Antwort die in der Spezifikation definierten CORS-Header mit den folgenden Anpassungen ein:

• Access-Control-Allow-Origin: Gibt den Origin-Header der Anfrage zurück.

• Access-Control-Expose-Headers: Fügt die Liste der erlaubten Header, die Sie konfiguriert haben, mit diesen immer sichtbaren Headern zusammen: X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, Cross-Origin-Embedder-Policy, Content-Security-Policy-Report-Only, Content-Security-Policy.

• Access-Control-Max-Age: Ist auf zwei Stunden eingestellt.

• Access-Control-Allow-Credentials: Ist auf „true“ gesetzt.

Überlegungen zum Zugriff und SSO¶

Wenn Sie vom Internet aus auf den öffentlichen Endpunkt zugreifen, kann es sein, dass die Authentifizierung mit Benutzername und Kennwort funktioniert, aber SSO zu einer leeren Seite oder dem Fehler führt: „OAuth Clientintegration mit der angegebenen Client-ID wurde nicht gefunden.“

Dies passiert, wenn Sie die alte Methode der föderierten Authentifizierung (SSO) mit Snowflake anstelle der neueren Version der Sicherheitsintegration verwenden, wie unter Konfigurieren von Snowflake für die Verwendung der Verbundauthentifizierung beschrieben. Gehen Sie wie folgt vor, um dies zu überprüfen:

1. Führen Sie die folgende Abfrage aus:

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   Wenn Sie diesen Parameter gesetzt haben, haben Sie zu irgendeinem Zeitpunkt die alte föderierte Authentifizierung verwendet.

2. Wenn der obige Parameter gesetzt wurde, führen Sie die folgende Abfrage aus, um festzustellen, ob Sie über eine SAML-Sicherheitsintegration verfügen:

   SHOW INTEGRATIONS
     ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
   

   Copy

   Wenn Sie keine Integrationen des Typs SAML2 haben, dann verwenden Sie die alte Methode der föderierten Authentifizierung.

In diesem Fall besteht die Lösung darin, von der alten Methode der föderierten Authentifizierung auf die neue, integrative Methode der föderierten Authentifizierung umzusteigen. Weitere Informationen dazu finden Sie unter Migration zu einer SAML2-Sicherheitsintegration.

Netzwerkausgang über private Konnektivität¶

Anstatt den Netzwerkausgag über das öffentliche Internet zu routen, können Sie sich dafür entscheiden, den Ausgangverkehr Ihres Dienstes über einen privaten Konnektivitätsendpunkt zu leiten.

Zunächst müssen Sie den privaten Konnektivitätsendpunkt in Ihrem Snowflake-Konto erstellen. Konfigurieren Sie dann eine Netzwerkregel, um den ausgehenden Datenverkehr über die private Konnektivität zuzulassen. Der Prozess zur Einrichtung einer External Access Integration (EAI) bleibt derselbe wie im vorangegangenen Abschnitt beschrieben.

Wenn Sie zum Beispiel den ausgehenden Internetzugang Ihres Dienstes zu einem Amazon S3-Bucket über private Konnektivität aktivieren möchten, gehen Sie wie folgt vor:

1. Aktivieren Sie die private Link-Konnektivität für den selbstverwalteten Endpunktdienst (Amazon S3). Eine Schritt-für-Schritt-Anleitung finden Sie unter AWS Private Link for Amazon S3.

2. Rufen Sie die Systemfunktion SYSTEM$PROVISION_PRIVATELINK_ENDPOINT auf, um einen privaten Konnektivitätsendpunkt in Ihrem Snowflake-VNet bereitzustellen. Dadurch kann Snowflake über private Konnektivität eine Verbindung zum externen Dienst (in diesem Beispiel Amazon S3) herstellen.

   USE ROLE ACCOUNTADMIN;
   
   SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
     'com.amazonaws.us-west-2.s3',
     '*.s3.us-west-2.amazonaws.com'
   );
   

   Copy

3. Genehmigen Sie den Endpunkt im Konto des Cloudanbieters. In diesem Beispiel für Amazon AWS, siehe Verbindungsanfragen annehmen oder ablehnen in der AWS-Dokumentation. Um den Endpunkt in Azure zu genehmigen, lesen Sie auch die Azure-Dokumentation.

4. Verwenden Sie den Befehl CREATE NETWORK RULE, um eine Netzwerkegel für den ausgehenden Datenverkehr zu erstellen, in der Sie die externen Ziele angeben, für die Sie den Zugriff erlauben möchten.

   CREATE OR REPLACE NETWORK RULE private_link_network_rule
     MODE = EGRESS
     TYPE = PRIVATE_HOST_PORT
     VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
   

   Copy

   Der Parameters TYPE ist auf PRIVATE_HOST_PORT eingestellt. Er zeigt an, dass die Netzwerkregel den ausgehenden Datenverkehr über die private Konnektivität zulässt.

5. Die übrigen Schritte zur Erstellung eines EAI und dessen Verwendung zur Erstellung eines Dienstes sind die gleichen wie im vorangegangenen Abschnitt (siehe Konfigurieren des Netzwerkausgangs) erklärt.

Weitere Informationen zur Arbeit mit privaten Konnektivitätsendpunkten finden Sie unter:

• Verwalten Sie private Konnektivitätsendpunkte: AWS

• Private Konnektivitätsendpunkte verwalten: Azure

• Verwalten Sie private Konnektivitätsendpunkte: Google Cloud

Snowflake-Geheimnisse angeben¶

Geben Sie ein Snowflake-Geheimnis durch Name oder Referenz an (die Referenz ist nur im Native Application-Szenario anwendbar):

• Snowflake-Geheimnis per Name übergeben: Sie können einen Geheimnamen als snowflakeSecret-Feldwert übergeben.

  ...
  secrets:
  - snowflakeSecret:
      objectName: '<secret-name>'
    <other info about where in the container to copy the secret>
    ...
  

  Copy

  Beachten Sie, dass Sie optional <secret-name> direkt als Wert snowflakeSecret angeben können.

• Snowflake-Geheimnis per Referenz weitergeben: Wenn Sie Snowpark Container Services verwenden, um eine Native App (eine App mit Containern) zu erstellen, verwenden der App-Produzent und die Verbraucher unterschiedliche Snowflake-Konten. In bestimmten Kontexten muss eine installierte Snowflake Native App auf bestehende Geheimnisobjekte im Verbraucherkonto zugreifen, die außerhalb des APPLICATION-Objekts existieren. In diesem Fall können Entwickler die Syntax der Spezifikation „secrets by reference“ (Geheimnisse per Referenz) verwenden, um Anmeldeinformationen wie gezeigt zu behandeln:

  containers:
  - name: main
    image: <url>
    secrets:
    - snowflakeSecret:
        objectReference: '<reference-name>'
      <other info about where in the container to copy the secret>
  

  Copy

  Beachten Sie, dass die Spezifikation objectReference anstelle von objectName verwendet, um einen geheimen Referenznamen anzugeben.

Festlegen der Platzierung von Geheimnissen innerhalb des Containers¶

Sie können Snowflake anweisen, die Geheimnisse entweder als Umgebungsvariablen in den Containern zu platzieren oder sie in lokale Dateien der Container zu schreiben.

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: <secret-name>
    secretKeyRef: username | password | secret_string |  'access_token'
    envVarName: '<env-variable-name>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: username
    envVarName: LOGIN_USER
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: password
    envVarName: LOGIN_PASSWORD

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    secretKeyRef: secret_string
    envVarName: GENERIC_SECRET

containers:
- name: <name>
  image: <url>
  ...
  secrets:
  - snowflakeSecret: <snowflake-secret-name>
    directoryPath: '<local directory path in the container>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.oauth_secret
  TYPE = OAUTH2
  OAUTH_REFRESH_TOKEN = '34n;vods4nQsdg09wee4qnfvadH'
  OAUTH_REFRESH_TOKEN_EXPIRY_TIME = '2023-12-31 20:00:00'
  API_AUTHENTICATION = my_integration;

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.oauth_secret
    directoryPath: '/usr/local/creds'