Container Registry est obsolète et son abandon est planifié. Depuis le 15 mai 2024, Artifact Registry héberge les images du domaine gcr.io dans les projets qui n'ont pas encore utilisé Container Registry. Après le 18 mars 2025, Container Registry sera arrêté.

Pour commencer à gérer des conteneurs sur Google Cloud, utilisez Artifact Registry. Si vous utilisez Container Registry, découvrez comment passer à Artifact Registry pour gérer vos conteneurs sur Google Cloud.

Pour en savoir plus, consultez la page des abandons et les notes de version.

Cette page a été traduite par l'API Cloud Translation.

Contrôle des accès avec IAM

Cette page décrit les autorisations de contrôle d'accès à Container Registry.

Une fois les autorisations configurées, vous pouvez configurer l'authentification pour les clients Docker que vous utilisez pour stocker et extraire des images.

Si vous utilisez Artifact Analysis pour travailler avec des métadonnées de conteneurs, telles que détectées dans les images, consultez les Documentation Artifact Analysis pour en savoir plus sur les autorisations permettant d'afficher ou de gérer les métadonnées.

Avant de commencer

Vérifiez que vous disposez des autorisations nécessaires pour gérer les utilisateurs. Vous devez disposer des autorisations nécessaires dans l'un des rôles suivants:

Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin)
Administrateur de sécurité (roles/iam.securityAdmin)

Au lieu d'attribuer ces rôles, vous pouvez utiliser un custom role ou rôle prédéfini avec le même autorisations.

Autorisations et rôles

Tous les utilisateurs, comptes de service et autres identités qui interagissent avec Container Registry doivent disposer Autorisations Identity and Access Management (IAM) pour Cloud Storage

Services Google Cloud qui accèdent généralement à Container Registry sont configurés avec des autorisations par défaut pour les registres projet Google Cloud. Si les autorisations par défaut ne répondent pas à vos besoins, vous devez configurer les autorisations appropriées.
Pour les autres identités, vous devez configurer les autorisations requises.

Vous contrôlez l'accès aux hôtes Container Registry à l'aide d'autorisations Cloud Storage. Le tableau suivant répertorie les Rôles Cloud Storage disposant du rôle requises par Container Registry.

Des autorisations supplémentaires sont requises pour afficher Container Registry à l'aide de la console Google Cloud, consultez Autorisations courantes requises pour utiliser la console Cloud.

Accès requis	Rôle	Où accorder des autorisations ?
Extraire des images (lecture seule) d'un registre existant	Lecteur des objets Storage (roles/storage.objectViewer)	Accordez le rôle sur le bucket de stockage du registre.
Transférer (écrire) des images vers un hôte de registre existant et extraire (lire) des images dans un projet	Rédacteur des anciens buckets de l'espace de stockage (roles/storage.legacyBucketWriter)	Accordez le rôle sur le bucket de stockage du registre. Cette autorisation concerne uniquement disponible au niveau du bucket, vous ne pouvez pas l'accorder au niveau du projet.
Ajoutez des hôtes de registre aux projets Google Cloud et créez le des buckets de stockage associés.	Administrateur de l'espace de stockage (roles/storage.admin)	Accorder le rôle au niveau du projet

Le transfert d'images nécessite des autorisations de lecture et d'écriture sur les objets, ainsi que le Autorisation storage.buckets.get. Le rôle "Rédacteur des anciens buckets de l'espace de stockage" inclut les autorisations requises dans un rôle Cloud Storage unique, n'accorde pas un contrôle total sur les buckets et objets de stockage.

Le rôle Administrateur de l'espace de stockage offre un contrôle total sur les buckets et les objets de stockage. Si vous accordez cette autorisation au niveau du projet, le compte principal a accès à tous les buckets de stockage du projet, y compris ceux qui ne sont pas utilisés Container Registry. Déterminez avec soin les comptes principaux qui nécessitent ce rôle.

