gcr.io hébergé sur Artifact Registry par défaut

Apprenez à configurer des dépôts gcr.io dans Artifact Registry, et découvrez les différences entre les autorisations Artifact Registry et Container Registry, ainsi que la configuration du bucket de stockage.

Les étapes manuelles décrites dans ce document peuvent être effectuées à l'aide de l'outil de migration automatique. Si vous souhaitez utiliser l'outil de migration automatique pour migrer vos projets utilisant activement Container Registry vers des dépôts standards Artifact Registry ou des dépôts gcr.io, consultez la section Automatiser la migration vers Artifact Registry.

Abandon de Container Registry

Les projets Google Cloud qui n'ont pas utilisé Container Registry avant le 15 mai 2024 n'accepteront que l'hébergement et la gestion d'images dans Artifact Registry. Ce changement concerne les éléments suivants:

  • Les nouveaux projets.
  • Projets existants pour lesquels vous n'avez pas transféré d'image vers Container Registry.

Les organisations qui n'ont pas utilisé Container Registry avant le 8 janvier 2024 disposeront de nouveaux dépôts gcr.io hébergés sur Artifact Registry par défaut.

Lorsque vous activez l'API Artifact Registry dans ces projets, Artifact Registry gère automatiquement la création des dépôts gcr.io dans Artifact Registry et redirige les requêtes vers le domaine gcr.io vers le dépôt Artifact Registry approprié. Contrairement à la compatibilité des domaines gcr.io existants dans les projets utilisant Container Registry activement, la redirection vers Artifact Registry est automatique.

Container Registry restera disponible dans les projets pour lesquels l'une des actions suivantes s'est produite avant le 15 mai 2024:

  • Vous avez activé l'API Container Registry dans le projet.
  • Vous avez transféré une image vers un hôte de registre du projet.

Voici nos recommandations pour vous préparer au changement à venir:

  • Suivez les instructions de ce document pour configurer des projets pour lesquels vous n'utilisez pas Container Registry afin qu'ils soient prêts pour le traitement automatique des requêtes gcr.io lorsque les modifications prennent effet.
  • Testez la compatibilité du domaine gcr.io pour vérifier que votre automatisation existante continuera de fonctionner.

Les dépôts gcr.io hébergés sur Artifact Registry sont créés dans les mêmes emplacements multirégionaux que Container Registry accepte. Si vous souhaitez stocker vos images dans d'autres régions, vous devez passer aux dépôts standards sur le domaine pkg.dev.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer des dépôts "gcr.io", demandez à votre administrateur de vous attribuer les rôles IAM suivants:

  • Pour créer des dépôts Artifact Registry et accorder l'accès à des dépôts individuels : Administrateur Artifact Registry (roles/artifactregistry.admin) sur le projet
  • Pour afficher et gérer la configuration Container Registry existante appliquée aux buckets de stockage Cloud Storage : Administrateur Storage (roles/storage.admin) sur le projet
  • Pour accorder l'accès au dépôt au niveau du projet : Administrateur IAM de projet (roles/resourcemanager.projectIamAdmin) ou un rôle comprenant des autorisations équivalentes telles qu'Administrateur de dossier (roles/resourcemanager.folderAdmin) ou Administrateur de l'organisation (roles/resourcemanager.organizationAdmin) sur le projet, le dossier ou l'organisation
  • Pour répertorier les services activés dans une organisation : Lecteur d'éléments Cloud (roles/cloudasset.viewer) sur l'organisation

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Avant de commencer

Vous pouvez répertorier les projets dans lesquels au moins une image est stockée dans Container Registry. Vous pouvez ensuite vous concentrer sur la configuration d'autres projets pour l'hébergement de requêtes gcr.io dans Artifact Registry en suivant les instructions de ce document.

Exécutez la commande suivante pour rechercher l'utilisation de Container Registry dans votre organisation Google Cloud.

  gcloud container images list-gcr-usage \
      --organization=ORGANIZATION

Remplacez ORGANIZATION par l'ID de votre organisation Google Cloud.

Vous pouvez également lister l'utilisation de Container Registry pour votre projet ou dossier. Pour en savoir plus sur l'utilisation de Container Registry, consultez la page Vérifier l'utilisation de Container Registry.

Activer l'API

Activez l'API Artifact Registry pour que les requêtes adressées au domaine gcr.io soient automatiquement traitées par Artifact Registry lorsque l'hébergement automatique de gcr.io prend effet.

  1. Exécutez la commande ci-dessous.

    gcloud services enable \
        artifactregistry.googleapis.com
    
  2. Si vous placez normalement l'API Container Registry dans un périmètre de service VPC Service Controls, veillez également à placer l'API Artifact Registry dans ce périmètre. Pour obtenir des instructions, consultez la section Sécuriser les dépôts dans un périmètre de service.

