Gestion des tokens sur GitLab : guide complet

Imaginez le scénario suivant : un ingénieur travaille dans une entreprise technologique en pleine croissance et reçoit un appel urgent à 2 heures du matin. Un pipeline de déploiement critique a échoué, et son équipe essaie de comprendre les raisons de cet échec. Après des heures d'investigation, il réalise qu'un utilisateur a révoqué le jeton d'accès personnel d'un ingénieur qui a quitté l'entreprise une semaine plus tôt. Ce token étant lié à plusieurs processus d'automatisation clés, votre système est maintenant dans un état catastrophique. Comment faire en sorte que cette situation ne se reproduise plus ? Découvrez dans cet article toutes les étapes de la gestion des tokens, de leur identification à leur sécurisation. Ce guide complète notre documentation officielle sur les tokens et s'adresse aux administrateurs GitLab, aux équipes de développement et de sécurité qui doivent garantir une gestion efficace et sécurisée des tokens dans le cadre de leurs projets.

Sélection du token adapté au job

Choisir le bon token garantit à la fois la sécurité et des fonctionnalités optimales selon votre cas d'utilisation. Les tokens peuvent servir à authentifier des requêtes API, à automatiser des pipelines CI/CD, à intégrer des outils tiers, à gérer des déploiements, à accéder aux dépôts et bien plus encore. Le graphique ci-dessus illustre un cas d'utilisation classique lié à la propriété d'un seul utilisateur. Pour plus d'informations, consultez notre documentation sur les rôles et autorisations des utilisateurs dans chaque espace de nommage (utilisateur/groupe) au sein de votre instance ou groupe principal. Voici quelques exemples d'utilisation :

• Les jetons d'accès personnel (PAT) peuvent être utilisés lorsque l'accès personnel et les autorisations d'un utilisateur sont requis. Dans ce cas, les identifiants de connexion suivent le statut et les autorisations du compte de l'utilisateur, y compris sa révocation si le compte perd l'accès à un projet ou à un groupe spécifique (ou est entièrement bloqué).
• Les tokens d'accès au projet/groupe (PrAT / GrAT) sont recommandés lorsque l'accès doit être limité aux ressources d'un projet/groupe spécifique. Ainsi, tout utilisateur disposant d'un PrAT/GrAT peut accéder à ces ressources via des mécanismes gérés par des portées attribuées.

Types de tokens

Voici la liste des tokens GitLab, avec leurs préfixes par défaut et le principal cas d'utilisation associé. Pour plus de détails, consultez la page de présentation des tokens GitLab.

Tokens	Préfixe	Description
Jeton d'accès personnel	glpat	Accès aux données propres à l'utilisateur
Token OAuth 2.0	gloas	Authentification à l'aide du protocole OAuth2.0 pour des intégrations tierces
Token d'emprunt d'identité	glpat	Possibilité d'agir au nom d'un autre utilisateur à des fins d'administration
Token d'accès au projet	glpat	Accès aux données d'un projet spécifique
Token d'accès au groupe	glpat	Accès aux données d'un groupe spécifique
Token de déploiement	gldt	Accès aux images d'un registre de conteneurs pour cloner ou effectuer un push/pull sans identifiants utilisateur ni mot de passe
Clés de déploiement	N/A	Accès en lecture seule ou en lecture-écriture aux dépôts
Token d'accès au runner	glrt	Authentification des GitLab Runners
Token de job CI/CD	glcbt	Automatisation des processus CI/CD
Token de déclenchement	glptt	Déclenchement manuel ou automatique des pipelines
Token de flux	glft	Authentification de l'accès aux flux de paquets/RSS
Token d'e-mail entrant	glimt	Traitement des e-mails entrants
Token GitLab Agent for Kubernetes	glagent	Gestion des clusters Kubernetes via GitLab Agent
Tokens SCIM	glsoat	Activation des intégrations SCIM pour le provisionnement des utilisateurs
Token client pour feature flags	glffct	Activation automatisée des feature flags
Token de webhook	N/A	Token de secret défini par l'utilisateur pour sécuriser les charges utiles des webhooks et vérifier que les requêtes proviennent de GitLab