Par défaut, le compte de service Cloud Build autorisations disposant du rôle "Administrateur de l'espace de stockage". Ce compte de service peut donc ajouter des registres vers son projet parent lors des premières opérations de transfert et de transfert d'images vers dans son projet parent.
Si vous utilisez Docker ou d'autres outils pour créer des images et les transférer vers un registre, envisagez d'ajouter des registres à votre projet en utilisant un compte avec le plus d'administrateur Storage, puis accordez le rôle "Rédacteur des anciens buckets de l'espace de stockage" ou Rôles de lecteur des objets Storage à d'autres comptes ayant besoin de transférer ou d'extraire images.

Pour en savoir plus sur les rôles et les autorisations Cloud Storage, consultez la documentation de Cloud Storage.

Accorder des autorisations IAM

Container Registry utilise les buckets Cloud Storage comme stockage sous-jacent pour les images de conteneurs. Vous contrôlez l'accès à vos images en accordant des autorisations au bucket pour un registre.

La première image transmise à un nom d'hôte ajoute l'hôte de registre et son espace de stockage. un bucket à un projet. Par exemple, le premier transfert vers gcr.io/my-project ajoute l'hôte de registre gcr.io au projet avec ID du projet my-project et crée un bucket de stockage pour le registre. Le nom du bucket contient l'un des formats suivants:

artifacts.PROJECT-ID.appspot.com pour les images stockées sur l'hôte gcr.io
STORAGE-REGION.artifacts.PROJECT-ID.appspot.com pour les images stockées sur d'autres hôtes de registre

Pour effectuer cette première transmission d'image, doivent disposer des autorisations associées au rôle Administrateur de l'espace de stockage ;

Après avoir transféré l'image initiale sur un hôte de registre, accordez-lui les autorisations sur le bucket de stockage du registre pour contrôler l'accès aux images dans dans le registre:

Rédacteur des anciens buckets Storage pour les transferts
Lecteur des objets Storage pour l'extraction uniquement

Vous pouvez accorder des autorisations pour un bucket à l'aide de la console Google Cloud ou l'outil de ligne de commande gsutil.

Limites et restrictions

Vous ne pouvez accorder des autorisations qu'au niveau du bucket de stockage Hôtes Container Registry

Container Registry ignore les autorisations définies sur des objets individuels dans dans un bucket Cloud Storage.
Vous ne pouvez pas accorder d'autorisations sur les dépôts d'un registre. Si vous avez besoin plus précis, Artifact Registry fournit un contrôle des accès au niveau du dépôt et peut mieux répondre à vos besoins.
Si vous activez l'accès uniforme au niveau du bucket pour tout bucket de stockage Container Registry, vous devez explicitement accorder autorisations pour tous les utilisateurs et comptes de service qui accèdent à vos registres. Dans Dans ce cas, les rôles "Propriétaire" et "Éditeur" eux-mêmes n'accordent pas les autorisations requises.

Octroyer des autorisations

Si l'hôte de registre n'existe pas encore dans le projet, un compte avec autorisations du rôle Administrateur de l'espace de stockage doit transférer la première image vers le registre. Le bucket de stockage est alors créé pour l'hôte de registre.

Cloud Build dispose des autorisations nécessaires pour exécuter l'image initiale dans le même projet. Si vous transférez des images avec un autre outil, Vérifiez les autorisations du compte Google Cloud que vous utilisez pour s'authentifier auprès de Container Registry.

Pour en savoir plus sur le transfert de l'image initiale avec Docker, consultez Ajouter un registre
Dans le projet contenant Container Registry, accordez les autorisations appropriées sur le bucket Cloud Storage utilisé par l'hôte de registre.

Remarque :Vous ne pouvez pas accorder d'autorisations "Rédacteur des anciens buckets de l'espace de stockage" au niveau du projet. et d'accorder des autorisations de lecteur des objets Storage donne accès à tous les buckets de stockage, y compris à ceux qui ne sont pas utilisées par Container Registry.
Console
1. Accédez à la page Cloud Storage de la console Google Cloud.
2. Cliquez sur le lien artifacts.PROJECT-ID.appspot.com ou STORAGE-REGION.artifacts.PROJECT-ID.appspot.com pour le bucket.
  
  Remplacez PROJECT-ID par Google Cloud ID du projet du projet qui héberge Container Registry STORAGE-REGION avec l'emplacement multirégional (asia, eu ou us) du registre qui héberge l'image.
