Skip to main content

À propos des autorisations pour les packages GitHub

Découvrez comment gérer les autorisations pour vos packages.

Qui peut utiliser cette fonctionnalité ?

GitHub Packages est disponible avec GitHub Free, GitHub Pro, GitHub Free pour les organisations, GitHub Team, GitHub Enterprise Cloud et GitHub Enterprise Server 3.0 ou ultérieur.
GitHub Packages n’est pas disponible pour les référentiels privés appartenant à des comptes qui utilisent des plans par référentiel hérités. Par ailleurs, les comptes utilisant des plans par dépôt hérités ne peuvent pas accéder aux registres qui prennent en charge les autorisations granulaires, car ces comptes sont facturés par dépôt. Pour obtenir la liste des registres prenant en charge les autorisations granulaires, consultez la section « À propos des autorisations pour les packages GitHub ». Pour plus d’informations, consultez « Plans de GitHub ».

Les autorisations pour les packages peuvent être limitées à un utilisateur, à une organisation ou à un dépôt.

Autorisations granulaires pour les packages limités à l’utilisateur/l’organisation

Les packages avec des autorisations granulaires sont délimités à un compte personnel ou à une organisation. Vous pouvez modifier le contrôle d’accès et la visibilité d’un package séparément d’un référentiel connecté (ou lié) à un package.

Les registres GitHub Packages suivants prennent en charge les autorisations granulaires.

  • Container registry
  • Registre npm - Registre NuGet - Registre RubyGems

Autorisations pour les packages limités au dépôt

Un package délimité au dépôt hérite des autorisations et de la visibilité du dépôt dans lequel le package est publié. Vous pouvez trouver un package limité à un référentiel en accédant à la page principale du référentiel et en cliquant sur le lien Packages à droite de la page. Pour plus d’informations, consultez « Connexion d’un dépôt à un package ».

Les registres GitHub Packages suivants prennent uniquement en charge les autorisations limitées au dépôt.

– Registre Docker (docker.pkg.github.com)

  • registre Apache Maven
  • Registre Gradle

Pour autres registres, vous pouvez choisir d’autoriser que les packages soient limités à un utilisateur ou à une organisation, ou liés à un dépôt.

Visibilité et autorisations d’accès pour les packages

Si un package appartient à un registre qui prend en charge les autorisations granulaires, toute personne disposant d’autorisations d’administrateur sur le package peut définir le package sur privé ou public, et peut accorder des autorisations d’accès pour le package qui sont distinctes des autorisations définies au niveau de l’organisation et du dépôt. Pour obtenir la liste des registres prenant en charge les autorisations granulaires, consultez « À propos des autorisations pour les packages GitHub ».

Dans la plupart des registres, pour extraire un package, vous devez vous authentifier avec un personal access token ou GITHUB_TOKEN, que le package soit public ou privé. Toutefois, dans Container registry, les packages publics autorisent l’accès anonyme et peuvent être extraits sans authentification ni connexion via l’interface CLI.

Remarque : Si vous publiez un package qui est lié à un dépôt, le package hérite de ses autorisations par défaut. Pour accéder aux paramètres des autorisations granulaires du package, vous devez supprimer les autorisations héritées du package. Si vous êtes propriétaire d’une organisation, vous pouvez désactiver l’héritage automatique des autorisations pour tous les nouveaux packages délimités à votre organisation. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package » et « Configuration du contrôle d’accès et de la visibilité d’un package ».

Quand vous publiez un package, vous bénéficiez automatiquement d’autorisations d’administrateur sur le package. Si vous publiez un package dans une organisation, toute personne ayant le rôle owner dans l’organisation obtient également des autorisations d’administrateur sur le package.

Pour les packages délimités à un compte personnel, vous pouvez attribuer un rôle d’accès à n’importe quelle personne. Pour les packages délimités à une organisation, vous pouvez attribuer un rôle d’accès à toute personne ou équipe de l’organisation.

Si vous utilisez un workflow GitHub Actions pour gérer vos images conteneur, vous pouvez accorder un rôle d’accès au dépôt dans lequel le workflow est stocké dans en utilisant le bouton Ajouter un dépôt sous « Gérer l’accès à Actions » dans les paramètres du package. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».

AutorisationDescription de l’accès
LirePeut télécharger le package.
Peut lire les métadonnées du package.
WritePeut charger et télécharger ce package.
Peut lire et écrire des métadonnées de package.
AdminPeut charger, télécharger, supprimer et gérer ce package.
Peut lire et écrire des métadonnées de package.
Peut accorder des autorisations sur le package.

Remarque : la capacité des workflows GitHub Actions de supprimer et de restaurer des packages à l’aide de l’API REST est actuellement en version bêta publique et susceptible d’être modifiée.

Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».

