Snowpark Container Services : considérations supplémentaires pour les services¶

Connexion à Snowflake¶

Snowflake fournit les variables d’environnement suivantes pour vous permettre de configurer un client Snowflake dans votre code de service :

• SNOWFLAKE_ACCOUNT : fournit le localisateur de compte du compte Snowflake sous lequel le service est actuellement exécuté.

• SNOWFLAKE_HOST : fournit le nom d’hôte utilisé pour se connecter à Snowflake.

Snowflake fournit également un jeton OAuth dans le conteneur dans un fichier nommé /snowflake/session/token. Lors de la création d’une connexion, vous fournissez ce jeton au connecteur.

Lorsque vous créez une connexion à Snowflake à partir d’un conteneur, vous devez utiliser les jetons SNOWFLAKE_HOST, SNOWFLAKE_ACCOUNT et OAuth. Vous ne pouvez pas utiliser le jeton OAuth sans utiliser également SNOWFLAKE_HOST, et vous ne pouvez pas utiliser le jeton OAuth en dehors de Snowpark Container Services. Pour plus d’informations, voir Utilisation d’un jeton OAuth pour exécuter SQL.

Pour des exemples de code utilisant divers pilotes Snowflake, voir Exemples de connexion Snowflake.

Exemples

• Dans le tutoriel 2 (voir main.py), le code lit les variables d’environnement comme suit :

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

  Copy

  Le code transmet ces variables à un code de création de connexion pour le client Snowflake choisi. Le conteneur utilise ces identifiants de connexion pour créer une nouvelle session, avec le rôle de propriétaire comme rôle principal, afin d’exécuter des requêtes. L’exemple de code suivant est le minimum requis pour créer une connexion Snowflake en Python :

  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

• Lorsque vous utilisez l’hôte par défaut (c’est-à-dire que vous n’incluez pas l’argument host lors de la création d’une connexion), la connexion à Snowflake en utilisant d’autres formes d’authentification (telles que le nom d’utilisateur et le mot de passe) est prise en charge. Par exemple, la connexion suivante spécifie le nom d’utilisateur et le mot de passe pour l’authentification :

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

  Copy

  L’utilisation d’un hôte par défaut nécessite l’intégration d’accès externe avec une règle de réseau permettant l’accès de votre service au nom d’hôte Snowflake pour votre compte. Par exemple, si le nom de votre compte est MyAccount, le nom d’hôte sera moncompte.snowflakecomputing.com. Pour plus d’informations, voir Sortie réseau.

  • Créez une règle de réseau qui correspond au nom d’hôte d’API Snowflake de votre compte :

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

    Copy

  • Créez une intégration à l’aide de la règle de réseau précédente :

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

    Copy

Configuration de la base de données et du contexte du schéma pour l’exécution de SQL¶

Cette section présente deux concepts :

• La logique utilisée par Snowflake pour déterminer la base de données et le schéma dans lesquels créer votre service.

• La méthode par laquelle Snowflake transmet cette information à vos conteneurs, permettant ainsi au code du conteneur d’exécuter SQL dans le même contexte de base de données et de schéma.

Snowflake utilise le nom du service pour déterminer la base de données et le schéma dans lesquels créer un service :

• Exemple 1 : dans les commandes CREATE SERVICE et EXECUTE JOB SERVICE suivantes, le nom du service ne spécifie pas explicitement une base de données et un nom de schéma. Snowflake crée le service et le service de tâche dans la base de données et le schéma actuels.

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

• Exemple 2 : dans les commandes CREATE SERVICE et EXECUTE JOB SERVICE suivantes, le nom du service comprend une base de données et un nom de schéma. Snowflake crée le service et le service de tâche dans la base de données (test_db) et le schéma (test_schema) spécifiés, quel que soit le schéma actuel.

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

Lorsque Snowflake démarre un service, Snowflake fournit les informations relatives à la base de données et au schéma aux conteneurs en cours d’exécution en utilisant les variables d’environnement suivantes :

• SNOWFLAKE_DATABASE

• SNOWFLAKE_SCHEMA

Le code de votre conteneur peut utiliser des variables d’environnement dans le code de connexion pour déterminer la base de données et le schéma à utiliser, comme le montre cet exemple :

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

