Contrôle des accès avec IAM

Utilisez Identity and Access Management (IAM) pour attribuer des rôles et contrôler qui peut accéder aux données et les gérer dans Artifact Registry. Artifact Registry contient des rôles prédéfinis qui peuvent vous aider à simplifier la configuration du pipeline CI/CD. Si vous avez besoin d'un contrôle des accès supplémentaire ou si vous intégrez Artifact Registry à un outil tiers, vous pouvez également configurer des rôles personnalisés.

Avant de commencer

1. Activez Artifact Registry, y compris l'API et Google Cloud CLI.
2. Si vous souhaitez appliquer des autorisations spécifiques à un dépôt, créez un dépôt Artifact Registry pour vos packages.

Présentation

Les autorisations et les rôles IAM déterminent votre capacité à créer, afficher, modifier ou supprimer des données dans un dépôt Artifact Registry.

Un rôle est un ensemble d'autorisations. Vous ne pouvez pas accorder directement une autorisation principale. À la place, vous lui accordez un rôle. Lorsque vous accordez un rôle à un compte principal, vous lui accordez toutes les autorisations associées à ce rôle. Vous pouvez attribuer plusieurs rôles au même compte principal.

Cloud de Confiance  autorisations par défaut

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

• Compute Engine et les versions compatibles de Google Kubernetes Engine utilisent le compte de service Compute Engine par défaut, qui dispose d'un accès en lecture seule au stockage.

Si tous vos services se trouvent dans le même projet Cloud de Confiance by S3NS et que les autorisations par défaut répondent à vos besoins, vous n'avez pas besoin de configurer les 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, attribuez le rôle requis au pool d'identités de charge de travail ou au compte de service pour chaque service.

• Vous utilisez une version de GKE qui n'est pas compatible avec l'extraction d'images depuis Artifact Registry. Pour obtenir des instructions de configuration, consultez la section GKE.
• 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 au lieu du compte de service par défaut. Dans le projet avec Artifact Registry, attribuez le rôle requis à votre compte de service.

Intégration tierce

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

Traditionnellement, les applications exécutées en dehors de Cloud de Confiance utilisent des clés de compte de service pour accéder aux ressources Cloud de Confiance . Toutefois, les clés de compte de service sont des identifiants puissants. Si elles ne sont pas gérées correctement, elles peuvent présenter un risque de sécurité.

La fédération d'identité de charge de travail vous permet d'utiliser Identity and Access Management pour accorder des rôles IAM à des identités externes, et leur permettre d'emprunter l'identité de comptes de service. Cette approche élimine les tâches de maintenance et de sécurité associées aux clés de compte de service.

Utiliser la fédération d'identité de charge de travail :

1. Créez un pool de fédération d'identité de charge de travail.
2. Créer un fournisseur de fédération d'identité de charge de travail
3. Accordez le rôle Artifact Registry approprié au pool d'identités de charge de travail pour autoriser l'accès au dépôt. Pour en savoir plus, consultez Autoriser votre charge de travail externe à accéder aux ressources Cloud de Confiance by S3NS .
4. Si vous devez accéder à Artifact Registry pendant de plus longues périodes, configurez le délai d'expiration du jeton OIDC sur une période plus longue dans votre configuration des identifiants.

5. Configurez votre client tiers pour qu'il s'authentifie auprès d'Artifact Registry.

   • Images de conteneur: Docker, Helm
   • Packages de l'OS: Debian, RPM

Utiliser un compte de service :

1. 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.
2. Accordez le rôle Artifact Registry approprié au compte de service afin de fournir l'accès au dépôt.

3. Configurez votre client tiers pour qu'il s'authentifie auprès d'Artifact Registry.

   • Images de conteneur: Docker, Helm
   • Packages de l'OS: Debian, RPM

Rôles et autorisations

Chaque méthode de l'API Artifact Registry nécessite que le principal effectuant la requête dispose des autorisations requises pour utiliser la ressource. Les autorisations sont accordées aux comptes principaux en définissant des stratégies qui leur attribuent un rôle prédéfini sur la ressource.

Vous pouvez attribuer des rôles sur le projet Cloud de Confiance by S3NS ou le dépôt Artifact Registry.

Rôles Artifact Registry prédéfinis

