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 des buckets 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 effectuer la transition de vos projets utilisant Container Registry actif vers des dépôts standards ou gcr.io Artifact Registry à l'aide de l'outil de migration automatique, 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 ne seront compatibles qu'avec l'hébergement et la gestion d'images dans Artifact Registry. Ce changement affecte:

  • Projets nouvellement créés.
  • Projets existants dans 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 par défaut de tous les nouveaux dépôts gcr.io hébergés sur Artifact Registry.

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é actuelle avec les domaines gcr.io dans les projets où Container Registry actif est utilisé, la redirection vers Artifact Registry est automatique.

Container Registry restera disponible dans les projets où l'une des actions suivantes a eu lieu 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 les 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é avec les domaines 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. Si vous souhaitez stocker vos images dans d'autres régions, vous devez passer à des 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 accorder 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 de l'espace de stockage (roles/storage.admin) au niveau du projet
  • Pour accorder l'accès à un dépôt au niveau du projet : Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) ou rôle incluant des autorisations équivalentes, comme 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) au niveau de 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 si Container Registry est utilisé dans votre organisation Google Cloud.

  gcloud containers list-gcr-usage \
      --organization=ORGANIZATION

Remplacez ORGANIZATION par votre ID d'organisation Google Cloud.

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

Activer l'API

Activez l'API Artifact Registry afin qu'Artifact Registry traite automatiquement les requêtes adressées au domaine gcr.io 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 le périmètre. Pour obtenir des instructions, consultez la page 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 dispose de ses propres rôles IAM, qui distinguent 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 de 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 l'appartiennent.

La liste comprend les rôles IAM attribués directement sur le bucket, ainsi que 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. Il est possible que certains comptes principaux n'accèdent qu'à d'autres buckets Cloud Storage qui ne sont pas liés à 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 fournissent des 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 la table de mappage de rôles pour vous aider à attribuer les rôles appropriés si l'accès à Artifact Registry est approprié.

Le tableau suivant mappe 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 obligatoire Rôle actuel Rôle Artifact Registry Où attribuer le rôle
Extraire uniquement des images (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 extraire des images (lecture et écriture)
  • Supprimer des images
Rédacteur des anciens buckets de l'espace de stockage
(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ôts Artifact Registry Create-on-Push
(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 disposent de 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. 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.

Consultez la documentation de référence sur les rôles de l'agent de service pour en savoir plus sur les autorisations associées aux rôles de l'agent de service.

Rôles personnalisés

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

Pour savoir comment attribuer des rôles Artifact Registry, consultez la page 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 les buckets Cloud Storage correspondants dans votre projet. Si vous disposez d'une automatisation pour Container Registry qui 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 de chiffrement 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 les dépôts gcr.io vous-même et spécifier CMEK comme méthode de chiffrement lorsque vous les créez.

Pour créer manuellement un dépôt gcr.io, procédez comme suit:

  1. Si vous utilisez une clé CMEK, créez la clé que vous utiliserez avec ce dépôt et accordez les autorisations nécessaires pour l'utiliser. Consultez la section 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ôt 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 avec une clé de chiffrement 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ôt 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 répertoriant vos dépôts à l'aide de la commande suivante:

    gcloud artifacts repositories list
    

Étapes suivantes

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