Cette page a été traduite par l'API Cloud Translation.

Configurer les rôles et les autorisations

Cette page décrit comment accorder des autorisations aux dépôts Artifact Registry.

Avant de commencer

Activez Artifact Registry, y compris en activant l'API et en installant Google Cloud CLI.
Créez les dépôts pour vos packages si vous souhaitez appliquer des autorisations spécifiques aux dépôts.

Présentation

Artifact Registry est entièrement intégré aux services Google Cloud pour la mise en œuvre d'un pipeline CI/CD, et comporte des autorisations par défaut afin de minimiser les efforts de configuration. Vous pouvez également intégrer Artifact Registry à des outils CI/CD tiers et configurer les autorisations et l'authentification requises pour accéder aux dépôts.

Si vous utilisez Container Analysis pour travailler avec des métadonnées de conteneur, telles que les failles trouvées dans les images, consultez la documentation de Container Analysis pour savoir comment accorder l'accès permettant d'afficher ou de gérer les métadonnées.

Intégration à Google Cloud

Par défaut, les autorisations suivantes s'appliquent aux services Google Cloud CI/CD dans le même projet que Artifact Registry :

Les autorisations Cloud Build incluent des autorisations permettant d'importer et de télécharger des artefacts.
Compute Engine, les versions compatibles de Google Kubernetes Engine et Cloud Run utilisent le compte de service par défaut Compute Engine, qui dispose d'un accès en lecture seule à l'espace de stockage.

Si tous vos services appartiennent au même projet Google Cloud et que les autorisations par défaut répondent à vos besoins, vous n'avez pas besoin de configurer des autorisations.

Vous devez configurer les autorisations d'Artifact Registry pour ces services dans les cas suivants :

Vous souhaitez utiliser ces services pour accéder à Artifact Registry dans un autre projet. Dans le projet avec Artifact Registry, accordez au compte de service le rôle requis pour chaque service. Si vous vous connectez à Cloud Run, accordez le rôle requis à l'agent de service Cloud Run.
Vous utilisez une version de GKE qui n'est pas compatible avec l'extraction d'images d'Artifact Registry. Consultez la section GKE pour obtenir des instructions de configuration.
Vous souhaitez que le compte de service par défaut dispose d'un accès en lecture et en écriture aux dépôts. Pour en savoir plus, consultez les informations suivantes :
- Compute Engine
- GKE
Vous utilisez un compte de service fourni par l'utilisateur pour vos environnements d'exécution plutôt que le compte de service par défaut. Dans le projet avec Artifact Registry, accordez à votre compte de service le rôle requis.

Intégration tierce

Pour les clients tiers, vous devez configurer à la fois les autorisations et l'authentification.

Créez un compte de service pour agir au nom de votre application ou sélectionnez un compte de service existant que vous utilisez pour l'automatisation CI/CD.
Accordez le rôle Artifact Registry approprié au compte de service afin de fournir l'accès au dépôt.
Configurez votre client tiers pour qu'il s'authentifie auprès d'Artifact Registry.
- Images de conteneurs: Docker et Helm
- Packages de langage: Java, Node.js, Python, Go
- Packages de système d'exploitation: Debian et RPM
- Autre: Modèles de pipeline Kubeflow

Rôles et autorisations

Accordez une autorisation Identity and Access Management (IAM) en attribuant un rôle qui inclut l'autorisation. Vous pouvez accorder des autorisations au niveau du projet ou du dépôt.

Rôles Artifact Registry prédéfinis

IAM fournit des rôles prédéfinis qui accordent l'accès à des ressources Google Cloud spécifiques et empêchent les accès non autorisés aux autres ressources.

Les rôles prédéfinis suivants sont disponibles pour Artifact Registry:

