Snowpark Container Services: Zusätzliche Hinweise zu Diensten¶

Verbinden mit Snowflake¶

Snowflake stellt die folgenden Umgebungsvariablen zur Verfügung, mit denen Sie einen Snowflake-Client in Ihrem Dienstcode konfigurieren können:

• SNOWFLAKE_ACCOUNT: Liefert den Konto-Locator für das Snowflake-Konto, unter dem der Service derzeit läuft.

• SNOWFLAKE_HOST: Gibt den Hostnamen an, der für die Verbindung zu Snowflake verwendet wird.

Snowflake stellt auch ein OAuth-Token im Container in einer Datei namens /snowflake/session/token bereit. Wenn Sie eine Verbindung herstellen, geben Sie dieses Token an den Konnektor weiter.

Wenn Sie eine Verbindung zu Snowflake von einem Container aus erstellen, müssen Sie SNOWFLAKE_HOST, SNOWFLAKE_ACCOUNT und das OAuth-Token verwenden. Sie können das OAuth-Token nur verwenden, wenn Sie auch SNOWFLAKE_HOST verwenden, und Sie können das OAuth-Token nicht außerhalb von Snowpark Container Services verwenden. Weitere Informationen dazu finden Sie unter Verwenden eines OAuth-Tokens zum Ausführen von SQL.

Beispielcode für die Verwendung verschiedener Snowflake-Treiber finden Sie unter Snowflake Connection Samples.

Beispiele

• In Tutorial 2 (siehe main.py) liest der Code die Umgebungsvariablen wie folgt:

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

  Copy

  Der Code übergibt diese Variablen an einen Verbindungserstellungscode für den Snowflake-Client Ihrer Wahl. Der Container verwendet diese Anmeldeinformationen, um eine neue Sitzung mit der Eigentümerrolle als Primärrolle zu erstellen, um Abfragen auszuführen. Der folgende Beispielcode zeigt, was mindestens zum Erstellen einer Snowflake-Verbindung in Python erforderlich ist:

  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'
  )
  

  Copy

• Wenn Sie den Standard-Host verwenden (d. h. Sie geben das Argument host beim Erstellen einer Verbindung nicht an), wird die Verbindung zu Snowflake mit anderen Formen der Authentifizierung (z. B. Benutzername und Kennwort) unterstützt. Bei der folgenden Verbindung werden zur Authentifizierung beispielsweise Benutzername und Kennwort angegeben:

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

  Copy

  Die Verwendung eines Standard-Hosts erfordert eine Integration für den externen Zugriff mit einer Netzwerkregel, die den Zugriff von Ihrem Dienst auf den Snowflake-Hostnamen Ihres Kontos erlaubt. Wenn Ihr Kontoname beispielsweise MyAccount ist, lautet der Hostname myaccount.snowflakecomputing.com. Weitere Informationen dazu finden Sie unter Konfigurieren des Netzwerkausgangs.

  • Erstellen Sie eine Netzwerkregel, die einen Abgleich mit Snowflake-API-Hostnamen Ihres Kontos vornimmt:

    CREATE OR REPLACE NETWORK RULE snowflake_egress_access
      MODE = EGRESS
      TYPE = HOST_PORT
      VALUE_LIST = ('myaccount.snowflakecomputing.com');
    

    Copy

  • Erstellen Sie eine Integration unter Verwendung der obigen Netzwerkregel:

    CREATE EXTERNAL ACCESS INTEGRATION snowflake_egress_access_integration
      ALLOWED_NETWORK_RULES = (snowflake_egress_access)
      ENABLED = true;
    

    Copy

Konfigurieren des Datenbank- und Schemakontextes für das Ausführen von SQL¶

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.

• Standard-Warehouse beim Erstellen eines Dienstes angeben. Geben Sie den optionalen Parameter QUERY_WAREHOUSE im Befehl CREATE SERVICE (oder EXECUTE JOB SERVICE) an, um ein Standard-Warehouse bereitzustellen. Wenn Ihr Anwendungscode kein Warehouse als Teil der Verbindungskonfiguration bereitstellt, verwendet Snowflake das Standard-Warehouse. Verwenden Sie den Befehl ALTER SERVICE, um das Standard-Warehouse zu ändern.

Wenn Sie ein Warehouse mit beiden Methoden angeben, wird das im Anwendungscode angegebene Warehouse verwendet.

Verwenden eines OAuth-Tokens zum Ausführen von SQL¶

