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

Découvrez comment configurer des dépôts gcr.io dans Artifact Registry et en savoir plus sur les différences entre les autorisations Artifact Registry et Container Registry, et le bucket de stockage configuration.

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

Abandon de Container Registry

Projets Google Cloud n'ayant jamais utilisé Container Registry auparavant À compter du 15 mai 2024, vous ne pourrez héberger et gérer des images que 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.

Organisations n'ayant jamais utilisé Container Registry auparavant Le 8 janvier 2024, de nouveaux dépôts gcr.io seront hébergés sur Artifact Registry par défaut.

Lorsque vous activez l'API Artifact Registry dans ces projets, Artifact Registry gèrent automatiquement la création de dépôts gcr.io dans Artifact Registry et rediriger les requêtes vers le domaine gcr.io vers le dépôt Artifact Registry approprié un dépôt de clés. Contrairement à la compatibilité des domaines gcr.io existante dans les projets avec une utilisation active de Container Registry, la redirection vers Artifact Registry sera automatique.

Container Registry restera disponible dans les projets où l'un des éléments suivants actions antérieures au 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 qui n'utilisent pas Container Registry et sont donc prêts pour le traitement automatique requêtes sur gcr.io lorsque les modifications prennent effet.
  • Tester la compatibilité du domaine gcr.io pour vérifier que l'automatisation existante continuera de fonctionner.

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

Rôles requis

Pour obtenir les autorisations dont vous avez besoin pour configurer les dépôts "gcr.io", demandez à votre administrateur de vous accorder le 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 de projet IAM (roles/resourcemanager.projectIamAdmin) ou un rôle comprenant 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) 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 votre Google Cloud ID de l'organisation.

Vous pouvez également lister l'utilisation de Container Registry pour votre projet ou dossier. Pour plus sur l'utilisation de Container Registry, consultez Vérifiez 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 gérée par Artifact Registry lors de l'activation automatique de l'hébergement gcr.io.

  1. Exécutez la commande suivante :

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

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 Les rôles et ces rôles séparent les rôles de lecture, d'écriture et d'administration de référentiels Container Registry.

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

Vous pouvez également afficher la liste des comptes principaux ayant accès à l'espace 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 à Google Cloud ID du projet.

    • 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 inclut les rôles IAM attribués directement sur le bucket et les rôles hérités du projet parent. Selon le rôle, vous pouvez choisir le rôle Artifact Registry le plus approprié à attribuer.

Cloud Storage et rôles de base

Accorder des autorisations aux utilisateurs et aux comptes de service qui ont actuellement accès à Container Registry avec un accès aux dépôts Artifact Registry. Pour 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 les rôles IAM Accès limité aux buckets de stockage Ils n'offrent pas intrinsèquement tout l'accès à Cloud Storage aux ressources que leur nom implique et fournissent des autorisations supplémentaires pour d'autres services Google Cloud. Vérifiez les utilisateurs et les comptes de service accès à Artifact Registry et utiliser la table de mappage des rôles pour vous accordez 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 rôles Cloud Storage prédéfinis pour accéder à 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 envoyé 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 et les rôles attribués au niveau du projet. Par exemple, l'agent de service Cloud Run dispose du rôle "Agent de service Cloud Run".

Dans la plupart des cas, ces rôles d'agent de service contiennent des valeurs pour Container Registry et Artifact Registry, aucune modification supplémentaire n'est requise si vous exécutez Artifact Registry dans le même projet que votre registre Container Registry existant Google Cloud.

Consultez le documentation de référence sur les rôles d'agent de service pour plus de détails 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 à accorder 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 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 de votre projet. Si vous utilisez l'automatisation pour Container Registry qui interagit directement avec les buckets de stockage, vous devez mettre à jour pour modifier le dépôt Artifact Registry.

Par exemple, si vous accordez par programmation des autorisations Cloud Storage des buckets de stockage pour Container Registry, vous devez mettre à jour cette automatisation pour accorder Autorisations Artifact Registry sur les dépôts Artifact Registry hébergeant des images 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. au lieu d'un bucket de stockage. L'hébergement automatique de gcr.io sur Artifact Registry crée Dépôts gcr.io chiffrés avec des clés appartenant à Google 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 gcr.io dépôts vous-même et spécifiez CMEK comme méthode de chiffrement lorsque lorsque vous les créez.

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 accorder les autorisations nécessaires à l'utilisation de la clé. Voir 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 des 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 Create (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. À ne pas faire inclure des données sensibles, car les descriptions de référentiel ne sont pas chiffrées.

    • KMS-KEY est le chemin d'accès complet au 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 en exécutant la commande suivante:

    gcloud artifacts repositories list
    

Étape suivante

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