Identification des tokens utilisés

Inventaire des identifiants de connexion

Avec GitLab Ultimate, les administrateurs (GitLab Self-Managed) et les propriétaires de groupe principal (GitLab.com, à partir de la version 17.5) peuvent surveiller les identifiants de connexion dans leur espace de nommage. Cet inventaire permet de suivre les détails des tokens, notamment :

• Le type de tokens * Les tokens disponibles sur GitLab.com * Les tokens disponibles sur GitLab Self-Managed * Les comptes utilisateurs associés * Les portées des tokens, ainsi que leur date de création et d'expiration * Les adresses IP des derniers tokens utilisés (à partir de GitLab 17.10) * Le filtrage des tokens en fonction des paramètres définis par l'utilisateur * La possibilité de révoquer et de procéder à une rotation de ces tokens Tenir correctement un inventaire des identifiants de connexion permet d'identifier les tokens avec des autorisations excessives et ceux dont la rotation est requise, ce qui garantit un workflow sécurisé et efficace.

#### API dédiée pour l'inventaire des identifiants En complément de l'interface utilisateur, une API d'inventaire des identifiants de connexion permet d’accéder à cet inventaire via le nouveau [point de terminaison](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project) /group/:id/manage. Les identifiants de connexion accessibles sous ce point de terminaison sont réservés aux [comptes utilisateurs Entreprise](https://docs.gitlab.com/ee/user/enterprise_user/) ayant souscrit un abonnement GitLab. Ils ne peuvent être consultés que par le propriétaire du groupe principal du projet de l'entreprise concernée. Voici à quoi pourrait ressembler un appel API à l'avenir : ```console curl --header "PRIVATE-TOKEN: " curl --header "PRIVATE-TOKEN: " "https://verified_domain.com/api/v4/groups//manage/personal_access_tokens" ``` ### API GitLab L'API GitLab vous permet de répertorier et de gérer les tokens automatiquement (à l'aide de scripts ou d'applications) au sein de votre entreprise. Les points de terminaison clés liés à l'authentification prennent en charge [différents types de tokens](https://docs.gitlab.com/ee/api/rest/authentication.html), notamment les jetons d'accès personnel, les tokens d'accès au groupe, les tokens de job CI/CD, entre autres. Voici un exemple d'utilisation d'un jeton d'accès personnel qui répertorie tous les projets visibles sur GitLab pour l'utilisateur authentifié : ```console curl --header "PRIVATE-TOKEN: " "https://gitlab.example.com/api/v4/projects" ``` Regardez cette vidéo et découvrez comment effectuer des appels à l'API GitLab.