Exemple

Dans le tutoriel 2, vous créez un service de tâche Snowflake qui se connecte à Snowflake et exécute des instructions SQL. Les étapes suivantes résument la manière dont le code du tutoriel utilise les variables d’environnement :

1. Dans la configuration commune (voir la section Configuration commune), vous créez des ressources, notamment une base de données et un schéma. Vous définissez également la base de données et le schéma actuels pour la session :

   USE DATABASE tutorial_db;
   ...
   USE SCHEMA data_schema;
   

   Copy

2. Après avoir créé un service de tâche (exécution de EXECUTE JOB SERVICE), Snowflake démarre le conteneur et définit les variables d’environnement suivantes dans le conteneur en fonction de la base de données et du schéma actuels de la session :

   • SNOWFLAKE_DATABASE est défini sur « TUTORIAL_DB »

   • SNOWFLAKE_SCHEMA est défini sur « DATA_SCHEMA »

3. Le code de la tâche (voir main.py dans le tutoriel 2) lit ces variables d’environnement :

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

   Copy

4. Le code de la tâche définit la base de données et le schéma comme le contexte dans lequel exécuter les instructions SQL (fonction run_job() dans main.py) :

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

   Copy

   Note

   SNOWFLAKE_ACCOUNT, SNOWFLAKE_HOST, SNOWFLAKE_DATABASE, SNOWFLAKE_SCHEMA sont des variables d’environnement que Snowflake génère pour le conteneur d’application, mais SNOWFLAKE_WAREHOUSE ne l’est pas (le code de l’application du tutoriel 2 a créé cette variable parce que Snowflake ne transmet pas de nom d’entrepôt à un conteneur).

Spécification de l’entrepôt pour votre conteneur¶

Si votre service se connecte à Snowflake pour exécuter une requête dans un entrepôt Snowflake, vous disposez des options suivantes pour spécifier un entrepôt :

• Spécifiez un entrepôt dans votre code d’application. Spécifiez un entrepôt dans le cadre de la configuration de la connexion lorsque vous démarrez une session Snowflake pour exécuter des requêtes dans votre code. Pour un exemple, voir le tutoriel 2.

• Spécifiez un entrepôt par défaut lors de la création d’un service. Spécifiez le paramètre facultatif QUERY_WAREHOUSE dans la commande CREATE SERVICE (ou EXECUTE JOB SERVICE) pour fournir un entrepôt par défaut. Si votre code d’application ne fournit pas d’entrepôt dans le cadre de la configuration de la connexion, Snowflake utilise l’entrepôt par défaut. Utilisez la commande ALTER SERVICE pour modifier l’entrepôt par défaut.

Si vous spécifiez un entrepôt à l’aide des deux méthodes, c’est l’entrepôt spécifié dans le code d’application qui est utilisé.

Utilisation d’un jeton OAuth pour exécuter SQL¶

Tous les clients fournis par Snowflake prennent en charge OAuth comme moyen d’authentification. Les conteneurs de services utilisent également le mécanisme OAuth pour s’authentifier auprès de Snowflake. Par exemple, lorsqu’un conteneur veut exécuter SQL, il crée une connexion à Snowflake, comme n’importe quel autre client Snowflake :

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

Lorsque vous créez un service, Snowflake exécute les conteneurs et fournit un jeton Oauth pour les conteneurs à utiliser à l’emplacement suivant dans le conteneur : /snowflake/session/token.

Notez les détails suivants concernant ce jeton OAuth :

• Vous devez lire le contenu du fichier /snowflake/session/token immédiatement avant de l’utiliser, car le contenu expire au bout de 10 minutes, et Snowflake actualise ce fichier toutes les quelques minutes. Une fois qu’un conteneur s’est connecté avec succès à Snowflake, le délai d’expiration ne s’applique pas à la connexion (comme pour les sessions créées directement par les utilisateurs).

• Ce jeton OAuth n’est valable que pour le service Snowflake concerné. Vous ne pouvez pas copier le jeton OAuth et l’utiliser en dehors du service.

• À l’aide du jeton OAuth, les conteneurs se connectent à Snowflake en tant qu’utilisateur du service et utilisent le rôle de propriétaire du service.