Accorder des autorisations aux dépôts

Container Registry utilise des rôles Cloud Storage pour contrôler les accès. Artifact Registry possède ses propres rôles IAM, qui séparent plus clairement les rôles de lecture, d'écriture et d'administration de dépôt que Container Registry.

Pour mapper rapidement les autorisations existantes accordées sur les buckets de stockage avec les rôles Artifact Registry suggérés, utilisez l'outil de mappage de rôles.

Vous pouvez également afficher la liste des comptes principaux ayant accès aux buckets de stockage à l'aide de la console Google Cloud.

  1. Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.

    Accéder à la page "Buckets"

  2. Cliquez sur le bucket de stockage correspondant à l'hôte de registre que vous souhaitez afficher. Dans les noms des buckets, PROJECT-ID correspond à l'ID de votre projet Google Cloud.

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
  3. Cliquez sur l'onglet Autorisations.

  4. Dans l'onglet "Autorisations", cliquez sur le sous-onglet Afficher par rôle.

  5. Développez un rôle pour afficher les comptes principaux qui disposent de ce rôle.

La liste comprend les rôles IAM attribués directement sur le bucket et les rôles hérités du projet parent. En fonction du rôle, vous pouvez choisir le rôle Artifact Registry le plus approprié à attribuer.

Cloud Storage et rôles de base

Accordez aux utilisateurs et aux comptes de service qui accèdent actuellement à Container Registry un accès aux dépôts Artifact Registry. Pour les rôles Cloud Storage hérités du projet parent, vous devez vérifier que le compte principal utilise actuellement Container Registry. Certains comptes principaux peuvent n'accéder qu'à d'autres buckets Cloud Storage sans lien avec Container Registry.

Les rôles de base Propriétaire, Éditeur et Lecteur qui existaient avant IAM disposent d'un accès limité aux buckets de stockage. Ils n'accordent pas intrinsèquement tous les accès aux ressources Cloud Storage que leur nom implique et ne fournissent pas d'autorisations supplémentaires pour d'autres services Google Cloud. Vérifiez quels utilisateurs et comptes de service ont besoin d'accéder à Artifact Registry et utilisez le tableau du mappage des rôles pour vous aider à attribuer les rôles appropriés si l'accès à Artifact Registry est approprié.

Le tableau suivant présente les rôles Artifact Registry en fonction des autorisations accordées par les rôles Cloud Storage prédéfinis pour l'accès à Container Registry.

Accès requis Rôle actuel Rôle Artifact Registry Où attribuer un rôle
Extraire des images uniquement (lecture seule) Lecteur des objets Storage
(roles/storage.objectViewer)
Lecteur Artifact Registry
(roles/artifactregistry.reader)
Dépôt Artifact Registry ou projet Google Cloud
  • Transférer et récupérer des images (lecture et écriture)
  • Supprimer des images
Rédacteur des anciens buckets Storage
(roles/storage.legacyBucketWriter)
Administrateur de dépôt Artifact Registry
(roles/artifactregistry.repoAdmin)
Dépôt Artifact Registry ou projet Google Cloud
Créez un dépôt gcr.io dans Artifact Registry la première fois qu'une image est transférée vers un nom d'hôte gcr.io dans un projet. Administrateur de l'espace de stockage
(roles/storage.admin)
Administrateur de dépôt Artifact Registry avec création lors de l'envoi
(roles/artifactregistry.createOnPushRepoAdmin)
Projet Google Cloud
Créer, gérer et supprimer des dépôts Administrateur de l'espace de stockage
(roles/storage.admin)
Administrateur Artifact Registry
(roles/artifactregistry.Admin)
Projet Google Cloud
Rôles d'agent de service hérités du projet

Les comptes de service par défaut des services Google Cloud ont leurs propres rôles attribués au niveau du projet. Par exemple, l'agent de service pour Cloud Run a le rôle d'agent de service Cloud Run.

Dans la plupart des cas, ces rôles d'agent de service contiennent des autorisations par défaut équivalentes pour Container Registry et Artifact Registry, et vous n'avez pas besoin d'apporter de modifications supplémentaires si vous exécutez Artifact Registry dans le même projet que votre service Container Registry existant.

Reportez-vous à la documentation de référence sur les rôles d'agent de service pour en savoir plus sur les autorisations dans les rôles d'agent de service.

Rôles personnalisés

Utilisez le tableau de mappage des rôles pour vous aider à choisir le rôle à attribuer aux utilisateurs ou aux comptes de service en fonction du niveau d'accès dont ils ont besoin.