Rôle	Description
Lecteur Artifact Registry (`roles/artifactregistry.reader`)	Afficher et obtenir des artefacts, afficher les métadonnées du dépôt
Rédacteur Artifact Registry (`roles/artifactregistry.writer`)	Lire et écrire des artefacts.
Rédacteur Artifact Registry Create-on-push (`roles/artifactregistry.createOnPushWriter`)	Lire et écrire des artefacts. Créez des dépôts gcr.io lorsque la première image est transférée vers un hôte du domaine `gcr.io`.
Administrateur de dépôts Artifact Registry (`roles/artifactregistry.repoAdmin`)	Lire, écrire et supprimer des artefacts.
Administrateur de dépôt Create-on-push Artifact Registry (`roles/artifactregistry.createOnPushRepoAdmin`)	Lire, écrire et supprimer des artefacts. Créez des dépôts gcr.io lorsque la première image est transférée vers un hôte du domaine `gcr.io`.
Administrateur Artifact Registry (`roles/artifactregistry.admin`)	Créez et gérez des dépôts et des artefacts.

Pour obtenir la liste complète des autorisations individuelles de chaque rôle, consultez la section Rôles Artifact Registry. Vous pouvez également utiliser la commande gcloud iam roles describe pour afficher une liste des autorisations dans chaque rôle.

Rôles IAM de base

Les rôles IAM de base accordent aux utilisateurs un accès global, au niveau du projet, à toutes les ressources Google Cloud. Dans la mesure du possible, utilisez des rôles prédéfinis pour que les utilisateurs et les comptes de service disposent uniquement des autorisations requises.

Le tableau suivant répertorie les rôles de base qui existaient avant IAM et les rôles IAM Artifact Registry qu'ils incluent :

Rôle	Nom du rôle	Inclus le rôle
`roles/viewer`	Lecteur	`roles/artifactregistry.reader`
`roles/editor`	Éditeur	`roles/artifactregistry.writer` `roles/artifactregistry.repoAdmin`
`roles/owner`	Owner	`roles/artifactregistry.admin`

Accorder des autorisations

Accordez des autorisations au niveau du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet. Si certains comptes nécessitent différents niveaux d'accès, attribuez des rôles au niveau du dépôt.

Si vous attribuez des rôles à l'aide de la commande gcloud, vous pouvez spécifier une liaison de rôle unique pour un compte principal ou utiliser un fichier de stratégie pour définir plusieurs liaisons.

Le modèle de règle de référence suivant est utilisé pour les exemples de cette page. Le fichier de règles de référence est nommé policy.yaml. Le modèle contient des exemples de noms d'utilisateurs et de comptes de service. Remplacez ces exemples d'utilisateurs et de comptes de service en fonction de votre projet.

Pour en savoir plus sur le format d'une stratégie, consultez la documentation sur la stratégie IAM.

bindings:

- members:
  - user: user@gmail.com
  role: roles/owner

- members:
  - serviceAccount: repo-readonly@iam.gserviceaccount.com
  - user: user2@gmail.com
  role: roles/artifactregistry.reader

- members:
  - serviceAccount: repo-write@iam.gserviceaccount.com
  role: roles/artifactregistry.writer

- members:
  - serviceAccount: repo-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.repoAdmin

- members:
  - serviceAccount: ar-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.admin

Accorder des autorisations à l'échelle du projet

Attribuez un rôle au niveau du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

Pour ajouter un membre d'équipe à un projet et lui attribuer un rôle Artifact Registry:

Console

Ouvrez la page "IAM" dans Google Cloud Console.
Ouvrir la page IAM
Cliquez sur Sélectionner un projet, choisissez le projet dans lequel Artifact Registry est en cours d'exécution, puis cliquez sur Ouvrir.
Cliquez sur Ajouter.
Saisissez une adresse e-mail. Vous pouvez ajouter des personnes, des comptes de service ou des groupes Google en tant que comptes principaux.
Sélectionnez un rôle pour le compte principal. Conformément au principe de sécurité du moindre privilège, pensez à accorder le minimum de privilèges nécessaires pour empêcher tout accès indésirable à d'autres ressources.
Cliquez sur Enregistrer.

gcloud

Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Pour attribuer un rôle à un seul compte principal, exécutez la commande suivante:
```
gcloud projects add-iam-policy-binding PROJECT \
   --member=PRINCPAL \
   --role=ROLE
```
Où :
- PROJECT est l'ID du projet dans lequel Artifact Registry est en cours d'exécution.
- PRINCIPAL est le compte principal pour lequel vous souhaitez ajouter la liaison. Utilisez le formulaire user|group|serviceAccount:email ou domain:domain.
  
  Exemples : user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com ou domain:example.domain.com.