3. Sélectionnez l'onglet Autorisations.
4. Cliquez sur Ajouter.
5. Dans le champ Comptes principaux, saisissez les adresses e-mail des comptes. nécessitant un accès, séparés par une virgule. Voici les types d'adresses e-mail possibles :
  - Un compte Google (par exemple, someone@example.com)
  - Groupe Google (par exemple, my-developer-team@googlegroups.com)
  - Un compte de service IAM
    
    Consultez la liste des services Google Cloud. qui accèdent généralement aux registres pour trouver l'adresse e-mail des compte de service associé. Si le service est exécuté dans un projet différent de celui de Container Registry, assurez-vous que vous utilisez l'adresse e-mail du compte de service un autre projet.
6. Dans le menu déroulant Sélectionnez un rôle, sélectionnez le rôle Cloud Storage, puis sélectionnez l'autorisation appropriée.
  - Lecteur des objets de l'espace de stockage pour extraire des images uniquement
  - Rédacteur des anciens buckets de l'espace de stockage pour transférer et extraire des images
7. Cliquez sur Ajouter.
Remarque : Les adresses e-mail et les domaines doivent être associés à un compte Google ou Google Apps actif.
gsutil
1. Exécutez la commande suivante pour répertorier les buckets du projet :
```
gsutil ls
```
  La réponse est semblable à ceci :
```
gs://[BUCKET_NAME1]/
gs://[BUCKET_NAME2]/
gs://[BUCKET_NAME3]/ ...
```
  Recherchez le bucket de l'hôte de registre dans la liste de buckets renvoyée. Le bucket qui stocke vos images porte le nom BUCKET-NAME sous l'une des formes suivantes:
  - artifacts.PROJECT-ID.appspot.com pour les images stockées sur l'hôte gcr.io
  - STORAGE-REGION.artifacts.PROJECT-ID.appspot.com pour les images stockées sur d'autres hôtes de registre
  Où
  - PROJECT-ID est votre Google Cloud ID du projet.
  - STORAGE-REGION est l'emplacement du bucket de stockage :
    us pour les registres de l'hôte us.gcr.io
    
    eu pour les registres de l'hôte eu.gcr.io
    
    asia pour les registres de l'hôte asia.gcr.io
2. Exécutez la commande suivante dans la fenêtre de votre interface système ou de votre terminal :
```
gsutil iam ch TYPE:EMAIL-ADDRESS:ROLE gs://BUCKET_NAME
```
  Où
  - TYPE peut être :
    serviceAccount, si EMAIL-ADDRESS spécifie un compte de service.
    
    user, si EMAIL-ADDRESS est un compte Google.
    
    group, si EMAIL-ADDRESS est un groupe Google.
  - EMAIL-ADDRESS peut être :
    
    Un compte Google (par exemple, someone@example.com)
    
    Groupe Google (par exemple, my-developer-team@googlegroups.com)
    
    Un compte de service IAM
    
    Consultez la liste des services Google Cloud. qui accèdent généralement aux registres pour trouver l'adresse e-mail des compte de service associé. Si le service est exécuté dans un projet différent de celui de Container Registry, assurez-vous que vous utilisez l'adresse e-mail du compte de service un autre projet.
  - ROLE est le rôle Cloud Storage que vous souhaitez attribuer.
    
    objectViewer pour extraire des images
    
    legacyBucketWriter images de transfert et d'extraction
  - BUCKET_NAME est le nom du bucket Cloud Storage au format artifacts.PROJECT-ID.appspot.com ou STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
Par exemple, cette commande accorde au compte de service my-account@my-project.iam.gserviceaccount.com disposant des autorisations suivantes : transférer et extraire des images dans le bucket my-example-bucket:
```
gsutil iam ch \
  serviceAccount:my-account@my-project.iam.gserviceaccount.com:legacyBucketWriter \
  gs://my-example-bucket
```
La commande gsutil iam ch modifie les autorisations IAM du bucket de stockage dans lequel le registre est hébergé. Voici d'autres exemples : dans la documentation gsutil.
Remarque : Les adresses e-mail et les domaines doivent être associés à un compte Google ou Google Apps actif.
Si vous configurez l'accès pour les VM Compute Engine ou les nœuds GKE qui transféreront des images vers Container Registry ; consultez la page Configurer des VM et des clusters pour en savoir plus étapes de configuration.

