doc-locale/fr-fr/auth/tokens/fine_grained_access_tokens.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Les jetons d'accès personnel affinés ont une portée limitée à l'accès aux ressources et aux permissions spécifiques que vous définissez. Lors de la création du jeton, vous définissez les attributs suivants :
Group and project, User et Global).Pour créer un jeton d'accès personnel affiné :
Un jeton d'accès personnel s'affiche. Enregistrez le jeton d'accès personnel dans un endroit sûr. Après avoir quitté ou actualisé la page, vous ne pourrez plus le consulter.
Les administrateurs peuvent créer un jeton d'accès personnel affiné pouvant emprunter l'identité d'autres utilisateurs via le paramètre sudo de l'API REST.
Seul un administrateur peut créer un jeton avec la fonctionnalité sudo. Un utilisateur non-administrateur qui tente d'en créer un reçoit une erreur.
Un jeton affiné continue d'appliquer ses propres autorisations lors de l'emprunt d'identité. Le jeton ne peut effectuer une action que lorsque les deux conditions suivantes sont remplies :
Ce comportement diffère d'un jeton d'accès personnel hérité avec la portée sudo, qui peut effectuer n'importe quelle action en tant qu'utilisateur dont l'identité est empruntée.
[!warning] Un jeton avec la fonctionnalité sudo peut agir en tant que n'importe quel utilisateur. Limitez ses autorisations et périmètres au strict minimum requis, et stockez-le de manière sécurisée.
Les autorisations qu'un jeton d'accès personnel affiné peut utiliser dépendent du point de terminaison que le jeton appelle :
{{< history >}}
granular_personal_access_tokens_enforcement et granular_personal_access_tokens_enforcement_saas. Désactivés par défaut.{{< /history >}}
Vous pouvez exiger de vos utilisateurs qu'ils adoptent des jetons d'accès personnel affinés après une date d'application spécifiée. Après cette date, les jetons d'accès personnel hérités existants restent listés dans les profils utilisateurs, mais ne peuvent plus être utilisés pour accéder aux ressources.
L'application fonctionne différemment sur GitLab.com et GitLab Self-Managed :
Prérequis :
Sur GitLab.com, l'application s'étend au groupe, à ses sous-groupes et à ses projets, et bloque les jetons d'accès personnel hérités pour l'accès à ces ressources après la date d'application. Les utilisateurs peuvent toujours créer des jetons hérités, mais ces jetons ne peuvent pas accéder aux ressources soumises à l'application pour le groupe.
Ce paramètre n'est pas disponible sur GitLab Self-Managed.
Vous pouvez appliquer les jetons affinés uniquement sur un groupe principal.
Pour appliquer les jetons d'accès personnel affinés pour un groupe principal :
Après la date d'application, les utilisateurs reçoivent une erreur lorsqu'ils tentent d'utiliser un jeton hérité pour accéder aux ressources du groupe principal, de ses sous-groupes ou de ses projets. L'erreur liste le périmètre de ressource et les autorisations dont un jeton affiné a besoin. Par exemple :
Access denied: This operation requires a fine-grained personal access token with the following project permissions: [Project: Read].
Prérequis :
Sur GitLab Self-Managed, l'application s'étend à l'ensemble de l'instance et bloque les utilisateurs dans la création ou la rotation des jetons d'accès personnel hérités après la date d'application. Les utilisateurs ne peuvent créer que des jetons affinés. Les jetons hérités existants continuent de fonctionner jusqu'à leur expiration.
Pour appliquer les jetons d'accès personnel affinés pour l'instance :
Après la date d'application, les utilisateurs reçoivent une erreur lorsqu'ils tentent de créer ou de renouveler un jeton hérité.