Mappage des rôles IAM de Container Registry vers Artifact Registry

Ce document explique comment mapper des rôles Container Registry à des rôles Artifact Registry et les appliquer à un dépôt Artifact Registry. Vous pouvez suivre les mêmes étapes à l'aide de l'outil de migration automatique.

Container Registry et Artifact Registry utilisent différents rôles IAM (Identity and Access Management) pour contrôler l'accès aux images de conteneur stockées dans le registre.

Pour vous aider à passer de Container Registry à Artifact Registry, vous pouvez exécuter une commande Google Cloud CLI qui:

  • Identifie les règles d'autorisation qui s'appliquent à un bucket de stockage Cloud Storage qui stocke des images pour Container Registry
  • Renvoie une stratégie avec des rôles Artifact Registry similaires afin que vous puissiez accorder à vos utilisateurs Container Registry existants l'accès aux dépôts Artifact Registry.

La commande utilise Policy Analyzer pour analyser les stratégies d'autorisation IAM.

Avant de commencer

  1. Créez un dépôt Artifact Registry. Si vous avez choisi la méthode manuelle pour la transition, suivez la procédure pour migrer manuellement vers les dépôts gcr.io dans Artifact Registry ou migrer manuellement vers les dépôts pkg.dev.

  2. Enable the Cloud Asset API.

    Enable the API

    Vous devez activer l'API dans le projet dans lequel vous souhaitez analyser les règles d'autorisation existantes.

  3. Installez et initialisez gcloud CLI. Pour une installation existante, passez à la dernière version à l'aide de la commande suivante:

    gcloud components update
    

Rôles requis

Pour obtenir les autorisations nécessaires pour analyser les stratégies d'autorisation et accorder l'accès aux dépôts Artifact Registry, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet, le dossier ou l'organisation pour lesquels vous souhaitez analyser les autorisations:

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour analyser les stratégies d'autorisation et accorder l'accès aux dépôts Artifact Registry. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour analyser les règles d'autorisation et accorder l'accès aux dépôts Artifact Registry:

  • cloudasset.assets.analyzeIamPolicy
  • cloudasset.assets.searchAllResources
  • cloudasset.assets.searchAllIamPolicies
  • Pour analyser les règles avec des rôles IAM personnalisés : iam.roles.get
  • Pour analyser les règles à l'aide de la Google Cloud CLI : serviceusage.services.use
  • Pour attribuer des rôles à un dépôt Artifact Registry : artifactregistry.repositories.setIamPolicy

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

Utiliser l'outil de mappage

L'outil de mappage vérifie les règles d'autorisation pour un nom d'hôte Container Registry spécifié, tel que gcr.io.

L'outil recherche des ensembles d'autorisations dans des rôles Cloud Storage prédéfinis et les met en correspondance avec des rôles Artifact Registry. Pour comparer les autorisations Cloud Storage aux rôles Artifact Registry, consultez la section Mappages de rôles.

