Passer au contenu principal
Un compte de service désigne un utilisateur non humain ou une machine capable d’exécuter automatiquement des tâches courantes dans les projets d’une équipe ou entre plusieurs équipes. Les comptes de service sont idéaux pour les pipelines CI/CD, les tâches d’entraînement automatisées et d’autres flux de travail machine à machine.

​
Principaux avantages

Principaux avantages des comptes de service :
  • Aucune consommation de licence : les comptes de service ne consomment ni licence utilisateur ni autre licence
  • Clés API dédiées : identifiants 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 de Production à grande échelle
  • Opérations déléguées : les comptes de service opèrent pour le compte de l’utilisateur ou de l’organisation qui les crée

​
Aperçu

Les comptes de service offrent un moyen sûr d’automatiser les flux de travail W&B sans utiliser d’identifiants personnels ni d’identifiants codés en dur. Ils peuvent être créés selon deux périmètres :
  • Limité à l’organisation : créés par les administrateurs de l’organisation, avec un accès à l’ensemble des Teams.
  • À portée d’équipe : créés par les Administrateurs d’équipe, avec un accès limité à une équipe spécifique
La clé API d’un compte de service permet d’accéder en lecture et en écriture aux projets relevant du périmètre de ce compte. Cela permet une gestion centralisée des flux de travail automatisés pour le suivi des expériences dans W&B Models ou la journalisation des traces dans W&B Weave. Les comptes de service sont particulièrement utiles pour :
  • Pipelines CI/CD : journaliser 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 de la production : journaliser les métriques d’inférence et les performances du modèle à partir des systèmes de production
  • Notebooks Jupyter : notebooks partagés dans des environnements JupyterHub ou Google Colab
  • Jobs Kubernetes : flux de travail automatisés exécutés dans des clusters K8s
  • Airflow/Prefect/Dagster : outils d’orchestration de pipelines ML
Les comptes de service sont disponibles sur Cloud dédié, sur les instances autogérées avec une licence Enterprise, ainsi que pour les comptes entreprise sur le Cloud mutualisé.

​
Comptes de service limités à l’organisation

Les comptes de service limités à l’organisation disposent d’autorisations en lecture et en écriture dans tous les Projects de l’organisation, quelle que soit la team, à l’exception des projets Restricted. Avant qu’un compte de service limité à l’organisation puisse accéder à un projet Restricted, un administrateur de ce projet doit explicitement ajouter le compte de service au projet.

​
Créer un compte de service limité à l’organisation

Pour créer un compte de service limité à l’organisation et une clé API :
  1. Connectez-vous à W&B, cliquez sur l’icône de votre profil, puis :
    • Cloud dédié ou Autogéré : cliquez sur Tableau de bord de l’organisation, puis sur Comptes de service.
    • Cloud mutualisé : cliquez sur Comptes de service.
  2. Cliquez sur Créer un compte de service.
  3. Saisissez un nom et sélectionnez une équipe par défaut.
  4. Cliquez sur Créer.
  5. Repérez le compte de service que vous venez de créer.
  6. Cliquez sur le menu d’action (...), puis sur Créer une clé API.
  7. Saisissez un nom pour la clé API, puis cliquez sur Créer.
  8. Copiez la clé API et conservez-la en lieu sûr.
  9. Cliquez sur Terminé.
La clé API complète n’est affichée qu’une seule fois, au moment de sa création. Une fois la boîte de dialogue fermée, vous ne pourrez plus voir la clé API complète. Seul l’ID de la clé (la première partie de la clé) reste visible dans vos paramètres. Si vous perdez la clé API complète, vous devrez créer une nouvelle clé API.
Un compte de service limité à l’organisation nécessite qu’une équipe par défaut soit définie, même s’il a accès aux projets non restreints appartenant à toutes les équipes de l’organisation. Cela permet d’éviter qu’une charge de travail échoue si la variable WANDB_ENTITY n’est pas définie dans l’environnement pour l’entraînement de votre modèle ou votre application d’IA générative. Pour utiliser un compte de service limité à l’organisation pour 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

Un compte de service à portée d’équipe peut lire et écrire dans tous les projets de son équipe, sauf dans les projets restreints de cette même équipe. Avant qu’un compte de service à portée d’équipe puisse accéder à un projet restreint, un administrateur de ce projet doit explicitement ajouter le compte de service au projet.

​
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 :
  1. Dans les paramètres de votre équipe, cliquez sur Service Accounts.
  2. Cliquez sur New Team Service Account.
  3. Saisissez un nom pour le compte de service.
  4. Définissez la méthode d’authentification sur Generate API key (par défaut). Si vous sélectionnez Federated Identity, le compte de service ne peut pas détenir de clés API.
  5. Cliquez sur Create.
  6. Repérez le compte de service que vous venez de créer.
  7. Cliquez sur le menu d’action (...), puis sur Create API key.
  8. Saisissez un nom pour la clé API, puis cliquez sur Create.
  9. Copiez la clé API et conservez-la en lieu sûr.
  10. Cliquez sur Done.
La clé API complète n’est affichée qu’une seule fois, au moment de sa création. Une fois la boîte de dialogue fermée, vous ne pourrez plus voir la clé API complète. Seul l’ID de la clé (la première partie de la clé) reste visible dans vos paramètres. Si vous perdez la clé API complète, vous devrez créer une nouvelle clé API.