À propos des étendues et des autorisations des registres de packages

GitHub Packages prend uniquement en charge l’authentification à l’aide d’un personal access token (classic). Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».

Pour utiliser ou gérer un package hébergé par un registre de packages, vous devez utiliser un personal access token (classic) avec l’étendue appropriée et votre compte personnel doit avoir les autorisations appropriées.

Par exemple :

  • Pour télécharger et installer des packages à partir d’un dépôt, votre personal access token (classic) doit avoir l’étendue read:packages et votre compte d’utilisateur doit avoir une autorisation en lecture.
  • Pour supprimer un package sur GitHub Enterprise Cloud, votre personal access token (classic) doit au moins avoir les étendues delete:packages et read:packages. L’étendue repo est également requise pour les packages limités au référentiel. Pour plus d’informations, consultez « Suppression et restauration d'un package ».
ÉtendueDescriptionAutorisation requise
read:packagesTélécharger et installer des packages de GitHub Packageslire
write:packagesCharger et publier des packages sur GitHub Packagesécrire
delete:packagesSupprimer les packages de GitHub Packagesadmin
repoCharger et supprimer des packages (avec write:packages ou delete:packages)écriture ou administrateur

Remarque : la capacité des workflows GitHub Actions de supprimer et de restaurer des packages à l’aide de l’API REST est actuellement en version bêta publique et susceptible d’être modifiée.

Lorsque vous créez un workflow GitHub Actions, vous pouvez utiliser GITHUB_TOKEN pour publier, installer, supprimer et restaurer des packages dans GitHub Packages sans avoir à stocker ni à gérer un personal access token.

Pour plus d’informations, consultez :

À propos des transferts de dépôts

Vous pouvez transférer un dépôt à un autre compte personnel ou une autre organisation. Pour plus d’informations, consultez « Transfert d’un dépôt ».

Lorsque vous transférez un dépôt, GitHub peut transférer les paquets associés au dépôt, en fonction du registre auquel appartiennent les paquets.

  • Pour les registres qui prennent en charge les autorisations granulaires, les packages sont délimités à un compte personnel ou à une organisation, et le compte associé au package ne change pas quand vous transférez un dépôt. Si vous avez lié un package à un dépôt, le lien est supprimé lorsque vous transférez le dépôt à un autre utilisateur. Tous les codespaces ou workflows GitHub Actions associés au dépôt perdent l’accès au package. Si le package a hérité de ses autorisations d’accès du dépôt lié, les utilisateurs perdent l’accès au package. Pour obtenir la liste de ces registres, consultez « Autorisations granulaires pour les packages délimités à l’utilisateur/l’organisation » ci-dessus.
  • Pour les registres qui prennent uniquement en charge les autorisations limitées au dépôt, les paquets sont publiés directement dans les dépôts, et GitHub transfère les paquets associés à un dépôt dans le cadre du transfert du dépôt. Toute utilisation facturable associée aux packages sera ensuite facturée au nouveau propriétaire du dépôt. Si le précédent propriétaire du dépôt est supprimé en tant que collaborateur sur le dépôt, il peut ne plus pouvoir accéder aux packages associés au dépôt. Pour obtenir la liste de ces registres, consultez « Autorisations pour les paquets limités au dépôt » ci-dessus.

Gestion de l’accès aux packages dans les workflows GitHub Actions

Pour garantir que vos workflows conservent l’accès à vos packages, assurez-vous que vous utilisez le jeton d’accès approprié à votre workflow et que vous avez activé l’accès GitHub Actions à votre package.

Pour plus d’informations conceptuelles sur GitHub Actions ou des exemples d’utilisation de packages dans les workflows, consultez « Gestion des packages GitHub en utilisant des workflows GitHub Actions ».

Jetons d’accès

Remarque : la capacité des workflows GitHub Actions de supprimer et de restaurer des packages à l’aide de l’API REST est actuellement en version bêta publique et susceptible d’être modifiée.

  • Pour publier, installer, supprimer et restaurer les packages associés au dépôt de workflow, utilisez GITHUB_TOKEN.
  • Pour installer des packages associés à d’autres dépôts privés auxquels GITHUB_TOKEN ne peut pas accéder, utilisez un personal access token (classic).

Pour plus d’informations sur le GITHUB_TOKEN utilisé dans les workflows GitHub Actions, consultez « Authentification par jeton automatique ».

Configurer l’accès de GitHub Actions pour les packages avec des autorisations granulaires

Pour garantir l’accès de vos workflows aux packages stockés dans des registres prenant en charge les autorisations granulaires, vous devez accorder à GitHub Actions l’accès aux dépôts dans lesquels votre workflow est exécuté. Vous trouverez ce paramètre dans la page des paramètres de votre package. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».