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

Options de configuration des identifiants¶

Snowflake recommande que les conteneurs d’application utilisent des identifiants de connexion fournis par Snowflake pour s’authentifier auprès de Snowflake lors de l’exécution de SQL. Bien qu’il soit possible d’utiliser d’autres identifiants de connexion en se connectant via une intégration d’accès externe (EAI), la connexion via une EAI traite le service comme s’il fonctionnait en dehors de Snowflake et se connecte à Snowflake via Internet.

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

• Utiliser les informations d’identification de l’utilisateur du service fournies par Snowflake : Snowflake fournit chaque service avec des identifiants de connexion, qui sont appelés identifiants de connexion de service. Un service utilise ces identifiants de connexion pour se connecter à Snowflake en tant qu’utilisateur du service.

• Utiliser les identifiants de connexion de l’appelant fournis par Snowflake (droits de l’appelant) : lorsque vous configurez votre service avec les droits de l’appelant, Snowflake fournit également des identifiants de connexion pour que le service puisse se connecter à Snowflake en tant qu’utilisateur appelant.

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

  Note

  Si vous utilisez des intégrations d’accès externes pour accéder à Snowflake, vous pourriez envoyer des informations potentiellement sensibles sur Internet.

Pour des exemples de code qui utilisent divers pilotes Snowflake pour la connexion à Snowflake, voir Exemples de connexion Snowflake.

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¶

En plus de fournir des identifiants de connexion, Snowflake fournit également la base de données et le contexte de schéma dans lesquels le service est créé. Le code du conteneur peut utiliser ces informations pour exécuter SQL dans le même contexte de base de données et de schéma que le service.

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.

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

  Note

  L’entrepôt spécifié à l’aide du paramètre QUERY_WAREHOUSE est le paramètre par défaut uniquement pour l’utilisateur de service. Lorsque le service se connecte à Snowflake au nom d’un autre utilisateur — dans le contexte de scénario des droits de l’appelant, Snowflake utilise l’entrepôt par défaut de l’utilisateur.

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 Vue QUERY_HISTORY or QUERY_HISTORY function where user_type is SNOWFLAKE_SERVICE.

Exemple 1 : récupérer les requêtes exécutées par un service.

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;

Dans la clause WHERE :

• user_name = '<service_name>' : Vous spécifiez le nom du service comme nom d’utilisateur car un service exécute des requêtes en tant qu’utilisateur du service <label-snowpark_containers_connect_to_snowflake_from_container>, et que le nom de l’utilisateur du service est le même que le nom du service.

• user_type = 'SNOWFLAKE_SERVICE' et user_name = '<service_name>' : Cela limite le résultat de la requête à récupérer uniquement les requêtes exécutées par un service.

• user_database_name et user_schema_name : Pour un utilisateur de service, il s’agit de la base de données et du schéma du service.

Vous pouvez obtenir les mêmes résultats en appelant la fonction QUERY_HISTORY.

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;

Dans la clause WHERE :

• user_type = 'SNOWFLAKE_SERVICE' et user_name = '<service_name>' limitent le résultat de la requête pour récupérer uniquement les requêtes exécutées par un service.

• Les noms user_database_name et user_schema_name (pour un utilisateur de service) sont la base de données et le schéma du service.

Exemple 2 : récupérer les requêtes exécutées par les services et les informations correspondantes sur les services.

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'

La requête rejoint les vues QUERY_HISTORY et SERVICES pour récupérer des informations sur les requêtes et les services qui ont exécuté les requêtes. Remarques :

• Pour les requêtes exécutées par les services, le query_history.user_name est le nom de l’utilisateur du service, qui est le même que le nom du service.

• La requête joint les vues à l’aide des IDs de schémas (pas le nom des schémas) pour vous assurer que vous faites référence au même schéma, car si vous supprimez et recréez un schéma, l’ID du schéma change, mais le nom reste le même.

Vous pouvez ajouter des filtres facultatifs à la requête. Par exemple :

• Filtre query_history pour récupérer uniquement les services qui ont exécuté des requêtes spécifiques.

• Filtre services pour récupérer uniquement les requêtes exécutées par des services spécifiques.