### Identification de l’utilisation des tokens Vous pouvez identifier de différentes manières les emplacements ou les contextes dans lesquels les tokens sont utilisés : * Depuis **Paramètres utilisateur > [Jetons d'accès](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)** * Dans l'inventaire des identifiants de connexion * Dans les événements d'audit * Via l'API Les informations sur l'utilisation des tokens sont mises à jour toutes les 10 minutes pour **last_used** et toutes les minutes pour **last_used_ip**. La possibilité d'afficher les adresses IP a été introduite dans GitLab 17.9 et est contrôlée par le feature flag **:pat_ip**. Suivez ces [étapes pour afficher la dernière fois où un token a été utilisé](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used), ainsi que ses cinq dernières adresses IP distinctes.  ## Gestion des tokens dans l'API et l'interface utilisateur de GitLab Le tableau suivant répertorie des vidéos qui présentent plusieurs créations de tokens dans l'interface utilisateur et leur utilisation via l'API. | Tokens | UI GitLab | API GitLab | | ----------------------- | --------- | ---------- | | Jeton d'accès personnel | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=3) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=43) | | Token d'accès au groupe | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=120) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=157) | | Token d'accès au projet | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=254) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=285) | ## Gestion de la rotation et de l'expiration des tokens La mise en œuvre d'une rotation des tokens et de règles d'expiration strictes permet de réduire les risques de compromission et de garantir la conformité aux normes de sécurité. Une rotation régulière et des expirations contrôlées empêchent que les identifiants de connexion obsolètes ne deviennent des failles de sécurité. Auparavant, les tokens d'accès au groupe et au projet arrivés à expiration étaient automatiquement supprimés, ce qui compliquait les audits et les analyses de résultats des scans de sécurité en raison de l'absence d'historique de ces tokens inactifs. Pour remédier à ce problème, une [fonctionnalité](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) a introduit la conservation dans l'interface utilisateur des enregistrements de tokens d'accès au groupe et au projet inactifs pendant 30 jours après leur expiration. Cette amélioration permet aux équipes de suivre l'utilisation, l'expiration et la révocation des tokens et offre ainsi une meilleure conformité et un meilleur contrôle. Pour gérer de manière proactive la rotation et l'expiration de vos tokens, procédez comme suit : * Régénérez activement vos tokens via l'interface utilisateur ou l'API. Si vous utilisez l'API, tenez compte du mécanisme de sécurité de [détection automatique de la réutilisation des tokens](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection). * Définissez une [limite de durée de validité maximale](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) à l'échelle de l'instance pour les tokens d'accès. ### API de rotation des tokens Jusqu'à la version GitLab 17.7, les utilisateurs devaient effectuer une rotation automatique des tokens d'accès exclusivement via l'API. Cette fonctionnalité est maintenant disponible dans l'interface utilisateur. Pour en savoir plus, regardez les vidéos dans le tableau ci-dessous ou consultez notre [documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui). ### Extraits de code pour la rotation des tokens Le tableau suivant regroupe des vidéos expliquant le processus de rotation des tokens dans GitLab. | Tokens | Prérequis | UI GitLab | API GitLab | | ----------------------- | --------- | --------- | ---------- | | Jeton d'accès personnel | Portée : API | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=76) | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=92) | | Token d'accès au groupe | Portée : API et rôle(s) : propriétaire | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=203) | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=214) | | Token d'accès au projet | Portée : API et rôle(s) : propriétaire, chargé de maintenance | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=335) | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) et [vidéo](https://youtu.be/v5Nj3Jy4vaI?t=349) | ## Bonnes pratiques de gestion des tokens ### Principe de moindre privilège Atténuez les risques en limitant les autorisations attribuées aux tokens à celles strictement nécessaires à leurs tâches respectives. Vous pourrez ainsi anticiper et résoudre de manière proactive les points de défaillance de vos systèmes. Pour ce faire, procédez comme suit : * Sélectionnez le token adapté au job. Consultez l'organigramme en cas de besoin. * Attribuez uniquement les portées nécessaires lors de la création d'un token. Par exemple, utilisez des portées en lecture seule pour les tokens employés à des fins d'audit. Consultez notre documentation sur les [rôles](https://docs.gitlab.com/ee/user/permissions.html#roles). * Évitez d'accorder des privilèges d'administrateur, sauf si cela est explicitement requis. * Appliquez une [durée de validité](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1) par défaut à l'échelle de l'instance. * Examinez et auditez régulièrement les autorisations octroyées aux tokens pour vous assurer de leur adéquation avec les besoins opérationnels actuels. * Révoquez les tokens une fois leur tâche terminée. ### Comptes de service Les [comptes de service](https://docs.gitlab.com/ee/user/profile/service_accounts.html) associent les tokens à des entités non humaines, ce qui permet de les distinguer des comptes d'utilisateurs et de réduire la dépendance à des utilisateurs spécifiques. Au lieu d'utiliser des comptes personnels pour générer des tokens à des fins d'automatisation, créez des comptes de service avec des portées limitées. Voici les principaux avantages : * Utilisation de tokens de compte de service dans les pipelines CI/CD pour éviter les perturbations causées par les modifications de compte d'utilisateur * Automatisation des processus de rotation, sans impact sur les comptes personnels * Suivi ciblé et piste d'audit plus clairs des actions entreprises par les comptes de service * Comptes de service [sans date d'expiration](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date) * Aucun [siège de licence](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account) consommé GitLab a lancé une nouvelle [interface utilisateur dédiée aux comptes de service](https://gitlab.com/groups/gitlab-org/-/epics/9965) en complément de leur [création via l'API](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), afin de simplifier leur gestion et celle des tokens associés. Regardez la démo ci-dessous sur l'utilisation automatique des comptes de service.