- ROLE est le rôle que vous souhaitez accorder.
Pour en savoir plus, consultez la documentation sur add-iam-policy-binding.

Pour attribuer des rôles à l'aide d'un fichier de stratégie, exécutez la commande suivante :
```
gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml
```
Où :
- PROJECT est l'ID du projet ou l'identifiant complet du projet dans lequel Artifact Registry est en cours d'exécution.
- /PATH/TO/policy.yaml est le chemin d'accès et le nom du fichier de stratégie.
Pour obtenir la stratégie actuellement configurée, exécutez la commande suivante :
```
gcloud projects get-iam-policy PROJECT
```
Où PROJECT est l'ID du projet ou à l'identifiant complet du projet.

Pour en savoir plus, consultez la documentation sur set-iam-policy.

Accorder des autorisations spécifiques au dépôt

Accordez des autorisations au niveau du dépôt lorsque vous souhaitez que les utilisateurs ou les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

Console

Pour accorder l'accès à un dépôt spécifique, procédez comme suit :

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

Ouvrir la page "Dépôts"
Sélectionnez le dépôt approprié.
Si le panneau d'informations ne s'affiche pas, cliquez sur Afficher le panneau d'informations dans la barre de menu.
Dans l'onglet "Autorisations", cliquez sur Ajouter un compte principal.
Saisissez une adresse e-mail. Vous pouvez ajouter des personnes, des comptes de service ou des groupes Google en tant qu'entités principales.
Sélectionnez un rôle pour le compte principal. Nous vous recommandons d'accorder au compte principal le minimum de privilèges nécessaires.
Cliquez sur Enregistrer.

gcloud

Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Vous pouvez définir un ensemble IAM de liaisons de stratégie individuelles ou utiliser un fichier de stratégie.

Pour attribuer un rôle à un seul compte principal, exécutez la commande suivante:
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location LOCATION \
   --member=PRINCIPAL \
   --role=ROLE