Configurer l'accès public aux images

Container Registry est accessible publiquement si le bucket de stockage sous-jacent de l'emplacement d'hôte l'est aussi. Dans un projet, toutes les images de chaque emplacement d'hôte sont publiques ou non. Dans l'hôte d'un projet, il n'est pas possible de ne diffuser publiquement que des images spécifiques. Si vous souhaitez rendre publiques des images spécifiques :

veillez à les conserver dans un emplacement d'hôte séparé que vous rendez public, ou ;
Créez un projet pour stocker des images accessibles au public.

Pour diffuser publiquement des images de conteneurs, faites passer le bucket de stockage sous-jacent en accès public en procédant comme suit :

Assurez-vous d'avoir transféré une image vers Container Registry afin que le bucket de stockage sous-jacent existe.
Recherchez le nom du bucket Cloud Storage pour ce registre. Pour cela, répertoriez les buckets :
```
gsutil ls
```
L'URL de votre bucket Container Registry sera répertoriée sous la forme gs://artifacts.PROJECT-ID.appspot.com ou gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com, où :
- PROJECT-ID est votre Google Cloud ID du projet. Dans les projets à l'échelle du domaine, le nom de domaine figure dans l'ID du projet.
- STORAGE-REGION est l'emplacement du bucket de stockage :
  - us pour les registres de l'hôte us.gcr.io
  - eu pour les registres de l'hôte eu.gcr.io
  - asia pour les registres de l'hôte asia.gcr.io
Faites passer le bucket de stockage Container Registry en accès public en exécutant la commande suivante. Cette dernière rendra toutes les images du bucket accessibles au public.
```
gsutil iam ch allUsers:objectViewer gs://BUCKET-NAME
```
où :
- gs://BUCKET-NAME est l'URL du bucket Container Registry.

Supprimer l'accès public aux images

Console

Assurez-vous d'avoir transféré une image vers Container Registry afin que le bucket de stockage sous-jacent existe.
Ouvrez la page Container Registry dans la console Google Cloud.

Ouvrir la page Container Registry.
Dans le panneau de gauche, cliquez sur Paramètres.
Sur la page Paramètres, sous Accès public, activez l'option visibilité en mode Privé. Ce paramètre contrôle l'accès au bucket de stockage sous-jacent.

gsutil

Recherchez le nom du bucket Cloud Storage pour ce registre. Pour cela, répertoriez les buckets :
```
gsutil ls
```
L'URL de votre bucket Container Registry sera répertoriée sous la forme gs://artifacts.PROJECT-ID.appspot.com ou gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com, où :
- PROJECT-ID est votre console Google Cloud. ID du projet. Dans les projets à l'échelle du domaine, le nom de domaine figure dans l'ID du projet.
- STORAGE-REGION est l'emplacement du bucket de stockage :
  - us pour les registres de l'hôte us.gcr.io
  - eu pour les registres de l'hôte eu.gcr.io
  - asia pour les registres de l'hôte asia.gcr.io
Pour supprimer l'accès public à votre bucket de stockage, exécutez la commande suivante : dans la fenêtre de votre shell ou de votre terminal:
```
gsutil iam ch -d allUsers:objectViewer gs://BUCKET-NAME
```

où :

BUCKET-NAME est le nom du bucket souhaité.

Révoquer les autorisations

Pour révoquer des autorisations IAM, procédez comme suit :

Console

Accédez à la page Cloud Storage dans la console Google Cloud.
Cliquez sur le lien artifacts.PROJECT-ID.appspot.com ou STORAGE-REGION.artifacts.PROJECT-ID.appspot.com associés au bucket. Ici, PROJECT-ID est l'ID du projet Google Cloud qui héberge Container Registry et STORAGE-REGION est l'emplacement multirégional (asia, eu, ou us) du registre qui héberge l'image.
Sélectionnez l'onglet Autorisations.
Cliquez sur l'icône Corbeille à côté du compte principal que vous souhaitez supprimer.

