Principaux avantages
Principaux avantages des comptes de service :- Aucune consommation de licence : les comptes de service ne consomment aucune licence utilisateur.
- Clés API dédiées : des identifiants d’authentification sécurisés pour les flux de travail automatisés.
- Attribution de l’utilisateur : possibilité d’attribuer les runs automatisés à des utilisateurs humains.
- Prêt pour l’entreprise : conçu pour l’automatisation en production à grande échelle.
- Opérations déléguées : les comptes de service agissent pour le compte de l’utilisateur ou de l’organisation qui les crée.
Aperçu
Les comptes de service permettent d’automatiser en toute sécurité les flux de travail W&B, sans recourir à des identifiants d’authentification personnels ni à des identifiants codés en dur. Vous pouvez les créer selon deux portées :- Limité à l’organisation : créé par les administrateurs de l’organisation, avec un accès à toutes les équipes.
- À portée d’équipe : créé par les administrateurs d’équipe, avec un accès restreint à une équipe donnée.
Un compte de service limité à l’organisation ne doit pas être confondu avec une clé API d’organisation. Un compte de service est une identité non humaine qui détient ses propres clés. Une clé API d’organisation appartient à une personne et authentifie cette personne au sein d’une seule organisation.
- Pipelines CI/CD : consigner automatiquement les runs d’entraînement de modèles depuis GitHub Actions, GitLab CI ou Jenkins.
- Jobs planifiés : réentraînement nocturne de modèles, runs d’évaluation périodiques ou flux de travail de validation des données.
- Surveillance en production : journaliser les métriques d’inférence et les performances des modèles depuis les systèmes de production.
- Jupyter notebooks : notebooks partagés dans des environnements JupyterHub ou Google Colab.
- Jobs Kubernetes : flux de travail automatisés exécutés dans des clusters Kubernetes.
- Airflow/Prefect/Dagster : outils d’orchestration de pipelines de ML.
Les comptes de service sont disponibles sur le Cloud dédié, sur les instances autogérées disposant d’une licence Enterprise, ainsi que pour les comptes Enterprise sur le Cloud mutualisé.
Comptes de service limités à l’organisation
Utilisez un compte de service limité à l’organisation lorsque votre automatisation doit lire ou écrire dans des projets appartenant à plusieurs équipes. Les comptes de service limités à une organisation disposent d’autorisations de lecture et d’écriture sur tous les projets de l’organisation, quelle que soit l’équipe, à l’exception des projets restreints. Pour qu’un compte de service limité à l’organisation puisse accéder à un projet restreint, un administrateur de ce projet doit d’abord l’y ajouter explicitement.Créer un compte de service limité à l’organisation
Pour créer un compte de service limité à l’organisation et une clé API :- Connectez-vous à W&B.
- Cliquez sur l’icône de votre profil utilisateur, puis accédez à Service Accounts :
- Cloud dédié ou autogéré : cliquez sur Organization Dashboard, puis sur Service Accounts.
- Cloud mutualisé : cliquez sur Service Accounts.
- Cliquez sur Create service account.
- Indiquez un nom et sélectionnez une équipe par défaut.
- Cliquez sur Create.
- Repérez le compte de service que vous venez de créer, cliquez sur le menu action (), puis sur Create API key.
- Indiquez un nom pour la clé API, puis cliquez sur Create.
- Copiez la clé API et conservez-la en lieu sûr.
- Cliquez sur Done.
Un compte de service limité à l’organisation doit avoir une équipe par défaut, même s’il a accès aux projets non restreints de toutes les équipes de l’organisation. Cela évite qu’une charge de travail échoue si la variable
WANDB_ENTITY n’est pas définie dans l’environnement de votre entraînement de modèle ou de votre application d’IA générative. Pour utiliser un compte de service limité à l’organisation avec un projet d’une autre équipe, vous devez définir la variable d’environnement WANDB_ENTITY sur cette équipe.Comptes de service à portée d’équipe
Utilisez un compte de service à portée d’équipe lorsque vous souhaitez limiter une automatisation aux projets d’une seule équipe, conformément au principe du moindre privilège. Un compte de service à portée d’équipe dispose d’un accès en lecture et en écriture à tous les projets de son équipe, à l’exception des projets restreints de cette équipe. Pour qu’un compte de service à portée d’équipe puisse accéder à un projet restreint, un administrateur de ce projet doit explicitement l’y ajouter.Sur le Cloud dédié et les déploiements autogérés v0.83.0+, les administrateurs peuvent empêcher la création de comptes de service à portée d’équipe en définissant la variable d’environnement
GORILLA_DISABLE_TEAM_SERVICE_ACCOUNT_CREATION sur true sur l’instance. Voir Configuration IAM avancée.Créer un compte de service à portée d’équipe
Pour créer un compte de service à portée d’équipe et une clé API :- Dans les paramètres de votre équipe, cliquez sur Service Accounts.
- Cliquez sur New Team Service Account.
- Saisissez un nom pour le compte de service.
- Définissez Authentication Method sur Generate API key (par défaut). Si vous sélectionnez Federated Identity, le compte de service ne peut pas posséder de clés API.
- Cliquez sur Create.
- Repérez le compte de service que vous avez créé, cliquez sur son menu action (), puis sur Create API key.
- Saisissez un nom pour la clé API, puis cliquez sur Create.
- Copiez la clé API et conservez-la en lieu sûr.
- Cliquez sur Done.
Créer des clés API supplémentaires pour un compte de service
Pour créer une clé API appartenant à un compte de service :- Dans les paramètres de votre équipe ou de votre organisation, accédez à l’onglet Service Accounts.
- Trouvez le compte de service dans la liste.
- Cliquez sur le menu action (), puis sur Create API key.
- Saisissez un nom pour la clé API, puis cliquez sur Create.
- Copiez immédiatement la clé API affichée et conservez-la en lieu sûr.
- Cliquez sur Done.
Supprimer une clé API de compte de service
Pour supprimer une clé API appartenant à un compte de service d’organisation ou d’équipe :- Accédez à Organization settings, puis cliquez sur API Keys.
- Repérez la clé API. La liste comprend toutes les clés API appartenant aux comptes de service d’organisation et d’équipe. Vous pouvez rechercher ou filtrer les clés par nom ou par ID, et les trier selon n’importe quelle colonne.
- Cliquez sur le bouton de suppression.
WANDB_USERNAME ou WANDB_USER_EMAIL ne fonctionne pas, sauf si l’utilisateur référencé fait partie de l’équipe parente du compte de service.
Comptes de service externes
Si vous préférez émettre des identifiants d’authentification via votre propre fournisseur d’identité plutôt que de gérer des clés API natives W&B, utilisez des comptes de service externes. Outre les comptes de service intégrés, W&B prend également en charge, avec le SDK et la CLI W&B, les comptes de service externes à portée d’équipe, grâce à la fédération d’identités avec des fournisseurs d’identité (IdP) qui émettent des jetons Web JSON (JWT).Bonnes pratiques
Après avoir créé les comptes de service dont vous avez besoin, suivez ces recommandations pour garantir une utilisation sécurisée et efficace des comptes de service dans votre organisation :- Utiliser un gestionnaire de secrets : stockez les clés API des comptes de service dans un système de gestion des secrets sécurisé (par exemple, AWS Secrets Manager, HashiCorp Vault ou Azure Key Vault) plutôt que dans des fichiers de configuration en texte brut.
- Principe du moindre privilège : dans la mesure du possible, créez des comptes de service à portée d’équipe plutôt que des comptes limités à l’organisation, afin de limiter l’accès aux seuls projets nécessaires.
- Un compte de service par cas d’usage : créez des comptes de service distincts pour les différents flux de travail d’automatisation (par exemple, un pour la CI/CD, un autre pour le réentraînement planifié) afin de faciliter les audits et de permettre un contrôle d’accès granulaire.
- Audits réguliers : passez régulièrement en revue les comptes de service actifs et supprimez ceux qui ne sont plus utilisés. Consultez les journaux d’audit pour surveiller l’activité des comptes de service.
-
Gestion sécurisée des clés API :
- Ne commitez jamais de clés API dans un système de gestion de versions.
- Utilisez des variables d’environnement pour transmettre les clés aux applications.
- Faites pivoter les clés si elles ont été exposées accidentellement.
-
Conventions de nommage : utilisez des noms descriptifs qui indiquent la fonction du compte de service :
- Recommandé :
ci-model-training,nightly-eval-pipeline,prod-inference-monitor - À éviter :
service-account-1,test-sa,temp
- Recommandé :
-
Attribution de l’utilisateur : lorsque plusieurs membres de l’équipe utilisent le même flux de travail d’automatisation, définissez
WANDB_USERNAMEouWANDB_USER_EMAILpour savoir qui a déclenché chaque run : -
Configuration de l’environnement : pour les comptes de service à portée d’équipe, définissez toujours
WANDB_ENTITYafin que les runs soient journalisés dans la bonne équipe : - Gestion des erreurs : mettez en place une gestion des erreurs et des alertes appropriées en cas d’échec d’authentification, afin d’identifier rapidement les problèmes liés aux identifiants des comptes de service.
-
Documentation : tenez à jour une documentation indiquant :
- Les comptes de service existants et leur fonction.
- Les systèmes ou flux de travail qui utilisent chaque compte de service.
- Les coordonnées de l’équipe responsable de chaque compte.
Dépannage
Si un compte de service ne se comporte pas comme prévu, consultez les problèmes courants et leurs solutions ci-dessous :- Erreurs « Unauthorized » : vérifiez que la clé API est correctement définie et que le compte de service a accès au projet cible.
- Les runs n’apparaissent pas : vérifiez que
WANDB_ENTITYcorrespond au bon nom d’équipe. - L’attribution de l’utilisateur ne fonctionne pas : assurez-vous que l’utilisateur indiqué dans
WANDB_USERNAMEest membre de l’équipe. - Accès refusé aux projets restreints : ajoutez explicitement le compte de service à la liste d’accès du projet restreint.