Exemple 3 : pour chaque service, récupérer les informations sur l’utilisateur du service.

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'

La requête joint les vues SERVICES et USERS dans le schéma ACCOUNT_USAGE permettant de récupérer les services et les informations sur les utilisateurs des services. Remarques :

• Lorsqu’un service exécute des requêtes, il exécute les requêtes en tant qu’utilisateur du service et le nom de l’utilisateur du service est le même que le nom du service. Par conséquent, vous spécifiez la condition de jointure : users.name = services.service_name.

• Les noms de service ne sont uniques qu’au sein d’un schéma. Par conséquent, la requête spécifie la condition de jointure (users.schema_id = services.service_schema_id) pour garantir que chaque utilisateur de service est associé au service spécifique auquel il appartient (et non à un autre service du même nom exécuté dans des schémas différents).

Délai d’expiration de la connexion d’entrée¶

Les points de terminaison ont un délai d’expiration de 90 secondes. S’il n’y a aucune activité sur une connexion à un point de terminaison d’entrée pendant 90 secondes, Snowflake met fin à la connexion. Si votre application a besoin d’une connexion plus longue, utilisez l’interrogation ou WebSockets.

Déconnexion de l’authentification du navigateur web d’entrée¶

Si vous créez une application Web qui fonctionne en tant que service, vous avez la possibilité de permettre aux utilisateurs de se déconnecter de votre application en les dirigeant vers /sfc-endpoint/logout.

Après s’être déconnecté, l’utilisateur devra s’authentifier à nouveau auprès de Snowflake pour accéder au point de terminaison public du service.

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 Configuration de la 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.

Snowflake fournit l’assistance CORS que vous configurez dans la spécification du service.

Le proxy Snowflake renvoie les paramètres CORS définis dans la spécification du service. Notez que le proxy supprime les en-têtes CORS renvoyés par le service.

Les en-têtes CORS suivants sont définis par défaut :

• L’en-tête Access-Control-Expose-Headers signale toujours les noms d’en-têtes suivants, en plus des en-têtes configurés dans la spécification de service pour le point de terminaison.

  • 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 est défini sur deux heures.

• Access-Control-Allow-Credentials est défini sur true.

En outre, Snowflake définit l’en-tête Vary avec la valeur Origin pour indiquer au navigateur qu’en fonction de la valeur de Origin, la valeur de Access-Control-Allow-Origin peut être différente.

L’en-tête Authorization est nécessaire pour effectuer la requête CORS. Vous pouvez spécifier un jeton d’accès programmatique (PAT) dans cet en-tête (Authorization: "Snowflake Token=\"${patToken}\""). Pour plus d’informations sur la génération d’un jeton d’accès programmatique, voir Utilisation de jetons d’accès programmatique pour l’authentification.

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.

Considérations sur les entrées et CORS¶

Par défaut, les navigateurs empêchent les applications web hébergées sur un serveur d’envoyer des requêtes à un autre serveur dont le nom d’hôte est différent. Par exemple, si vous hébergez une application Web en dehors de Snowpark Container Services qui doit interagir avec un service backend déployé au sein de Snowpark Container Services, cette restriction s’applique.

CORS (Cross-Origin Resource Sharing) permet à un service Snowpark Container Services d’indiquer aux navigateurs d’autoriser les requêtes provenant d’applications Web hébergées en dehors de son environnement. Vous pouvez configurer chaque point de terminaison public pour spécifier la manière dont il répond aux requêtes de contrôle en amont et aux requêtes standard CORS.

Le proxy Snowflake remplace toujours les en-têtes de réponse suivants :

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

Le proxy Snowflake n’inclut aucun de ces en-têtes CORS dans la réponse lorsque l’une des conditions suivantes s’applique :

• CORS n’est pas configuré pour le point de terminaison du service. C’est-à-dire qu’il n’y a pas de corsSettings dans la spécification du service

• CORS est configuré pour le point de terminaison du service, mais l’en-tête Origin de la requête ne correspond pas au champ Access-Control-Allow-Origin spécifié dans la spécification du service