gsutil

Exécutez la commande suivante dans la fenêtre de votre interface système ou de votre terminal :

gsutil iam ch -d PRINCIPAL gs://BUCKET-NAME

où :

PRINCIPAL peut être :
- user:EMAIL-ADDRESS pour un compte Google ;
- serviceAccount:EMAIL-ADDRESS pour un compte de service IAM ;
- group:EMAIL-ADDRESS pour un groupe Google ;
- allUsers pour révoquer l'accès public
BUCKET-NAME est le nom du bucket souhaité.

Integrate with Google Cloud services

Pour la plupart des comptes de service Google Cloud, configurer l'accès à un registre il suffit d'accorder les autorisations IAM appropriées.

Autorisations par défaut pour les services Google Cloud

Les services Google Cloud tels que Cloud Build ou Google Kubernetes Engine utilisent default service account ou agent de service avec lequel interagir ressources au sein d'un même projet.

Vous devez configurer ou modifier vous-même les autorisations dans les cas suivants :

Le service Google Cloud se trouve dans un projet différent de celui de Container Registry.
Les autorisations par défaut ne répondent pas à vos besoins. Par exemple, la valeur par défaut Le compte de service Compute Engine dispose d'un accès en lecture seule à l'espace de stockage projet. Si vous souhaitez transférer une image depuis la VM vers un registre, vous devez modifier les autorisations du compte de service de la VM ou s'authentifier auprès du registre avec un compte qui dispose d'un accès en écriture à l'espace de stockage.
Vous utilisez un compte de service personnalisé pour interagir avec Container Registry.

Les comptes de service suivants accèdent généralement à Container Registry. La du compte de service inclut l'adresse e-mail Google Cloud ID ou numéro de projet du projet dans lequel le service est exécuté.

Service	Compte de service	Adresse e-mail	Autorisations
Environnement flexible App Engine	Compte de service App Engine par défaut	`PROJECT-ID`@appspot.gserviceaccount.com	Rôle d'éditeur, peut lire et écrire dans l'espace de stockage
Compute Engine	Compte de service Compute Engine par défaut	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rôle d'éditeur, limité à un accès en lecture seule à l'espace de stockage
Cloud Build	Compte de service Cloud Build	`PROJECT-NUMBER`@cloudbuild.gserviceaccount.com	Autorisations par défaut y compris la création de buckets de stockage, ainsi que l'accès en lecture et en écriture à l'espace de stockage.
Cloud Run	Compte de service Compute Engine par défaut Compte de service d'exécution par défaut pour les révisions.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rôle d'éditeur, limité à un accès en lecture seule à l'espace de stockage
GKE	Compte de service Compute Engine par défaut Compte de service par défaut pour les nœuds.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rôle d'éditeur, limité à un accès en lecture seule à l'espace de stockage

Configurer des VM et des clusters pour transférer des images

Compute Engine et tout service Google Cloud qui utilise Compute Engine dispose d'un compte de service Compute Engine par défaut comme identité par défaut.

Les autorisations IAM et les niveaux d'accès ont un impact sur la capacité les VM pour lire et écrire dans l'espace de stockage.

Les autorisations IAM déterminent l'accès aux ressources.
Les niveaux d'accès déterminent champs d'application OAuth par défaut pour les requêtes effectuées via gcloud CLI et le client sur une instance de VM. Par conséquent, les niveaux d'accès peuvent limiter davantage aux méthodes d’API lors de l’authentification Identifiants par défaut de l'application.
- Pour extraire une image privée, le compte de service de la VM doit disposer de l'autorisation read sur le bucket de stockage de l'image.
- Pour transférer des images privées, le compte de service de la VM doit disposer du Niveau d'accès read-write, cloud-platform ou full-control au niveau le bucket de stockage d'une image.