Pour utiliser l'outil de mappage des rôles:

  1. Exécutez l'outil de mappage:

    gcloud beta artifacts docker upgrade print-iam-policy HOSTNAME \
        --project=PROJECT_ID > POLICY_FILENAME
    

    Remplacez les valeurs suivantes :

    • HOSTNAME correspond au nom d'hôte Container Registry que vous souhaitez que l'outil analyse:

      • gcr.io
      • asia.gcr.io
      • eu.gcr.io
      • us.gcr.io
    • PROJECT_ID correspond à l'ID du projet Google Cloud avec l'hôte du Registre que vous analysez.

    • POLICY_FILE est le nom de fichier de la stratégie, au format YAML, que l'outil renverra.

    L'exemple de commande suivant analyse le bucket de stockage pour gcr.io dans le projet my-project afin d'identifier les stratégies d'autorisation appliquées directement au bucket ou héritées de l'ID de l'organisation parente 101231231231 et de ses descendants.

    gcloud beta artifacts docker upgrade print-iam-policy gcr.io \
        --project=my-project > gcr-io-policy.yaml
    

    La commande renvoie un fichier de stratégie au format YAML avec des liaisons de rôle Artifact Registry, en fonction des règles d'autorisation existantes pour le bucket de stockage. Si le projet parent du bucket de stockage se trouve dans une organisation, le fichier de règles inclut les comptes principaux auxquels un accès est accordé au niveau du dossier ou de l'organisation.

    Par exemple, l'exemple suivant inclut des liaisons de rôle Artifact Registry pour:

    • Agents de service Cloud Build, Compute Engine et Container Registry Les agents de service agissent au nom des servicesGoogle Cloud .
    • Compte utilisateur user@example.com
    • Le compte de service géré par l'utilisateur deploy@my-project.iam.gserviceaccount.com.
    bindings:
    - members:
      - service-3213213213213@gcp-sa-cloudbuild.iam.gserviceaccount.com
      - user:user@example.com
      role: roles/artifactregistry.repoAdmin
    - members:
      - serviceAccount:deploy@my-project.iam.gserviceaccount.com
      - serviceAccount:service-1231231231231@@compute-system.iam.gserviceaccount.com
      - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
      role: roles/artifactregistry.reader
    
  2. Supprimez la ligne de l'agent de service Container Registry du fichier de règles, car ce compte de service n'a pas besoin d'accéder à vos dépôts Artifact Registry. Le suffixe de l'adresse e-mail de l'agent de service est containerregistry.iam.gserviceaccount.com.

    Dans l'exemple de règle de l'étape précédente, la ligne avec l'agent de service Container Registry est la suivante:

    - serviceAccount:service-1231231231231@containerregistry.iam.gserviceaccount.com
    
  3. Passez en revue les autres liaisons de rôles pour vous assurer qu'elles sont appropriées.

    Artifact Registry propose des rôles prédéfinis supplémentaires que vous pouvez envisager d'utiliser pour certains comptes principaux. Par exemple, l'administrateur de dépôt Artifact Registry avec création lors de l'envoi permet à un principal de créer des dépôts gcr.io dans Artifact Registry, mais pas d'autres dépôts Artifact Registry.

  4. Ajoutez des liaisons de rôle pour tous les comptes principaux manquants dans le fichier de stratégie.

    Les comptes principaux suivants peuvent être manquants dans le fichier de stratégie renvoyé:

    • Les principaux disposant de rôles personnalisés, et ces rôles personnalisés ne disposent pas des ensembles d'autorisations que l'outil a utilisés pour mapper les rôles.
    • Comptes principaux auxquels un accès a été accordé sur un dossier ou une organisation parent si vous n'êtes pas autorisé à afficher un dossier ou une organisation parent.
  5. Appliquez les liaisons de règles à vos dépôts Artifact Registry.

    gcloud artifacts repositories set-iam-policy REPOSITORY FILENAME \
        --project=PROJECT_ID \
        --location=LOCATION
    

    Remplacez les valeurs suivantes :

    • REPOSITORY est le nom du dépôt.
    • POLICY_FILENAME correspond au nom du fichier de stratégie que vous appliquez au dépôt.
    • PROJECT_ID est l'ID de projet.
    • LOCATION est l'emplacement régional ou multirégional du dépôt.

    L'exemple suivant pour le projet my-project applique la stratégie du fichier gcr-io-policy.yaml au dépôt nommé gcr.io dans l'emplacement multirégional us:

    gcloud artifacts repositories set-iam-policy gcr.io gcr-io-policy.yaml \
        --project=my-project \
        --location=us
    

    Si vous souhaitez appliquer des liaisons de rôles à une ressource de niveau supérieur, modifiez la stratégie de projet, de dossier ou d'organisation existante avec les liaisons que vous souhaitez ajouter.

Mappages de rôles

Le tableau suivant indique les rôles prédéfinis d'Artifact Registry à accorder aux utilisateurs existants de Container Registry en fonction des autorisations Cloud Storage dont ils disposent.

Autorisations requises dans le rôle Rôle Artifact Registry
storage.objects.get
storage.objects.list
Lecteur Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
Rédacteur Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
storage.objects.delete
Administrateur de dépôt Artifact Registry
storage.buckets.get
storage.objects.get
storage.objects.list
storage.objects.create
storage.buckets.create
Administrateur Artifact Registry