IAM fournit des rôles prédéfinis qui accordent l'accès à des ressources Cloud de Confiance spécifiques.

Rôles IAM de base

Les rôles de base sont des rôles très permissifs qui existaient avant la mise en place d'IAM. Les rôles de base ne doivent pas être attribués dans un environnement de production, mais ils peuvent être attribués dans un environnement de développement ou de test.

Dans la mesure du possible, utilisez des rôles prédéfinis pour l'accès au dépôt afin que les utilisateurs et les comptes de service ne disposent que des autorisations requises.

Pour en savoir plus sur les rôles de base, consultez la documentation de référence sur les rôles IAM de base et prédéfinis.

Attribution des rôles…

Attribuez des rôles au niveau du projet si les mêmes rôles 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 seule liaison de rôle pour un compte principal ou apporter des modifications à grande échelle aux stratégies en obtenant la stratégie d'autorisation d'une ressource, en la modifiant, puis en définissant la stratégie d'autorisation modifiée. Pour en savoir plus, consultez Attribuer ou révoquer plusieurs rôles de manière programmatique.

Attribuer des rôles à 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 utilisateur ou un compte de service à un projet et lui attribuer un rôle Artifact Registry :

Accorder des rôles spécifiques au dépôt

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

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}"
}

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

Si vous avez des artefacts que vous souhaitez rendre accessibles à tous sur Internet sans authentification, stockez-les dans un dépôt que vous rendez public.

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

Révocation des rôles…

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 à un dépôt, supprimez le compte principal allUsers.

Accorder un accès conditionnel avec des tags

Les administrateurs de projet peuvent créer des tags pour les ressources dans Cloud de Confianceet 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 le contrôle des accès
  • Créer et gérer des tags
  • Tags et contrôle d'accès.
• Développeurs associant des tags à des dépôts
  • Ajouter des tags aux dépôts

Intégration aux services Cloud de Confiance

Pour la plupart des comptes de service Cloud de Confiance , la configuration de l'accès à un registre ne nécessite que l'attribution des rôles IAM appropriés.

Comptes de service par défaut pour les services Cloud de Confiance by S3NS

Les servicesCloud de Confiance , tels que Google Kubernetes Engine, utilisent un compte de service par défaut ou un agent de service 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 Cloud de Confiance by S3NS se trouve dans un projet différent d'Artifact Registry.
• Les autorisations par défaut ne répondent pas à vos besoins.
• Vous utilisez un compte de service fourni par l'utilisateur pour interagir avec Artifact Registry au lieu du compte de service par défaut.
• La configuration de vos règles d'administration empêche l'attribution automatique de rôles aux comptes 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 du projet ou le numéro du projet Cloud de Confiancedans lequel le service est exécuté.

Selon la configuration de vos règles d'administration, le compte de service par défaut peut se voir attribuer automatiquement le rôle Éditeur sur votre projet. Nous vous recommandons vivement de désactiver l'attribution automatique des rôles en appliquant la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts. Si vous avez créé votre organisation après le 3 mai 2024, cette contrainte est appliquée par défaut.

Si vous désactivez l'attribution automatique de rôles, vous devez choisir les rôles à attribuer aux comptes de service par défaut, puis attribuer ces rôles vous-même.

Si le compte de service par défaut dispose déjà du rôle Éditeur, nous vous recommandons de le remplacer par des rôles moins permissifs.

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 niveaux d'accès d'une instance de VM déterminent les champs d'application OAuth par défaut pour les requêtes effectuées via 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 API lors de l'authentification avec les 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 comporte le suffixe @developer.s3ns-system.iam.gserviceaccount.com.
• Le compte de service par défaut dispose du rôle IAM de base É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 niveaux d'accès par défaut de Compute Engine, y compris l'accès en lecture seule au 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 la VM doit accéder à un dépôt dans un autre projet.
• Le compte de service de la VM doit effectuer des actions autres que la lecture des artefacts à partir des dépôts. Cela s'applique généralement aux outils tiers sur une VM qui doivent transférer des images ou exécuter des commandes Artifact Registry gcloud.

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

1. Dans le projet contenant votre instance de VM, obtenez le nom du compte de service Compute Engine par défaut. L'adresse e-mail du compte de service comporte le suffixe @developer.s3ns-system.iam.gserviceaccount.com.