• L’utilisation du jeton OAuth pour se connecter créera une nouvelle session. Le jeton OAuth n’est associé à aucune session SQL existante.

  Note

  Une différence importante entre l’exécution de procédures stockées et l’exécution d’un service est que les procédures stockées s’exécutent dans la même session que le SQL qui les exécute. Mais chaque fois qu’un conteneur établit une nouvelle connexion, vous créez une nouvelle session.

Entrée réseau¶

Pour permettre à quiconque d’interagir avec votre service depuis Internet, vous déclarez les ports réseau sur lesquels votre service écoute en tant que points de terminaison dans le fichier de spécification du service. Ces points de terminaison contrôlent l’entrée.

Par défaut, les points de terminaison de service sont privés. Seules les fonctions de service et les communications de service à service peuvent adresser des requêtes aux points de terminaison privés. Vous pouvez déclarer un point de terminaison comme étant public afin d’autoriser les requêtes vers un point de terminaison depuis Internet. Le rôle de propriétaire de service doit avoir le privilège BIND SERVICE ENDPOINT sur le compte.

endpoints:
- name: <endpoint name>
  port: <port number>
  protocol : < TCP / HTTP / HTTPS >
  public: true

Pour un exemple, voir le tutoriel 1.

Entrée et sécurité des applications web¶

Vous pouvez créer un service Snowpark Container Services pour l’hébergement web en utilisant la prise en charge de point de terminaison public (entrée réseau). Pour plus de sécurité, Snowflake utilise un service proxy pour contrôler les requêtes entrantes des clients vers votre service et les réponses sortantes de votre service vers les clients. Cette section explique ce que fait le proxy et comment il affecte un service déployé dans Snowpark Container Services.

Par exemple :

• Le proxy ne transmet pas une requête HTTP entrante si la requête utilise une méthode HTTP interdite.

• Le proxy envoie une réponse 403 au client si l’en-tête Content-Type de la réponse indique qu’elle contient un exécutable.

En outre, le proxy peut également injecter de nouveaux en-têtes et modifier les en-têtes existants dans la demande et la réponse, en tenant compte de votre conteneur et de la sécurité des données.

Par exemple, à la réception d’une requête, votre service peut envoyer du contenu HTML, JavaScript, CSS et d’autres contenus d’une page web au navigateur du client dans la réponse. La page web dans le navigateur fait partie de votre service et agit en tant qu’interface utilisateur. Pour des raisons de sécurité, si votre service est soumis à des restrictions (par exemple, l’interdiction d’établir des connexions réseau avec d’autres sites), vous voudrez peut-être que la page web de votre service soit soumise aux mêmes restrictions.

Par défaut, les services disposent d’autorisations limitées pour accéder à Internet. Le navigateur doit également empêcher l’application cliente d’accéder à Internet et de partager potentiellement des données dans la plupart des cas. Si vous avez mis en place une intégration d’accès externe (EAI) pour permettre à votre service d’accéder à example.com (voir Sortie réseau), la page web de votre service devrait également être en mesure d’accéder à example.com via votre navigateur.

Le proxy Snowflake applique les mêmes restrictions de réseau au service et à la page web en ajoutant un en-tête Content-Security-Policy (CSP) dans la réponse. Par défaut, le proxy ajoute une CSP de base dans la réponse pour se protéger contre les menaces de sécurité courantes. La sécurité du navigateur est le meilleur effort pour équilibrer la fonctionnalité et la sécurité. Il s’agit d’une responsabilité partagée qui garantit que cette base de référence est appropriée à votre cas d’utilisation. En outre, si votre service est configuré pour utiliser une EAI, le proxy applique les mêmes règles de réseau du EAI à la CSP pour la page web. Cette CSP permet à la page web du navigateur d’accéder aux mêmes sites que ceux auxquels le service peut accéder.

Les sections suivantes expliquent comment le proxy Snowflake gère les requêtes entrantes pour votre service et modifie les réponses sortantes de votre service aux clients.

Sortie réseau¶

Le code de votre application peut nécessiter un accès à Internet. Par défaut, les conteneurs d’application n’ont pas la permission d’accéder à Internet. Vous devez activer l’accès à Internet en utilisant les intégrations d’accès externe (EAIs).