### Outils de détection des vulnérabilités Tirez parti des outils de sécurité intégrés à la plateforme GitLab pour détecter et atténuer les vulnérabilités associées à l'utilisation des tokens. Pour une protection optimale, il est recommandé d'utiliser l'ensemble de ces outils de manière combinée. * [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) : analyse votre dépôt à la recherche de secrets codés en dur, tels que les tokens d'API, les mots de passe et d'autres informations contenant des données sensibles. Consultez la [liste des secrets détectés](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html). * [Tests statiques de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) : analyse votre code source à la recherche de failles de sécurité et [fournit des rapports intégrés aux merge requests contenant les résultats de l'interface utilisateur](https://docs.gitlab.com/ee/user/application_security/sast/#features), entre autres fonctionnalités. * [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) : assure que les bibliothèques tierces utilisées dans votre projet ne présentent pas de vulnérabilités liées aux tokens. ### Journaux d'audit et surveillance Veillez à l'intégrité de vos tokens en examinant régulièrement les journaux d'audit et les données d'utilisation des tokens au niveau de l'instance et/ou du groupe. * [Événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html) : activez la journalisation des événements d'audit dans GitLab pour suivre les activités liées aux tokens, telles que la création, l'utilisation, la révocation et les appels API suspects (paramètres non autorisés dans les journaux, déclenchements répétés du limiteur de débit). * [Liste des adresses IP autorisées](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions) : permet d'empêcher qu'un utilisateur malveillant masque ses activités derrière plusieurs adresses IP. * [Alertes](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) : configurez des alertes pour les activités inhabituelles (déclenchement d'une remontée d'alerte d'incident lors des rotations d'astreinte ou création d'incidents). * [Inventaire des identifiants de connexion](https://docs.gitlab.com/ee/administration/credentials_inventory.html) : contrôlez l'ensemble des tokens d'accès disponibles avec la possibilité de les révoquer si nécessaire. * [Notifications](https://docs.gitlab.com/ee/user/profile/notifications.html) : gérez de manière proactive tous les e-mails de notification d'expiration de tokens (d'accès au groupe/projet et personnel) que vous recevez. Suite aux retours de nos clients, cette fonctionnalité a été étendue pour inclure des notifications à 30 jours et 60 jours, en plus de la notification par défaut à 7 jours. * [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook) : les webhooks de tokens d'accès peuvent être configurés sur les groupes et les projets pour envoyer des événements d'expiration de tokens à sept jours. Cette fonctionnalité a également été étendue pour inclure des notifications à 30 jours et 60 jours via le feature flag **:extended_expiry_webhook_execution_setting** (désactivé par défaut). ## Perspectives Compte tenu du vaste catalogue de tokens de GitLab, nous avons [prévu](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) une consolidation axée sur la durée de validité, les portées affinées, la gestion cohérente et l'utilisation. En ce qui concerne les fonctionnalités liées aux tokens, nous avons identifié les priorités suivantes : une interface utilisateur complète pour les comptes de service, l'ajout de nouveaux types d'identifiants dans l'inventaire des identifiants de connexion et une amélioration de l'audit des tokens et comptes de service. > [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/free-trial/) et commencez à utiliser les fonctionnalités de gestion des tokens.