2. Dans le projet contenant le dépôt, accordez des autorisations pour que le compte de service puisse accéder au dépôt.

3. 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 une autorisation de lecture uniquement pour extraire des images.
        • storage-rw : accorde l'autorisation de lecture et d'écriture pour envoyer ou extraire des images.
        • cloud-platform : permet d'afficher et de gérer les données, y compris les métadonnées, dans le serviceCloud de Confiance .

      • 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 aucune configuration supplémentaire si toutes les exigences 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 au stockage par :
  • Utilisez les niveaux d'accès par défaut de Compute Engine.
  • Accorder le niveau d'accès cloud-platform ou un autre niveau d'accès incluant l'accès en lecture au 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 dépendent de l'identité de vos nœuds (compte de service Compute Engine par défaut ou compte de service fourni par l'utilisateur).

Compte de service par défaut

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

1. Si GKE se trouve dans un projet différent d'Artifact Registry, accordez les autorisations requises au compte de service.

2. Pour transférer des images, interagir avec des dépôts pour des formats autres que les 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.

3. 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 :

1. Accordez les autorisations requises au compte de service à partir du projetCloud de Confiance dans lequel Artifact Registry est exécuté.

2. 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 cloud-platform.

   Si vous utilisez l'indicateur --scopes avec la commande gcloud container clusters create ou gcloud container node-pools create, vous devez inclure les scopes d'accès appropriés pour une utilisation avec Artifact Registry.

Définir des niveaux d'accès

Les niveaux d'accès représentent l'ancienne méthode de spécification des autorisations associées aux VM Compute Engine. Pour extraire des images à partir de dépôts Artifact Registry, les nœuds GKE doivent disposer du niveau d'accès en lecture seule au stockage ou d'un autre niveau d'accès au stockage incluant l'accès en lecture au stockage.

Vous ne pouvez définir des niveaux 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, qui incluent un accès en lecture seule au 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, qui est requis pour la plupart des servicesCloud de Confiance .

Pour spécifier des niveaux 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 des niveaux 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 niveaux d'accès à accorder, 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 l'autorisation d'extraire des images en lecture seule.

  • storage-rw : accorde l'autorisation de lecture et d'écriture pour envoyer ou extraire des images.

  • cloud-platform : permet d'afficher et de gérer les données, y compris les métadonnées, dans le serviceCloud de Confiance .

  • Pour accéder à d'autres dépôts, vous devez utiliser le champ d'application cloud-platform.

  Pour obtenir la liste complète des niveaux d'accès, consultez la documentation de gcloud container clusters create ou gcloud container node-pools create.

Pour en savoir plus sur les niveaux d'accès que vous pouvez définir lorsque vous créez un cluster, consultez la documentation de la commande gcloud container clusters create.

Configurer un imagePullSecret

Pour configurer un objet imagePullSecret :

1. Dans le projet avec GKE, recherchez le compte de service Compute Engine par défaut. L'adresse e-mail du compte comporte le suffixe @developer.s3ns-system.iam.gserviceaccount.com.

2. Téléchargez la clé du compte de service pour le compte de service.

3. Dans le projet contenant le dépôt, vérifiez que vous avez accordé les autorisations appropriées.

4. 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.s3nsregistry.fr \
   --docker-email=SERVICE-ACCOUNT-EMAIL \
   --docker-username=_json_key \
   --docker-password="$(cat KEY-FILE)"
   

   Remplacez les éléments suivants :

   • LOCATION est l'emplacement régional du dépôt.
   • SERVICE-ACCOUNT-EMAIL correspond à l'adresse e-mail du compte de service Compute Engine.
   • KEY-FILE est le nom du fichier de clé de votre compte de service. Par exemple, `key.json`.

5. 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.

6. 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.

Agent de service Artifact Registry

L'agent de service Artifact Registry est un compte de service géré par Google qui agit au nom d'Artifact Registry lors de l'interaction avec les services Cloud de Confiance by S3NS. Pour en savoir plus sur le compte et ses autorisations, consultez Agent de service Artifact Registry.

Étapes suivantes

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

• Images de conteneur: Docker, Helm
• Packages de l'OS: Debian, RPM