Secrets et authentification API externe¶

Cette rubrique fournit des concepts sur l’authentification API externe et les secrets.

Dans ce chapitre :

Vue d’ensemble¶

L’authentification API externe fournit une voie pour s’authentifier auprès d’un service hébergé en dehors de Snowflake. La requête API d’accès au service nécessite que la requête API soit authentifiée. Snowflake prend en charge les méthodes d’authentification suivantes lors de l’utilisation de l’authentification API externe :

Authentification de base.
OAuth avec flux d’accord de code.
OAuth ave flux d’identifiants de connexion client.

Snowflake prend en charge l’authentification de base (c’est-à-dire le nom d’utilisateur et le mot de passe) dans l’en-tête de requête API comme spécifié dans RFC 7617, où les identifiants de connexion sont encodés à l’aide de Base64. De même, Snowflake prend en charge OAuth 2.0 comme spécifié dans RFC 6749. Dans Snowflake, les identifiants de connexion d’authentification sont stockés et accessibles en toute sécurité à partir d’un objet appelé secret. Le secret est utilisé avec un connecteur pour accéder au service en dehors de Snowflake, tel que le connecteur Snowflake pour ServiceNow. Une intégration de sécurité pour l”authentification API externe permet à Snowflake de se connecter au service hébergé en dehors de Snowflake lors de l’utilisation des flux OAuth.

Un secret est un objet au niveau du schéma qui stocke des informations sensibles, limite l’accès aux informations sensibles à l’aide de RBAC et est chiffré à l’aide de la hiérarchie de chiffrement de clé de Snowflake. Les informations présentes dans l’objet secret sont chiffrées à l’aide d’une clé de la hiérarchie de clés. Une fois que vous avez créé un secret, seuls les composants Snowflake dédiés tels que les intégrations et les fonctions externes peuvent lire les informations sensibles.

Par exemple, une fonction externe doit accéder au secret et le lire pour transmettre les identifiants de connexion d’authentification dans un en-tête d’autorisation API afin d’effectuer une requête API au service en dehors de Snowflake. La liaison du secret à la fonction externe se produit pendant le processus d’installation du connecteur. Cependant, si un utilisateur exécute une opération DESCRIBE SECRET sur le secret, la valeur du mot de passe stockée dans le secret n’est jamais exposée.

Snowflake fournit une gestion centralisée et un contrôle d’accès des identifiants de connexion utilisés pour l’authentification API dans le secret. Vous pouvez implémenter la séparation des tâches (c’est-à-dire SoD) pour la gestion du secret et les rôles associés à la gestion du connecteur. Le connecteur n’a besoin d’utiliser que le nom secret et les utilisateurs auxquels sont attribués les rôles de connecteur n’ont pas besoin d’afficher les informations sensibles stockées dans le secret.

Gestion des secrets¶

Snowflake fournit les commandes suivantes pour gérer l’objet secret :

Snowflake prend en charge les privilèges suivants pour déterminer si les utilisateurs peuvent créer, utiliser et posséder des secrets.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Privilège	Utilisation
CREATE	Permet de créer un nouveau secret dans un schéma.
USAGE	Permet d’utiliser un secret.
OWNERSHIP	Transfère la propriété du secret, ce qui permet d’en avoir le contrôle total. Nécessaire pour modifier la plupart des propriétés d’un secret.

Le tableau suivant résume la relation entre les opérations de commande de secrets et leurs privilèges nécessaires.

Opération	Privilège
CREATE SECRET	Un rôle avec le privilège USAGE sur la base de données et le schéma parents avec le privilège CREATE SECRET dans le même schéma.
ALTER SECRET	Un rôle avec le privilège OWNERSHIP sur le secret.
DROP SECRET	Un rôle avec le privilège OWNERSHIP sur le secret.
DESCRIBE SECRET	Un rôle avec le privilège USAGE sur le secret.
SHOW SECRETS	Un rôle avec le privilège USAGE sur le secret.
USE SECRET	Un rôle avec le privilège USAGE sur le secret. Ce privilège est requis pour le rôle créant la fonction externe et appelant la fonction externe lors de l’exécution de la requête, si le secret doit être utilisé avec une fonction externe.

Utilisation de l’authentification API externe et des secrets¶

Pour des exemples représentatifs, voir :

En outre, vous pouvez répliquer des secrets à l’aide de la réplication de comptes. Pour plus de détails, voir Réplication et secrets.