Pour obtenir des instructions sur l'attribution de rôles Artifact Registry, consultez la section Configurer les rôles et les autorisations.

Configuration du bucket de stockage

Lorsque vous créez un dépôt dans Artifact Registry, Artifact Registry ne crée pas de buckets Cloud Storage correspondants dans votre projet. Si l'automatisation de Container Registry interagit directement avec les buckets de stockage, vous devez la mettre à jour pour apporter les modifications correspondantes au dépôt Artifact Registry.

Par exemple, si vous accordez de manière automatisée des autorisations Cloud Storage sur les buckets de stockage pour Container Registry, vous devez mettre à jour cette automatisation pour accorder des autorisations Artifact Registry sur les dépôts Artifact Registry qui hébergent des images pour le domaine gcr.io.

Dans Artifact Registry, vous définissez la méthode de chiffrement des données stockées dans un dépôt plutôt que dans un bucket de stockage. L'hébergement automatique de gcr.io sur Artifact Registry crée des dépôts gcr.io chiffrés avec des clés détenues et gérées par Google. Si vous souhaitez utiliser des clés de chiffrement gérées par le client (CMEK), vous devez créer vous-même les dépôts gcr.io et spécifier CMEK comme méthode de chiffrement.

Pour créer manuellement un dépôt gcr.io:

  1. Si vous utilisez des CMEK, créez la clé que vous utiliserez avec ce dépôt et accordez les autorisations nécessaires pour utiliser cette clé. Consultez la page Activer les clés de chiffrement gérées par le client.

  2. Ajoutez le dépôt.

    Console

    1. Ouvrez la page Dépôts de la console Google Cloud.

      Ouvrir la page "Dépôts"

    2. Cliquez sur Créer un dépôt.

    3. Spécifiez le nom du dépôt.

      Nom d'hôte Container Registry Nom du dépôt Artifact Registry
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io
    4. Spécifiez Docker comme format de dépôt.

    5. Sous Type d'emplacement, spécifiez l'emplacement multirégional du dépôt:

      Nom d'hôte Container Registry Emplacement du dépôt Artifact Registry
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us
    6. Ajoutez une description pour le dépôt. N'incluez pas de données sensibles, car les descriptions de dépôts ne sont pas chiffrées.

    7. Dans la section Chiffrement, choisissez le mécanisme de chiffrement du dépôt.

      • Clé gérée par Google : chiffrez le contenu du dépôt à l'aide d'une clé appartenant à Google et gérée par Google.
      • Clé gérée par le client : chiffre le contenu du dépôt à l'aide d'une clé que vous contrôlez via Cloud Key Management Service. Pour obtenir des instructions sur la configuration de la clé, consultez la page Configurer des CMEK pour les dépôts.
    8. Cliquez sur Créer.

    gcloud

    Exécutez la commande suivante pour créer un dépôt.

    gcloud artifacts repositories create REPOSITORY \
        --repository-format=docker \
        --location=LOCATION \
        --description=DESCRIPTION \
        --kms-key=KMS-KEY
    

    Remplacez les valeurs suivantes :

    • REPOSITORY est le nom du dépôt.

      Nom d'hôte Container Registry Nom du dépôt Artifact Registry
      gcr.io gcr.io
      asia.gcr.io asia.gcr.io
      eu.gcr.io eu.gcr.io
      us.gcr.io us.gcr.io
    • LOCATION est l'emplacement multirégional du dépôt:

      Nom d'hôte Container Registry Emplacement du dépôt Artifact Registry
      gcr.io us
      asia.gcr.io asia
      eu.gcr.io europe
      us.gcr.io us
    • DESCRIPTION est une description du dépôt. N'incluez pas de données sensibles, car les descriptions de dépôts ne sont pas chiffrées.

    • KMS-KEY est le chemin d'accès complet à la clé de chiffrement Cloud KMS, si vous utilisez une clé de chiffrement gérée par le client pour chiffrer le contenu du dépôt. Le chemin est au format suivant :

      projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
      

      Remplacez les valeurs suivantes :

      • KMS-PROJECT est le projet dans lequel votre clé est stockée.
      • KMS-LOCATION correspond à l'emplacement de la clé.
      • KEY-RING correspond au nom du trousseau de clés.
      • KEY correspond au nom de la clé.

    Vous pouvez vérifier que le dépôt a bien été créé en listant vos dépôts à l'aide de la commande suivante:

    gcloud artifacts repositories list
    

Étapes suivantes

Configurez la compatibilité du domaine gcr.io dans un projet de test pour vérifier que l'automatisation et l'intégration existantes avec des services tels que Cloud Build, Google Kubernetes Engine ou Cloud Functions fonctionnent comme prévu.