```
Où :
- REPOSITORY est l'ID du dépôt.
- PRINCIPAL est le compte principal pour lequel vous souhaitez ajouter la liaison. Utilisez le formulaire user|group|serviceAccount:email ou domain:domain.
  
  Exemples : user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com ou domain:example.domain.com.
- ROLE est le rôle que vous souhaitez accorder.
- LOCATION est l'emplacement régional ou multirégional du dépôt.
Par exemple, pour ajouter une liaison de stratégie IAM pour le rôle roles/artifactregistry.writer de l'utilisateur write@gmail.com avec le dépôt my-repo à l'emplacement --us-central1, exécutez la commande suivante :
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
Pour attribuer des rôles à l'aide d'un fichier de stratégie, exécutez la commande suivante :
```
gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION
```
Où :
- REPOSITORY est l'ID du dépôt.
- /PATH/TO/policy.yaml est le chemin d'accès et le nom du fichier de stratégie.
- LOCATION est l'emplacement régional ou multirégional du dépôt.
Par exemple, pour définir la stratégie IAM du dépôt my-repo à l'emplacement --us-central1 avec la stratégie définie dans policy.yaml, exécutez la commande suivante :
```
gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
```

Terraform

Utilisez la ressource google_artifact_registry_repository_iam pour configurer une stratégie IAM. L'exemple suivant définit un compte de service portant le nom de ressource repo-account et lui accorde un accès en lecture à un dépôt portant le nom de ressource my-repo.

Si vous débutez avec Terraform pour Google Cloud, consultez la page Premiers pas – Google Cloud sur le site Web de HashiCorp.

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

ACCOUNT-ID est l'ID du compte de service. Il s'agit de la partie du champ d'adresse e-mail du compte de service avant le symbole @.

Pour obtenir des exemples supplémentaires, consultez la documentation de la ressource google_artifact_registry_repository_iam.

Configurer l'accès public à un dépôt

Si vous souhaitez mettre des artefacts à la disposition de tous les internautes sans authentification, stockez-les dans un dépôt que vous rendez public.

Pour configurer un dépôt pour un accès public en lecture seule, accordez le rôle "Lecteur Artifact Registry" au compte principal allUsers. Nous vous recommandons également de limiter les quotas de requêtes utilisateur afin qu'un seul utilisateur ne puisse pas utiliser le quota global de votre projet.

Console

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

Ouvrir la page "Dépôts"
Sélectionnez le dépôt approprié.
Si le panneau d'informations ne s'affiche pas, cliquez sur Afficher le panneau d'informations dans la barre de menu.
Dans l'onglet "Autorisations", cliquez sur Ajouter un compte principal.
Dans le champ Nouveaux comptes principaux, saisissez allUsers.
Sélectionnez le rôle Lecteur Artifact Registry.
Définissez une limite de requêtes par utilisateur sur l'API Artifact Registry pour éviter tout usage abusif par des utilisateurs non authentifiés. Pour savoir comment procéder, consultez la section Limiter l'utilisation des ressources.

gcloud

Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Exécutez la commande suivante :
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location=LOCATION --member=allUsers --role=ROLE
```
Où :
- REPOSITORY est l'ID du dépôt.
- ROLE est le rôle que vous souhaitez accorder.
- LOCATION est l'emplacement régional ou multirégional du dépôt.
Par exemple, configurez le dépôt my-repo à l'emplacement --us-central1 en tant qu'emplacement public en exécutant la commande suivante :
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
```
Définissez une limite de requêtes par utilisateur sur l'API Artifact Registry pour éviter tout usage abusif par des utilisateurs non authentifiés. Pour savoir comment procéder, consultez la section Limiter l'utilisation des ressources.

Révoquer des autorisations

Pour révoquer l'accès à un dépôt, supprimez le compte principal de la liste des comptes principaux autorisés.

Pour supprimer l'accès public d'un dépôt, supprimez le compte principal allUsers.

Console

Pour révoquer des autorisations :

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

Ouvrir la page "Dépôts"
Sélectionnez le dépôt approprié.
Si le panneau d'informations ne s'affiche pas, cliquez sur Afficher le panneau d'informations dans la barre de menu.
Dans l'onglet "Autorisations", développez le compte principal concerné. Si vous rendez privé un dépôt public, développez le compte principal allUsers.
Cliquez sur Supprimer le compte principal pour révoquer l'accès.

gcloud

Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Pour révoquer un rôle au niveau du projet, exécutez la commande suivante :
```
gcloud projects remove-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
```
- PROJECT est l'ID de projet.
- PRINCIPAL est le compte principal pour lequel la liaison est supprimée. Utilisez le formulaire user|group|serviceAccount:email ou domain:domain.
  
  Exemples : user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com ou domain:example.domain.com.
- ROLE est le rôle que vous souhaitez révoquer.
Pour révoquer un rôle dans un dépôt, exécutez la commande suivante :
```
gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
   --member=PRINCIPAL \
   --role=ROLE
```
Où :
- REPOSITORY est l'ID du dépôt.
- PRINCIPAL est le compte principal pour lequel la liaison est supprimée. Utilisez le formulaire user|group|serviceAccount:email ou domain:domain.
  
  Exemples : user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com ou domain:example.domain.com.
  
  Pour révoquer l'accès public au dépôt, spécifiez le compte principal allUsers.
- ROLE est le rôle que vous souhaitez révoquer.
Par exemple, pour supprimer une liaison de stratégie pour le rôle roles/artifactregistry.writer de l'utilisateur write@gmail.com avec le dépôt my-repo à l'emplacement --us-central1, exécutez la commande suivante:
```
gcloud artifacts repositories remove-policy-binding my-repo \
   --location=us-central1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer
```
Pour révoquer l'accès public à my-repo à l'emplacement --us-central1, exécutez:
```
gcloud artifacts repositories remove-policy-binding my-repo \
   --location=us-central1 \
   --member=allUsers \
   --role=roles/artifactregistry.reader