Dans la spécification du service, vous pouvez configurer les paramètres de CORS pour chaque point de terminaison public. Lorsque l’en-tête origin de la requête correspond au champ Access-Control-Allow-Origin spécifié pour le point de terminaison dans la spécification, le proxy inclut dans la réponse les en-têtes CORS définis dans la spécification, avec les ajustements suivants :

• Access-Control-Allow-Origin : Renvoie l’en-tête Origin de la requête.

• Access-Control-Expose-Headers : Fusionne la liste des en-têtes autorisés que vous avez configurés avec ces en-têtes toujours exposés : 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 est défini sur deux heures.

• Access-Control-Allow-Credentials est défini sur true.

Considérations sur les entrées et SSO¶

Lorsque vous accédez au point de terminaison public depuis Internet, vous pouvez constater que l’authentification par nom d’utilisateur/mot de passe fonctionne, mais que SSO aboutit à une page blanche ou à l’erreur : « L’intégration du clientOAuth avec l’ID de client donné est introuvable. »

Cela se produit lorsque vous utilisez l’ancien style d’authentification fédérée (SSO) avec Snowflake au lieu de la nouvelle version d’intégration de sécurité comme expliqué dans Configuration de Snowflake pour l’utilisation de l’authentification fédérée. Procédez comme suit pour vérifier :

1. Exécutez la requête suivante :

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   Si ce paramètre est défini, c’est que vous avez utilisé l’ancienne méthode d’authentification fédérée.

2. Si le paramètre précédent a été défini, exécutez les requêtes suivantes pour voir si vous avez une intégration de sécurité SAML :

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

   Copy

   Si vous n’avez pas d’intégration du type SAML2, vous utilisez l’ancienne méthode d’authentification fédérée.

Dans ce cas, la solution consiste à passer de l’ancienne authentification fédérée à la nouvelle authentification fédérée de type intégration. Pour plus d’informations, voir Migration d’une intégration de sécurité SAML2.

Sortie réseau par connectivité privée¶

Au lieu de router la sortie réseau via l’internet public, vous pouvez choisir de diriger le trafic de sortie de votre service vers un point de terminaison de connectivité privée.

Vous devez d’abord créer le point de terminaison de connectivité privée dans votre compte Snowflake. Configurez ensuite une règle de réseau pour autoriser le trafic sortant à utiliser la connectivité privée. Le processus de paramétrage d’une intégration d’accès externe (EAI) reste le même que celui décrit dans la section précédente.

Par exemple, si vous souhaitez activer l’accès internet sortant de votre service à un compartiment Amazon S3 via une connectivité privée, vous procédez comme suit :

1. Activez la connectivité du lien privé pour le service de point de terminaison autonome (Amazon S3). Pour obtenir des instructions étape par étape, consultez AWS Private Link pour Amazon S3.

2. Appelez la fonction du système SYSTEM$PROVISION_PRIVATELINK_ENDPOINT pour provisionner un point de terminaison de connectivité privée dans votre VNet Snowflake. Cela permet à Snowflake de se connecter au service externe (dans cet exemple, Amazon S3) en utilisant une connectivité privée.

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

   Copy

3. Dans le compte du fournisseur Cloud, approuvez le point de terminaison. Dans cet exemple, pour Amazon AWS, voir Accepter ou rejeter les requêtes de connexion dans la documentation AWS. Par ailleurs, pour approuver le point de terminaison dans Azure, consultez la documentation Azure.

4. Utilisez la commande CREATE NETWORK RULE pour créer une règle de réseau de sortie spécifiant les destinations externes auxquelles vous souhaitez autoriser l’accès.

   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

   La valeur du paramètre TYPE est définie sur PRIVATE_HOST_PORT. Elle indique que la règle de réseau autorise le trafic réseau sortant à utiliser la connectivité privée.

5. Le reste des étapes pour créer un EAI et l’utiliser pour créer un service sont les mêmes que celles expliquées dans la section précédente (voir Configuration de la sortie réseau).

Pour plus d’informations sur l’utilisation des points de terminaison de connectivité privée, reportez-vous à ce qui suit :

• Gérer les points de terminaison de la connectivité privée : AWS

• Gestion des points de terminaison de la connectivité privée : Azure

• Gérer les points de terminaison de la connectivité privée : Google Cloud

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'