À propos des registres privés et GitHub Codespaces
Un registre est un espace sécurisé pour stocker, gérer et récupérer des images conteneur ou d’autres packages. Il existe de nombreux exemples de registres, tels que :
- Container registry de GitHub, Azure Container Registry et DockerHub pour les images conteneur
- npm registry pour les packages Node.js.
Certains registres GitHub Packages, notamment le Container registry, peuvent être configurés pour autoriser que les packages soient tirés de manière fluide dans GitHub Codespaces lors de la création de codespaces, sans avoir à fournir d’informations d’identification d’authentification.
Pour accéder aux autres registres d’images conteneur, vous pouvez créer des secrets dans GitHub pour stocker les détails d’accès et permettre à GitHub Codespaces d’accéder aux images stockées dans ce registre.
Accès aux packages stockés dans les registres avec des autorisations granulaires
Les registres GitHub Packages qui prennent en charge les autorisations granulaires, notamment le Container registry, offrent le moyen le plus simple pour GitHub Codespaces de consommer des packages. Pour obtenir la liste des registres GitHub Packages qui prennent en charge les autorisations granulaires et l’accès fluide aux GitHub Codespaces, consultez « À propos des autorisations pour les packages GitHub ».
Accès à un package publié dans le même dépôt que le codespace
Si vous publiez un package dans le même dépôt que celui dans lequel le codespace est lancé, vous pouvez automatiquement récupérer (fetch) ce package lors de la création du codespace. Vous n’avez pas à fournir d’informations d’identification supplémentaires, sauf si l’option Hériter de l’accès du dépôt n’a pas été sélectionnée lors de la publication du package.
Héritage de l’accès du dépôt à partir duquel un package a été publié
Par défaut, le package hérite du paramètre d’accès du dépôt à partir duquel il a été publié. Par exemple, si le dépôt est public, le package l’est également. Si le dépôt est privé, le package l’est également, mais est accessible à partir du dépôt.
L’option Hériter de l’accès du dépôt contrôle ce comportement. L’option Hériter de l’accès du dépôt est sélectionnée par défaut lors de la publication via GitHub Actions, mais pas lors de la publication directement dans un registre avec un personal access token.
Si l’option Hériter de l’accès du dépôt n’a pas été sélectionnée lors de la publication du package, vous pouvez ajouter manuellement le dépôt aux contrôles d’accès du package publié. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Accès à un package publié dans l’organisation dans laquelle un codespace sera lancé
Si vous souhaitez qu’un package soit accessible à tous les codespaces d’une organisation, nous vous recommandons de publier ce package avec une visibilité interne. Le package est ainsi visible par tous les codespaces de l’organisation, sauf si le dépôt à partir duquel le codespace est lancé est public.
Si le codespace est lancé à partir d'un dépôt public faisant référence à un package interne ou privé, vous devez autoriser manuellement le dépôt public à accéder au package interne. Cela permet d’éviter que le package interne ne soit accidentellement divulgué publiquement. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Accès à un package privé à partir d’un sous-ensemble de dépôts d’une organisation
Si vous souhaitez autoriser un sous-ensemble de dépôts d’une organisation à accéder à un package, ou autoriser l’accès à un package interne ou privé à partir d’un codespace lancé dans un dépôt public, vous pouvez ajouter manuellement des dépôts aux paramètres d’accès du package. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Publication d’un package à partir d’un codespace
L’accès transparent d’un codespace à un registre se limite à l’extraction de packages. Si vous souhaitez publier un package à partir d’un codespace, vous devez utiliser un personal access token (classic) avec l’étendue write:packages.
Nous vous recommandons de publier des packages via GitHub Actions. Pour plus d’informations, consultez « Publication des images Docker » et « Publication de packages Node.js ».
Accès aux images stockées dans d’autres registres
Vous pouvez définir des secrets pour permettre à GitHub Codespaces d’accéder à des registres d’images conteneur autres que le Container registry de GitHub. Si vous accédez à une image conteneur à partir d’un registre qui ne prend pas en charge l’accès transparent, GitHub Codespaces vérifie la présence de trois secrets définissant le nom du serveur, le nom de l’utilisateur et le personal access token d’un registre. Si ces secrets sont trouvés, GitHub Codespaces met à disposition le registre dans votre codespace.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Vous pouvez stocker des secrets au niveau de l’utilisateur, du référentiel ou de l’organisation, ce qui vous permet de les partager en toute sécurité entre différents codespaces. Lorsque vous créez un ensemble de secrets pour un registre d’images privé, vous devez remplacer « <*> » dans le nom par un identificateur cohérent. Pour plus d’informations, consultez « Gestion des secrets chiffrés pour vos codespaces » et « Gestion des secrets chiffrés de votre dépôt et de votre organisation pour GitHub Codespaces ».
Si vous définissez les secrets au niveau de l’utilisateur ou de l’organisation, veillez à attribuer ces secrets au référentiel dans lequel vous créerez le codespace en choisissant une stratégie d’accès dans la liste déroulante.
Exemples de secrets
Pour un registre d’images privé dans Azure, vous pouvez créer les secrets suivants :
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Pour plus d’informations sur les registres d’images courants, consultez « Serveurs de registre d’images courants ». Notez que l’accès à AWS Elastic Container Registry (ERC) est différent.
Une fois les secrets ajoutés, vous devrez peut-être arrêter, puis démarrer le codespace dans lequel vous vous trouvez pour permettre la transmission des nouvelles variables d’environnement au conteneur. Pour plus d’informations, consultez « Utilisation de la palette de commandes de code Visual Studio dans GitHub Codespaces ».
Accès à AWS Elastic Container Registry
Pour accéder à AWS Elastic Container Registry (AWS Elastic Container Registry), vous pouvez fournir un ID de clé d’accès AWS et une clé secrète pour permettre à GitHub de récupérer un jeton d’accès et se connecter en votre nom.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
Vous devez également vous assurer que vous disposez des autorisations AWS IAM qui conviennent pour procéder à l’échange d’informations d’identification (par exemplests:GetServiceBearerToken) ainsi que l’opération de lecture ERC (AmazonEC2ContainerRegistryFullAccess ou ReadOnlyAccess).
Si vous ne souhaitez pas que GitHub procède à l’échange d’informations d’identification en votre nom, vous pouvez également fournir un jeton d’autorisation extrait via les API ou l’interface CLI AWS.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
La durée de ces jetons étant courte et ceux-ci devant être régulièrement actualisés, nous vous recommandons de fournir un ID de clé d’accès et un secret.
Bien que ces secrets puissent avoir n’importe quel nom, tant que le *_CONTAINER_REGISTRY_SERVER correspond à une URL ERC, nous vous recommandons d’utiliser ECR_CONTAINER_REGISTRY_*, sauf si vous traitez plusieurs registres ERC.
Pour plus d’informations, consultez la « documentation sur l’authentification du registre privé » ECR AWS.
Serveurs de registre d’images courants
Voici quelques-uns des serveurs de registre d’images courants :
- DockerHub -
https://index.docker.io/v1/ - GitHub Container Registry -
ghcr.io - Azure Container Registry -
<registry name>.azurecr.io - AWS Elastic Container Registry -
<aws_account_id>.dkr.ecr.<region>.amazonaws.com - Google Cloud Container Registry -
gcr.io(US),eu.gcr.io(EU),asia.gcr.io(Asie)
Débogage de l’accès au registre d’images privé
Si vous avez des difficultés à extraire une image d’un registre d’images privé, vérifiez que vous pouvez exécuter docker login -u <user> -p <password> <server>, en utilisant les valeurs des secrets définis ci-dessus. Si la connexion échoue, vérifiez que les informations d’identification de connexion sont valides et que vous disposez des autorisations appropriées sur le serveur pour récupérer une image conteneur. Si la connexion réussit, assurez-vous que ces valeurs sont correctement copiées dans les secrets GitHub Codespaces qui conviennent, au niveau de l’utilisateur, du référentiel ou de l’organisation, puis réessayez.