En règle générale, vous souhaitez qu’un administrateur de compte crée des EAIs pour gérer l’accès externe autorisé à partir des services (y compris des services de tâche). Les administrateurs de comptes peuvent alors accorder l’utilisation d’EAI à des rôles spécifiques que les développeurs utilisent pour exécuter des services.

L’exemple suivant décrit les étapes de la création d’une EAI qui autorise le trafic de sortie vers des destinations spécifiques spécifiées à l’aide de règles de réseau. Vous vous référez ensuite à l’EAI lorsque vous créez un service pour autoriser des requêtes vers des destinations Internet spécifiques.

Exemple

Supposons que vous souhaitiez que le code de votre application envoie des requêtes aux destinations suivantes :

• Requêtes HTTPS vers translation.googleapis.com

• Requêtes HTTP et HTTPS vers google.com

Suivez ces étapes pour permettre à votre service d’accéder à ces domaines sur Internet :

1. Créez une intégration d’accès externe (EAI). Pour ce faire, il faut disposer des autorisations nécessaires. Par exemple, vous pouvez utiliser le rôle ACCOUNTADMIN pour créer une EAI. Il s’agit d’un processus en deux étapes :

   1. Utilisez la commande CREATE NETWORK RULE pour créer une ou plusieurs règles de réseau de sortie répertoriant les destinations externes auxquelles vous souhaitez autoriser l’accès. Vous pouvez réaliser cet exemple avec une seule règle de réseau, mais pour l’illustration, nous créons deux règles de réseau :

      1. Créez une règle de réseau nommée translate_network_rule :

         CREATE OR REPLACE NETWORK RULE translate_network_rule
           MODE = EGRESS
           TYPE = HOST_PORT
           VALUE_LIST = ('translation.googleapis.com');
         

         Copy

         Cette règle autorise les connexions TCP vers la destination translation.googleapis.com. Le domaine dans la propriété VALUE_LIST ne spécifie pas le numéro de port optionnel, de sorte que le port par défaut 443 (HTTPS) est supposé. Cela permet à votre application de se connecter à n’importe quelle URL qui commence par https://translation.googleapis.com/.

      2. Créez une règle de réseau nommée google_network_rule :

         CREATE OR REPLACE NETWORK RULE google_network_rule
           MODE = EGRESS
           TYPE = HOST_PORT
           VALUE_LIST = ('google.com:80', 'google.com:443');
         

         Copy

         Cela permet à votre application de se connecter à n’importe quelle URL qui commence par http://google.com/ ou https://google.com/.

      Note

      Pour le paramètre VALUE_LIST vous devez fournir un nom d’hôte complet. Les caractères génériques (par exemple, *.googleapis.com) ne sont pas pris en charge.

      Snowpark Container Services ne prend en charge que les règles de réseau qui autorisent les ports 22, 80, 443 et 1024+. Si une règle de réseau référencée autorise l’accès à d’autres ports, la création du service échouera. Contactez votre représentant de compte si vous avez besoin d’utiliser des ports supplémentaires.

      Note

      Pour permettre à votre service d’envoyer des requêtes HTTP ou HTTPS à n’importe quelle destination sur Internet, vous spécifiez « 0.0.0.0 » comme domaine dans la propriété VALUE_LIST. La règle de réseau suivante permet d’envoyer des requêtes « HTTP » et « HTTPS » n’importe où sur Internet. Seuls les ports 80 ou 443 sont pris en charge avec « 0.0.0.0 ».

      CREATE NETWORK RULE allow_all_rule
        TYPE = 'HOST_PORT'
        MODE= 'EGRESS'
        VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
      

      Copy

   2. Créez une intégration d’accès externe (EAI) qui spécifie que les deux règles de réseau de sortie précédentes sont autorisées :

      CREATE EXTERNAL ACCESS INTEGRATION google_apis_access_integration
        ALLOWED_NETWORK_RULES = (translate_network_rule, google_network_rule)
        ENABLED = true;
      

      Copy

      L’administrateur du compte peut désormais accorder l’utilisation de l’intégration aux développeurs pour leur permettre d’exécuter un service qui peut accéder à des destinations spécifiques sur Internet.

      GRANT USAGE ON INTEGRATION google_apis_access_integration TO ROLE test_role;
      

      Copy

