Mise en réseau des services¶

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