```

Accorder un accès conditionnel avec des tags

Cette fonctionnalité est en version bêta.

Les administrateurs de projet peuvent créer des tags pour les ressources de Google Cloud et les gérer dans Resource Manager. Lorsque vous associez un tag à un dépôt Artifact Registry, les administrateurs peuvent l'utiliser avec des conditions IAM pour accorder un accès conditionnel au dépôt.

Vous ne pouvez pas associer de tags à des artefacts individuels.

Pour en savoir plus, consultez la documentation suivante:

Administrateurs configurant des tags et contrôle des accès
- Créer et gérer des tags
- Tags et contrôle d'accès.
Développeurs attachant des tags aux dépôts
- Ajouter des tags aux dépôts

Intégrer les services Google Cloud

Pour la plupart des comptes de service Google Cloud, il suffit d'accorder les autorisations IAM appropriées pour configurer l'accès à un registre.

Autorisations par défaut pour les services Google Cloud

Les services Google Cloud tels que Cloud Build ou Google Kubernetes Engine utilisent un compte de service par défaut ou géré par Google pour interagir avec les ressources d'un même projet.

Vous devez configurer ou modifier vous-même les autorisations dans les cas suivants :

Le service Google Cloud se trouve dans un projet différent de celui d'Artifact Registry.
Les autorisations par défaut ne répondent pas à vos besoins. Par exemple, le compte de service Compute Engine par défaut dispose d'un accès en lecture seule à l'espace de stockage dans le même projet. Si vous souhaitez transférer une image d'une VM vers Artifact Registry, vous pouvez modifier les autorisations du compte de service de la VM ou utiliser un autre compte disposant des autorisations requises.
Vous utilisez un compte de service fourni par l'utilisateur pour interagir avec Artifact Registry au lieu du compte de service par défaut.

Les comptes de service suivants accèdent généralement à Artifact Registry. L'adresse e-mail du compte de service inclut l'ID ou le numéro du projet Google Cloud sur lequel le service est exécuté.

Service	Compte de service	Adresse e-mail	Autorisations
Environnement flexible App Engine	Compte de service App Engine	`PROJECT-ID`@appspot.gserviceaccount.com	Rôle d'éditeur, lecture et écriture dans les dépôts
Compute Engine	Compte de service Compute Engine par défaut	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rôle éditeur, limité à un accès en lecture seule aux dépôts
Cloud Build	Compte de service Cloud Build	`PROJECT-NUMBER`@cloudbuild.gserviceaccount.com	Les autorisations par défaut incluent un accès en lecture et en écriture aux dépôts.
Cloud Run	Agent de service Cloud Run Agent de service pour `run.googleapis.com`.	service-`PROJECT-NUMBER`@serverless-robot-prod.iam.gserviceaccount.com	Autorisations de lecteur, limitées à un accès en lecture seule aux dépôts
GKE	Compte de service Compute Engine par défaut Compte de service par défaut pour les nœuds.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rôle éditeur, limité à un accès en lecture seule aux dépôts

Accorder l'accès aux instances Compute Engine

Les instances de VM qui accèdent aux dépôts doivent disposer des autorisations Artifact Registry et avoir le niveau d'accès à l'espace de stockage configuré.

Alors que le niveau d'accès d'un compte de service est déterminé par les rôles IAM qui lui sont attribués, les champs d'application d'accès sur une instance de VM déterminent les champs d'application OAuth par défaut pour les requêtes effectuées via la gcloud CLI et les bibliothèques clientes sur l'instance. Par conséquent, les niveaux d'accès peuvent limiter davantage l'accès aux méthodes d'API lors de l'authentification avec des identifiants par défaut de l'application.

Compute Engine utilise les valeurs par défaut suivantes:

Le compte de service Compute Engine par défaut est l'identité des instances de VM. L'adresse e-mail du compte de service porte le suffixe @developer.gserviceaccount.com.
Le compte de service par défaut dispose du rôle de base IAM Éditeur si vous n'avez pas désactivé ce comportement.
Les instances que vous créez avec le compte de service par défaut disposent des champs d'application d'accès par défaut Compute Engine, y compris un accès en lecture seule à l'espace de stockage. Bien que le rôle Éditeur accorde généralement un accès en écriture, le niveau d'accès au stockage read-only limite le compte de service de l'instance au téléchargement d'artefacts uniquement à partir de n'importe quel dépôt du même projet.

Vous devez configurer le niveau d'accès du compte de service dans les cas suivants :

Le compte de service de VM doit accéder au dépôt d'un autre projet.
Le compte de service de VM doit effectuer d'autres actions que la lecture d'artefacts à partir de dépôts. Cela s'applique généralement aux outils tiers d'une VM qui doit transférer des images ou exécuter les commandes gcloud d'Artifact Registry.

Pour configurer les autorisations et définir le niveau d'accès :

Dans le projet contenant votre instance de VM, obtenez le nom du compte de service Compute Engine par défaut. L'adresse e-mail associée au compte de service comporte le suffixe @developer.gserviceaccount.com.
Dans le projet contenant le dépôt, accordez des autorisations pour que le compte de service puisse accéder au dépôt.
Définissez le niveau d'accès avec l'option --scopes.
1. Arrêtez l'instance de VM. Consultez la section Arrêter une instance.
2. Définissez le niveau d'accès à l'aide de la commande suivante
```
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
```
  Remplacez SCOPE par la valeur appropriée.
  - Pour Docker, les options suivantes sont acceptées :
    - storage-ro : accorde un accès en lecture pour obtenir des images uniquement.
    - storage-rw : accorde un accès en lecture et en écriture pour le transfert ou l'extraction d'images.
    - cloud-platform : consultez et gérez les données, y compris les métadonnées, dans l'ensemble du service Google Cloud.
  - Pour les autres formats, vous devez utiliser le niveau d'accès cloud-platform.
3. Redémarrez l'instance de VM. Consultez la section Démarrer une instance arrêtée.

Accorder l'accès aux clusters Google Kubernetes Engine

Les clusters et les pools de nœuds GKE peuvent extraire des conteneurs sans configuration supplémentaire si toutes les conditions suivantes sont remplies:

GKE se trouve dans le même projet que celui qui contient Artifact Registry.
Les nœuds utilisent le compte de service par défaut : le compte de service Compute Engine par défaut.
Les nœuds ont été créés avec un accès en lecture à l'espace de stockage par :
- Utiliser les niveaux d'accès par défaut de Compute Engine
- Accorder au niveau d'accès cloud-platform ou à un autre niveau d'accès incluant un accès en lecture à l'espace de stockage.
Vous exécutez une version compatible de GKE.

Si votre environnement GKE ne répond pas à ces exigences, les instructions pour accorder l'accès varient selon que vous utilisez le compte de service Compute Engine par défaut ou un compte de service fourni par l'utilisateur comme identité pour vos nœuds.

Compte de service par défaut

Les exigences de configuration suivantes s'appliquent au compte de service Compute Engine par défaut :

Si GKE se trouve dans un projet différent de celui d'Artifact Registry, accordez les autorisations requises au compte de service.
Pour stocker des images, interagir avec des dépôts pour des formats autres que des conteneurs ou exécuter des commandes gcloud à partir de votre cluster, vous devez définir des niveaux d'accès pour le compte de service lorsque vous créez le cluster ou le pool de nœuds.
Si vous n'utilisez pas de version compatible de GKE, configurez imagePullSecrets.

Compte de service fourni par l'utilisateur

Si vous souhaitez utiliser un compte de service fourni par l'utilisateur comme identité pour un cluster, vous devez:

Accordez les autorisations requises au compte de service du projet Google Cloud sur lequel Artifact Registry est exécuté.
Par défaut, la création d'un cluster ou d'un pool de nœuds avec un compte de service fourni par l'utilisateur accorde le niveau d'accès d'application d'accès cloud-platform.

Si vous utilisez l'option --scopes avec la commande gcloud container clusters create ou gcloud container node-pools create, vous devez inclure les niveaux d'accès appropriés à utiliser avec Artifact Registry.

Définir des niveaux d'accès

Les champs d'application d'accès constituent l'ancienne méthode de spécification d'une autorisation pour les VM Compute Engine. Pour extraire des images des dépôts Artifact Registry, les nœuds GKE doivent disposer du niveau d'accès en lecture seule ou d'un autre niveau d'accès d'accès incluant un accès en lecture.

Vous ne pouvez définir des champs d'application d'accès que lorsque vous créez un cluster ou un pool de nœuds. Vous ne pouvez pas modifier les niveaux d'accès sur les nœuds existants.

Si vous utilisez le compte de service Compute Engine par défaut, GKE crée des nœuds avec les champs d'application d'accès par défaut de Compute Engine, ce qui inclut un accès en lecture seule à l'espace de stockage.
Si vous utilisez un compte de service fourni par l'utilisateur, GKE crée des nœuds avec le champ d'application cloud-platform, requis pour la plupart des services Google Cloud.

Pour spécifier les champs d'application d'accès lors de la création d'un cluster, exécutez la commande suivante:

gcloud container clusters create NAME --scopes=SCOPES

Pour spécifier les champs d'application d'accès lors de la création d'un pool de nœuds, exécutez la commande suivante:

gcloud container node-pools create NAME --scopes=SCOPES

Remplacez les valeurs suivantes :

NAME est le nom du cluster ou du pool de nœuds.
SCOPES est une liste de champs d'application d'accès à attribuer, séparés par une virgule.
- Pour accéder aux dépôts Docker, utilisez l'un des champs d'application suivants:
- storage-ro : accorde un accès en lecture seule à l'extraction d'images.
- storage-rw : accorde un accès en lecture et en écriture pour le transfert ou l'extraction d'images.
- cloud-platform : consultez et gérez les données, y compris les métadonnées, dans l'ensemble du service Google Cloud.
- Pour accéder à d'autres dépôts, vous devez utiliser le champ d'application cloud-platform.
Pour obtenir la liste complète des champs d'application, consultez la documentation sur gcloud container clusters create ou gcloud container node-pools create.

Pour plus d'informations sur les niveaux d'accès que vous pouvez définir lors de la création d'un cluster, reportez-vous à la documentation de la commande gcloud container clusters create.

Configurer imagePullSecret

Pour configurer un objet imagePullSecret :

Dans le projet avec GKE, recherchez le compte de service Compute Engine par défaut. L'adresse e-mail associée au compte comporte le suffixe @developer.gserviceaccount.com.
Téléchargez la clé du compte de service.
Dans le projet contenant le dépôt, vérifiez que vous avez accordé les autorisations appropriées.
Dans le projet contenant votre cluster, créez un secret imagePullSecret appelé artifact-registry avec la clé de compte de service.
```
kubectl create secret docker-registry artifact-registry \
--docker-server=https://LOCATION-docker.pkg.dev \
--docker-email=SERVICE-ACCOUNT-EMAIL \
--docker-username=_json_key \
--docker-password="$(cat KEY-FILE)"
```
Où :
- LOCATION est l'emplacement régional ou multirégional du dépôt.
- SERVICE-ACCOUNT-EMAIL est l'adresse e-mail associée au compte de service Compute Engine.
- KEY-FILE est le nom du fichier de clé de votre compte de service. Par exemple, key.json.
Ouvrez votre compte de service par défaut :
```
kubectl edit serviceaccount default --namespace default
```
Chaque espace de noms de votre cluster Kubernetes possède un compte de service par défaut appelé default. Ce compte de service par défaut est utilisé pour extraire votre image de conteneur.

Ajoutez le secret nouvellement créé imagePullSecret à votre compte de service par défaut :

imagePullSecrets:
- name: artifact-registry

Votre compte de service doit maintenant se présenter comme suit :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
  ...
secrets:
- name: default-token-zd84v
# The secret you created:
imagePullSecrets:
- name: artifact-registry

Désormais, tout pod créé dans l'espace de noms default actuel sera associé au secret imagePullSecret.

Compte de service Artifact Registry

L'agent de service Artifact Registry est un compte de service géré par Google qui agit pour le compte d'Artifact Registry lors de l'interaction avec les services Google Cloud. Pour en savoir plus sur le compte et ses autorisations, consultez la section Compte de service Artifact Registry.

Étapes suivantes

Une fois les autorisations configurées, découvrez comment utiliser vos artefacts.

Images de conteneurs: Docker et Helm
Packages de langage: Java, Node.js, Python, Go
Packages de système d'exploitation: Debian et RPM