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

Avant de commencer

1. Créez un dépôt Artifact Registry. Si vous avez choisi la méthode manuelle pour la transition, suivez les étapes 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 règles d'autorisation et accorder l'accès aux dépôts Artifact Registry, demandez à votre administrateur de vous attribuer les rôles IAM suivants sur le projet, le dossier ou l'organisation que vous souhaitez analyser pour les autorisations :

• Lecteur d'éléments Cloud (roles/cloudasset.viewer)
• Pour analyser les stratégies avec des rôles IAM personnalisés : Lecteur de rôle (roles/iam.roleViewer)
• Pour utiliser la Google Cloud CLI afin d'analyser les règles : Utilisateur de Service Usage (roles/serviceusage.serviceUsageConsumer)
• Pour attribuer des rôles sur un dépôt Artifact Registry : Administrateur Artifact Registry

Pour en savoir plus sur l'attribution de rôles, consultez 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 :

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 qui se trouvent dans les rôles Cloud Storage prédéfinis et les mappe aux rôles Artifact Registry. Pour comparer les autorisations Cloud Storage aux rôles Artifact Registry, consultez 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 l'outil doit analyser :

     • gcr.io
     • asia.gcr.io
     • eu.gcr.io
     • us.gcr.io

   • PROJECT_ID est l'ID du Google Cloud projet avec l'hôte de registre que vous analysez.

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

   L'exemple de commande suivant analyse le bucket de stockage gcr.io dans le projet my-project pour les stratégies d'autorisation qui sont appliquées directement au bucket ou qui sont héritées de l'ID d'organisation parent 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 l'accès a été accordé au niveau du dossier ou de l'organisation.

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

   • Les 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
   • 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. Examinez les autres liaisons de rôle pour vérifier qu'elles sont appropriées.

   Artifact Registry propose des rôles prédéfinis supplémentaires que vous pouvez envisager d'attribuer à certains comptes principaux. Par exemple, le rôle "Administrateur de dépôt Artifact Registry avec création lors de l'envoi" permet à un compte 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.

   Il est possible que les comptes principaux suivants ne figurent pas dans le fichier de stratégie renvoyé :

   • Les comptes principaux disposent de rôles personnalisés, et ces rôles personnalisés ne disposent pas des ensembles d'autorisations que l'outil utilisait pour mapper les rôles.
   • Les comptes principaux auxquels l'accès a été accordé dans un dossier ou une organisation parents si vous ne disposez pas des autorisations nécessaires pour afficher un dossier ou une organisation parents.

5. Appliquez les liaisons de stratégie à 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 règle du fichier gcr-io-policy.yaml au dépôt nommé gcr.io dans la région multirégionale 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ôle à une ressource de niveau supérieur, modifiez la stratégie de projet, de dossier ou d'organisation existante en y ajoutant les liaisons souhaitées.

Mappages de rôles

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