Le compte de service Compute Engine par défaut dispose du rôle Éditeur par défaut, qui permet de créer et de mettre à jour des ressources pour la plupart aux services Google Cloud. Toutefois, pour le compte de service par défaut ou un compte de service personnalisé que vous associez à une VM, le niveau d'accès par défaut pour les buckets Storage est en lecture seule. Cela signifie que, par défaut, les VM ne peuvent pas pour transmettre des images.

Si vous avez l'intention de ne déployer des images que dans des environnements tels que Compute Engine et GKE, vous n'avez pas besoin de modifier le niveau d'accès. Si vous exécuter des applications dans ces environnements qui transfèrent des images vers le registre, vous devez effectuer une configuration supplémentaire.

Les configurations suivantes nécessitent de modifier les autorisations IAM ou la configuration du niveau d'accès.

Stocker des images à partir d'une VM ou d'un cluster: Si vous souhaitez transférer des images, le compte de service de l'instance de VM doit avoir le niveau d'accès storage-rw au lieu de storage-ro.
La VM et Container Registry se trouvent dans des projets distincts: Vous devez accorder le compte de service avec IAM les autorisations d'accès au bucket de stockage utilisé par Container Registry.
Exécuter des commandes gcloud sur des VM: Le compte de service doit avoir le niveau d'accès cloud-platform. Ce champ d'application accorde des autorisations pour stocker et extraire des images, ainsi que pour exécuter des commandes gcloud.

La procédure de configuration des niveaux d'accès se trouve dans les sections suivantes.

Configurer les champs d'application pour les VM

Pour définir des niveaux d'accès lors de la création d'une VM, utilisez l'option --scopes.

gcloud compute instances create INSTANCE --scopes=SCOPE

Où

INSTANCE est le nom de l'instance de VM.
SCOPE correspond au niveau d'accès que vous souhaitez configurer pour le compte de service de VM :
- Extraire des images : storage-ro
- Extraire et stocker des images : storage-rw
- Pour extraire et stocker des images, exécutez la commande gcloud : cloud-platform

Pour modifier les niveaux d'accès d'une instance de VM existante :

Définissez le niveau d'accès avec l'option - scopes.

Arrêtez l'instance de VM. Consultez la section Arrêter une instance.
Modifiez le niveau d'accès à l'aide de la commande suivante.
```
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
```
Où
- INSTANCE est le nom de l'instance de VM.
- SCOPE correspond au niveau d'accès que vous souhaitez configurer pour le compte de service de VM :
  - Extraire des images : storage-ro
  - Extraire et stocker des images : storage-rw
  - Pour extraire et stocker des images, exécutez la commande gcloud : cloud-platform
Redémarrez l'instance de VM. Consultez la section Démarrer une instance arrêtée.

Si vous souhaitez utiliser un compte de service personnalisé pour les VM au lieu du compte par défaut compte de service, vous pouvez spécifier le compte de service et les niveaux d'accès à utiliser lorsque vous Créer la VM ou modifier les paramètres de la VM.

Configurer les champs d'application pour les clusters Google Kubernetes Engine

Par défaut, les clusters GKE sont créés avec des autorisations en lecture seule pour les buckets Cloud Storage.

Pour définir le niveau d'accès à l'espace de stockage read-write lors de la création d'un cluster Google Kubernetes Engine, utilisez l'option --scopes. Par exemple, la commande suivante crée un cluster avec les niveaux d'accès bigquery, storage-rw et compute-ro :

gcloud container clusters create example-cluster \
--scopes=bigquery,storage-rw,compute-ro

Pour plus d'informations sur les niveaux d'accès que vous pouvez définir lors de la création d'un cluster, reportez-vous à la documentation de la commande gcloud container clusters create.

Le compte de service Container Registry

L'agent de service Container Registry agit au nom de Container Registry lors de l'interaction avec les services Google Cloud. Le service dispose de l'ensemble minimal d'autorisations requises si vous avez activé API Container Registry après le 5 octobre 2020. L'agent de service avait le rôle d'Éditeur. Pour en savoir plus, sur l'agent de service et sur la modification de ses autorisations, consultez Compte de service Container Registry.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour savoir comment Container Registry fonctionne en conditions réelles différents scénarios. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

<ph type="x-smartling-placeholder"></ph> Essayer Container Registry gratuitement