​
Créez des clés API supplémentaires pour un compte de service

Pour créer une clé API associée à un compte de service :
  1. Accédez à l’onglet Service Accounts dans les paramètres de votre équipe ou de votre organisation.
  2. Recherchez le compte de service dans la liste.
  3. Cliquez sur le menu d’action (...), puis sur Create API key.
  4. Saisissez un nom pour la clé API, puis cliquez sur Create.
  5. Copiez immédiatement la clé API affichée et stockez-la en lieu sûr.
  6. Cliquez sur Done.
Vous pouvez créer plusieurs clés API pour un même compte de service afin de prendre en charge différents environnements ou flux de travail.
La clé API complète n’est affichée qu’une seule fois, au moment de sa création. Une fois la boîte de dialogue fermée, vous ne pourrez plus voir la clé API complète. Seul l’ID de la clé (la première partie de la clé) reste visible dans vos paramètres. Si vous perdez la clé API complète, vous devrez créer une nouvelle clé API.

​
Supprimer une clé API de compte de service

Pour supprimer une clé API appartenant à un compte de service d’une organisation ou d’une équipe :
  1. Accédez à Organization settings, puis cliquez sur API Keys.
  2. Repérez la clé API. La liste contient toutes les clés API appartenant à des comptes de service d’organisation et d’équipe. Vous pouvez effectuer une recherche ou appliquer un filtre par nom de clé ou ID, et trier selon n’importe quelle colonne.
  3. Cliquez sur le bouton Delete.
Si vous ne configurez pas d’équipe dans l’environnement d’entraînement du modèle ou de l’application d’IA générative qui utilise un compte de service à portée d’équipe, les runs du modèle ou les traces Weave sont consignés dans le projet indiqué au sein de l’équipe parente du compte de service. Dans ce cas, l’attribution de l’utilisateur à l’aide des variables 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.
Un compte de service à portée d’équipe ne peut pas consigner de runs dans un projet d’équipe ou à portée restreinte d’une équipe autre que son équipe parente, mais il peut consigner des runs dans un projet à visibilité ouverte au sein d’une autre équipe.

​
Comptes de service externes

En plus des comptes de service intégrés, W&B prend également en charge, via le SDK et la CLI W&B, des comptes de service externes à portée d’équipe, en utilisant la fédération d’identités avec des fournisseurs d’identité (IdP) capables d’émettre des jetons Web JSON (JWT).

​
Bonnes pratiques

Suivez ces recommandations pour garantir une utilisation sécurisée et efficace des comptes de service dans votre organisation :
  • Utilisez un gestionnaire de secrets : stockez les clés API des comptes de service dans un système sécurisé de gestion des secrets (par ex. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) plutôt que dans des fichiers de configuration en texte brut.
  • Principe du moindre privilège : créez des comptes de service à portée d’équipe lorsque c’est possible, plutôt que des comptes limités à l’organisation, afin de limiter l’accès aux seuls projets nécessaires.
  • Un compte de service distinct par cas d’usage : créez des comptes de service séparés pour différents flux de travail d’automatisation (par ex. un pour le CI/CD, un autre pour le réentraînement planifié) afin d’améliorer la traçabilité et de permettre un contrôle d’accès granulaire.
  • Audits réguliers : examinez périodiquement 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 :
    • N’enregistrez jamais de clés API dans un système de contrôle de version
    • Utilisez des variables d’environnement pour transmettre les clés aux applications
    • Renouvelez les clés si elles sont accidentellement exposées
  • Conventions de nommage : utilisez des noms descriptifs qui indiquent la finalité du compte de service :
    • Bon : ci-model-training, nightly-eval-pipeline, prod-inference-monitor
    • À éviter : service-account-1, test-sa, temp
  • attribution de l’utilisateur : lorsque plusieurs membres de l’équipe utilisent le même flux de travail d’automatisation, définissez WANDB_USERNAME ou WANDB_USER_EMAIL pour suivre qui a déclenché chaque run : 
    export WANDB_API_KEY="<service_account_key>"
export WANDB_USERNAME="john.doe@company.com"
  • Configuration de l’environnement : pour les comptes de service à portée d’équipe, définissez toujours WANDB_ENTITY pour vous assurer que les runs sont enregistrés dans la bonne équipe : 
    export WANDB_ENTITY="ml-team"
export WANDB_PROJECT="production-models"
  • Gestion des erreurs : mettez en place une gestion appropriée des erreurs et des alertes en cas d’échec de l’authentification afin d’identifier rapidement les problèmes liés aux identifiants du compte de service.
  • Documentation : tenez à jour une documentation indiquant :
    • Quels comptes de service existent et à quoi ils servent
    • Quels systèmes/flux de travail utilisent chaque compte de service
    • Les coordonnées de l’équipe responsable de chaque compte

​
Dépannage

Problèmes courants et solutions :
  • Erreurs « Unauthorized » : vérifiez que la clé API est correctement définie et que le compte de service a accès au projet cible
  • Runs qui n’apparaissent pas : vérifiez que WANDB_ENTITY est défini avec le nom d’équipe correct
  • L’attribution de l’utilisateur ne fonctionne pas : assurez-vous que l’utilisateur spécifié dans WANDB_USERNAME est membre de l’équipe
  • Accès refusé aux projets restreints : ajoutez explicitement le compte de service à la liste d’accès du projet restreint