2. Créez le service en fournissant l’EAI comme indiqué dans les exemples suivants. Le rôle de propriétaire qui crée le service a besoin du privilège USAGE sur l’EAI et du privilège READ sur les secrets référencés. Notez que vous ne pouvez pas utiliser le rôle ACCOUNTADMIN pour créer un service.

   • Créez un service :

     USE ROLE test_role;
     
     CREATE SERVICE eai_service
       IN COMPUTE POOL MYPOOL
       EXTERNAL_ACCESS_INTEGRATIONS = (GOOGLE_APIS_ACCESS_INTEGRATION)
       FROM SPECIFICATION
       $$
       spec:
         containers:
           - name: main
             image: /db/data_schema/tutorial_repository/my_echo_service_image:tutorial
             env:
               TEST_FILE_STAGE: source_stage/test_file
             args:
               - read_secret.py
         endpoints:
           - name: read
             port: 8080
       $$;
     

     Copy

     Cet exemple de requête CREATE SERVICE utilise une spécification de service en ligne et spécifie la propriété facultative EXTERNAL_ACCESS_INTEGRATIONS pour inclure l’EAI. L’EAI spécifie les règles de réseau qui autorisent le trafic de sortie du service vers les destinations spécifiques.

   • Exécuter un service de tâche :

     EXECUTE JOB SERVICE
       IN COMPUTE POOL tt_cp
       NAME = example_job_service
       EXTERNAL_ACCESS_INTEGRATIONS = (GOOGLE_APIS_ACCESS_INTEGRATION)
       FROM SPECIFICATION $$
       spec:
         container:
         - name: curl
           image: /tutorial_db/data_schema/tutorial_repo/alpine-curl:latest
           command:
           - "curl"
           - "http://google.com/"
       $$;
     

     Copy

     Cet exemple de commande EXECUTE JOBSERVICE spécifie la spécification en ligne et la propriété facultative EXTERNAL_ACCESS_INTEGRATIONS pour inclure l’EAI. Cela autorise le trafic de sortie de la tâche vers les destinations spécifiées dans les règles de réseau que l’EAI autorise.

Communications réseau entre les conteneurs¶

Il y a deux considérations à prendre en compte :

• Communications entre les conteneurs d’une instance de service : si une instance de service utilise plusieurs conteneurs, ces conteneurs peuvent communiquer entre eux via localhost (il n’est pas nécessaire de définir des points de terminaison dans la spécification du service).

• Communication entre les conteneurs appartenant à différents services ou plusieurs instances de services : les conteneurs appartenant à différents services (ou à différentes instances d’un même service) peuvent communiquer en utilisant des points de terminaison définis dans des fichiers de spécification. Pour plus d’informations, voir Communications de service à service.

Spécification des secrets Snowflake¶

Spécifiez un secret Snowflake par nom ou référence (la référence n’est applicable que dans le cas de Native Application) :

• Transmettez le secret Snowflake par nom : vous pouvez transmettre un nom de secret comme valeur de champ snowflakeSecret.

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

  Copy

  Notez que vous pouvez éventuellement spécifier <secret-name> directement comme la valeur snowflakeSecret.

• Transmettez le secret Snowflake par référence : lorsque vous utilisez les services de conteneurs Snowpark pour créer une Native App (une application avec des conteneurs), le producteur et les consommateurs de l’application utilisent des comptes Snowflake différents. Dans certains contextes, une Native App Snowflake installée doit accéder à des objets de secrets existants dans le compte consommateur et qui existent en dehors de l’objet APPLICATION. Dans ce cas, les développeurs peuvent utiliser la syntaxe de spécification « secrets par référence » pour gérer les identifiants de connexion comme indiqué :

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

  Copy

  Notez que la spécification utilise objectReference au lieu de objectName pour fournir un nom de référence secret.

Spécification du placement des secrets à l’intérieur du conteneur¶

Vous pouvez demander à Snowflake de placer les secrets dans les conteneurs en tant que variables d’environnement ou de les écrire dans des fichiers de conteneur locaux.

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'