Introduction

Depuis plusieurs mois, Snowflake a amorcé la fin progressive du type d’utilisateur LEGACY_SERVICE, utilisé historiquement pour les comptes de service authentifiés par mot de passe. Cette méthode, jugée moins sécurisée, sera dépréciée à partir de novembre 2025.

Concrètement, cela signifie que tous les utilisateurs de type LEGACY_SERVICE devront être migrés vers le type SERVICE avant cette échéance, sous peine de voir leurs connexions échouer.

Cette évolution s’inscrit dans la stratégie de Snowflake visant à renforcer la sécurité des accès et à généraliser l’authentification sans mot de passe (par clés, OAuth, ou intégrations d’identité). Si votre environnement Snowflake comporte encore des comptes LEGACY_SERVICE, c’est le moment d’anticiper la transition pour éviter toute interruption de vos pipelines ou intégrations automatisées.

🔍 LEGACY_SERVICE vs SERVICE : quelle différence ?

Type d’utilisateur	Authentification	Recommandé ?	Notes
LEGACY_SERVICE	Mot de passe (single factor)	❌ Non	Ancien modèle toléré pour compatibilité ; sera déprécié fin 2025
SERVICE	Clé publique/privée, OAuth, ou intégration avec un fournisseur d’identité (IdP)	✅ Oui	Nouveau standard sécurisé pour les comptes de service

👉 En résumé : SERVICE est la version moderne, sans mot de passe, qui offre une sécurité renforcée et une meilleure compatibilité avec les politiques d’accès unifiées (IAM, SSO, rotation automatique des clés, etc.).

🧭 Comment identifier vos comptes LEGACY_SERVICE

Exécutez la requête suivante dans votre data warehouse Snowflake pour lister les utilisateurs concernés :

sql
SELECT name, type
FROM snowflake.account_usage.users
WHERE type = 'LEGACY_SERVICE';

Cela vous permettra de repérer les utilisateurs à migrer.

(Si la colonne type n’existe pas encore sur votre version, vérifiez les métadonnées dans SHOW USERS;.)

🔐 Création d’un utilisateur SERVICE sécurisé

La création d’un utilisateur de type SERVICE dans Snowflake s’accompagne de deux étapes essentielles :

la génération d’une paire de clés RSA (publique/privée) utilisée pour l’authentification,

la mise en place d’une Network Policy pour restreindre les adresses IP autorisées.

1️⃣ Générer la clé publique et privée (bash)

Exécutez les commandes suivantes sur votre poste ou serveur sécurisé :

bash
# generate private key with an encryption password
openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out snowflake_rsa_key.p8

# generate public key referencing the private key
# need the private key encryption password
openssl rsa -in rsa_key.p8 -pubout -out snowflake_rsa_key.pub

📁 Résultat :

snowflake_rsa_key.p8 → clé privée (à stocker de façon sécurisée, non partagée)

snowflake_rsa_key.pub → clé publique (à enregistrer dans Snowflake)

💡

Stockez la clé privée dans un secret manager (AWS Secrets Manager, GCP Secrets Manager, HashiCorp Vault, etc.) plutôt que sur disque.

2️⃣ Créer l’utilisateur de type SERVICE dans Snowflake

Connectez-vous avec un rôle disposant des droits d’administration (ex : SECURITYADMIN), puis exécutez :

sql
USE ROLE SECURITYADMIN;

CREATE USER my_service_user
  TYPE = SERVICE
  RSA_PUBLIC_KEY = '<paste here the content of snowflake_rsa_key.pub>'
  DEFAULT_ROLE = MY_SERVICE_ROLE
  DEFAULT_WAREHOUSE = MY_WAREHOUSE
  DEFAULT_NAMESPACE = MY_DB.MY_SCHEMA
  COMMENT = 'Service account used for the XYZ tool';

👉 Cet utilisateur ne nécessitera aucun mot de passe, car il s’authentifie exclusivement via la clé privée correspondante (snowflake_rsa_key.pem).

3️⃣ Créer une Network Policy pour restreindre les IPs autorisées

Afin de sécuriser davantage les connexions, il est fortement recommandé d’associer une Network Policy au compte SERVICE. Cette policy permet de whitelister uniquement les IPs de votre outil ou environnement d’exécution (ex. Airflow, dbt, Jenkins, etc.) :

sql
USE ROLE ACCOUNTADMIN;

CREATE NETWORK POLICY np_service_tool
  ALLOWED_IP_LIST = ('192.168.10.0/24', '52.14.22.11', '34.217.55.90')
  BLOCKED_IP_LIST = ('0.0.0.0/0')
  COMMENT = 'Allow only the IP addresses of the XYZ service';

Puis, appliquez cette policy à votre utilisateur :

sql
USE ROLE SECURITYADMIN;

ALTER USER my_service_user SET NETWORK_POLICY = np_service_tool;

🔄 Et si votre outil ne supporte pas l’authentification par clé (Key Pair) ?

L’authentification par KeyPair reste la méthode recommandée et la plus sécurisée pour les utilisateurs de type SERVICE dans Snowflake.

Cependant, certains outils ou plateformes d’intégration ne supportent pas encore ce mode de connexion.

Dans ce cas, il est possible d’utiliser OAuth comme alternative, mais cela nécessite de créer une Security Integration dans Snowflake.

Documentation Snowflake : https://docs.snowflake.com/en/user-guide/oauth-intro

✅ Hiérarchie recommandée des méthodes d’authentification

Priorité	Méthode	Description	Quand l’utiliser
🔒 1	Key Pair (RSA)	Authentification forte et sans mot de passe. Les clés peuvent être renouvelées facilement.	Toujours à privilégier pour les comptes de service.
🔁 2	OAuth (Client Credentials Flow)	Authentification basée sur des jetons, via un fournisseur d’identité (IdP) ou l’intégration OAuth native de Snowflake.	À utiliser uniquement si votre outil ne supporte pas le Key Pair.

Dernier délai : fin du support de LEGACY_SERVICE — basculez vers SERVICE dès maintenant ❄