Alle von Snowflake bereitgestellten Clients unterstützen OAuth als Authentifizierungsoption. Auch Dienstcontainer verwenden den OAuth-Mechanismus zur Authentifizierung bei Snowflake. Wenn ein Container zum Beispiel SQL ausführen möchte, stellt er eine Verbindung zu Snowflake her, ähnlich wie jeder andere Snowflake-Client:

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'
)

Wenn Sie einen Dienst erstellen, führt Snowflake die Container aus und stellt den Containern ein OAuth-Token zur Verfügung, das an der folgendem Speicherort innerhalb des Containers verwendet wird: /snowflake/session/token.

Beachten Sie die folgenden Details zu diesem OAuth-Token:

• Sie müssen den Inhalt der Datei /snowflake/session/token unmittelbar vor der Verwendung lesen, da der Inhalt innerhalb von 10 Minuten abläuft, und Snowflake diese Datei alle paar Minuten aktualisiert. Nachdem sich ein Container erfolgreich mit Snowflake verbunden hat, gilt die Ablaufzeit nicht mehr für die Verbindung (wie bei allen Sitzungen, die Benutzer direkt erstellen).

• Dieses OAuth-Token ist nur innerhalb des jeweiligen Snowflake-Dienstes gültig. Sie können das OAuth-Token nicht kopieren und außerhalb des Dienstes verwenden.

• Unter Verwendung des OAuth-Tokens verbinden sich die Container mit Snowflake als Dienstbenutzer und verwenden die Eigentümerrolle des Dienstes.

• Die Verwendung des OAuth-Tokens zum Herstellen einer Verbindung führt zu einer neuen Sitzung. Das OAuth-Token ist mit keiner bestehenden SQL-Sitzung verbunden.

  Bemerkung

  Ein wesentlicher Unterschied zwischen dem Ausführen von gespeicherten Prozeduren und dem Ausführen eines Dienstes besteht darin, dass gespeicherte Prozeduren in der gleichen Sitzung ausgeführt werden wie der SQL-Code, der sie ausführt. Aber jedes Mal, wenn ein Container eine neue Verbindung aufbaut, wird eine neue Sitzung erstellt.

Konnektivität mit Snowflake aus einem Container heraus unter Verwendung Aufruferrechte¶

Container führen Abfragen aus, indem sie sich als Dienstbenutzer mit Snowflake verbinden und die Eigentümerrolle des Dienstes verwenden, die dem Dienst Berechtigungen gewährt. In bestimmten Anwendungsszenarien kann es erforderlich sein, dass Sie Abfragen im Kontext des Endbenutzers und nicht des Dienstbenutzers ausführen müssen. In diesem Kontext wird das Aufruferrechte-Feature verwendet.

Nehmen wir zum Beispiel an, Sie erstellen einen Dienst, der einen öffentlichen Endpunkt für eine Webanwendung bereitstellt, die ein Dashboard mit in Snowflake gespeicherten Daten anzeigt. Sie gewähren anderen Benutzern in Ihrem Snowflake-Konto Zugriff auf das Dashboard (indem Sie diesen Benutzern die Dienstrolle zuweisen). Wenn sich einer dieser Endbenutzer beim Dashboard anmeldet, soll das Dashboard nur die Daten anzeigen, auf die der Benutzer Zugriff hat.

Da Container jedoch standardmäßig Abfragen unter Verwendung des Dienstbenutzers und der Eigentümerrolle des Dienstes ausführen, zeigt das Dashboard die Daten an, auf die die Eigentümerrolle des Dienstes Zugriff hat, unabhängig davon, welcher Endbenutzer mit dem Endpunkt verbunden ist. Daher sind die Daten im Dashboard des Benutzers nicht auf die Daten beschränkt, auf die der Benutzer Zugriff hat, so dass der Benutzer auf Daten zugreifen kann, auf die er keinen Zugriff hat.

Um das Dashboard so einzuschränken, dass nur Daten angezeigt werden, auf die der angemeldete Benutzer Zugriff hat, müssen die Anwendungscontainer SQL mit den Berechtigungen des Endbenutzers ausführen. Sie können dies aktivieren, indem Sie die Aufruferrechte in der Anwendung verwenden.

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>;

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.

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 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 folgenden Abfragen aus, um festzustellen, ob Sie über eine SAML-Sicherheitsintegration verfügen:

   SHOW INTEGRATIONS;
   SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) 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

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'