Controllo dell'accesso con IAM

Questa pagina descrive il controllo dell'accesso con Identity and Access Management (IAM) in Artifact Registry.

Le autorizzazioni predefinite per Artifact Registry riducono al minimo le operazioni di configurazione durante l'implementazione di una pipeline CI/CD. Puoi anche integrare Artifact Registry con strumenti CI/CD di terze parti e configurare le autorizzazioni e l'autenticazione per accedere ai repository.

Se utilizzi Artifact Analysis per lavorare con i metadati del container, come le vulnerabilità trovate nelle immagini, consulta Documentazione di Artifact Analysis per informazioni sulla concessione dell'accesso per visualizzare o gestire i metadati.

Prima di iniziare

1. Abilita Artifact Registry, inclusa l'abilitazione dell'API e l'installazione di Google Cloud CLI.
2. Se vuoi applicare autorizzazioni specifiche per il repository, crea un repository Artifact Registry per i tuoi pacchetti.

Panoramica

Le autorizzazioni e i ruoli IAM determinano la tua capacità di creare, visualizzare, modificare o eliminare i dati in un repository Artifact Registry.

Un ruolo è una raccolta di autorizzazioni. Non puoi concedere le autorizzazioni a un'entità directly; concedi loro un ruolo. Quando concedi un ruolo a un'entità, concedi loro tutte le autorizzazioni contenute nel ruolo. Puoi concedere più ruoli alla stessa entità.

Autorizzazioni predefinite di Google Cloud

Per impostazione predefinita, le seguenti autorizzazioni si applicano ai servizi CI/CD di Google Cloud nello stesso progetto di Artifact Registry:

• Le autorizzazioni di Cloud Build includono le autorizzazioni per caricare e scaricare gli elementi.
• Compute Engine, le versioni supportate di Google Kubernetes Engine e Cloud Run utilizzano l'account di servizio predefinito di Compute Engine, che ha accesso di sola lettura allo spazio di archiviazione.

Se tutti i tuoi servizi si trovano nello stesso progetto Google Cloud e le autorizzazioni predefinite soddisfano le tue esigenze, non è necessario configurarle.

Devi configurare le autorizzazioni di Artifact Registry per questi servizi se:

• Vuoi utilizzare questi servizi per accedere ad Artifact Registry in un altro progetto. Nel progetto con Artifact Registry, concedi al pool di identità del carico di lavoro o all'account di servizio per ogni servizio il ruolo richiesto. Se ti connetti a Cloud Run, concedi la Agente di servizio Cloud Run il necessario ruolo.
• stai utilizzando una versione GKE che non ha per il pull delle immagini da Artifact Registry. Consulta le GKE per le istruzioni di configurazione.
• Vuoi che l'account di servizio predefinito abbia accesso in lettura e scrittura a repository. Per informazioni dettagliate, leggi le seguenti informazioni:
  • Compute Engine
  • GKE
• utilizzi un account di servizio fornito dall'utente per i tuoi ambienti di runtime anziché l'account di servizio predefinito. Nel progetto con Artifact Registry, concedi al tuo account di servizio la quantità richiesta ruolo.

Integrazione di terze parti

Per i client di terze parti, devi configurare sia le autorizzazioni sia l'autenticazione.

Tradizionalmente, le applicazioni in esecuzione al di fuori di Google Cloud utilizzano chiavi dell'account di servizio per accedere alle risorse Google Cloud. Tuttavia, le chiavi degli account di servizio credenziali molto potenti e possono comportare un rischio per la sicurezza se non vengono gestite in modo corretto.

La federazione delle identità per i carichi di lavoro ti consente di utilizzare Identity and Access Management per assegnare ruoli IAM alle identità esterne, inclusa la possibilità di rubare l'identità degli account di servizio. Questo approccio elimina il carico di manutenzione e sicurezza associato alle chiavi dell'account di servizio.

Utilizza la federazione delle identità per i carichi di lavoro:

1. Crea un pool federazione di Workload Identity.
2. Crea un provider di federazione delle identità per i carichi di lavoro.
3. Concedi il ruolo Artifact Registry appropriato al pool di identità del carico di lavoro per consentire l'accesso al repository.

4. Configura il client di terze parti per l'autenticazione con Artifact Registry.

   • Immagini container: Docker, Helm
   • Pacchetti di lingua: Java, Node.js, Python, Go
   • Pacchetti del sistema operativo: Debian, RPM
   • Altro: Modelli di pipeline Kubeflow

Utilizza un account di servizio:

1. Creare un servizio di agire per conto della tua applicazione o di scegliere un servizio esistente per l'automazione CI/CD.
2. Concedi il ruolo Artifact Registry appropriato all'account di servizio per fornire l'accesso al repository.

3. Configura il client di terze parti per l'autenticazione con Artifact Registry.

   • Immagini container: Docker, Helm
   • Pacchetti di lingua: Java, Node.js, Python, Go
   • Pacchetti del sistema operativo: Debian, RPM
   • Altro: Modelli di pipeline Kubeflow

GitLab su Google Cloud

L'integrazione di GitLab su Google Cloud utilizza Federazione delle identità per i carichi di lavoro per l'autorizzazione e l'autenticazione per per i carichi di lavoro GitLab su Google Cloud senza la necessità di account di servizio e gestire le chiavi account di servizioo. Per ulteriori informazioni su come viene utilizzata la federazione delle identità per i carichi di lavoro in questa partnership, consulta la Panoramica dell'autenticazione.

Per configurare la federazione delle identità per i carichi di lavoro e i requisiti Ruoli IAM per GitLab su Google Cloud: guarda il tutorial di GitLab Federazione di Google Cloud Workload Identity e criteri IAM.

Per connettere il tuo repository Artifact Registry, segui il tutorial GitLab Google Artifact Registry.

Ruoli e autorizzazioni

Ogni metodo dell'API Artifact Registry richiede che l'entità (utente, gruppo o account di servizio) che effettua la richiesta disponga delle autorizzazioni necessarie per la risorsa. Le autorizzazioni vengono assegnate alle entità impostando criteri che grantino all'entità un ruolo predefinito nella risorsa.

Puoi concedere i ruoli nel progetto Google Cloud o nel repository Artifact Registry.

Ruoli predefiniti di Artifact Registry

IAM fornisce ruoli predefiniti che consentono l'accesso a risorse Google Cloud specifiche e impediscono l'accesso non autorizzato ad altre risorse.

Utilizza i seguenti ruoli predefiniti per standard, virtuali e remoti repository sul dominio pkg.dev:

I seguenti ruoli predefiniti aggiuntivi includono le autorizzazioni per creare repository gcr.io per ospitare le immagini per il dominio gcr.io. I ruoli non includono le autorizzazioni per creare altri formati di repository in Artifact Registry nel dominio pkg.dev. Questi ruoli supportano la compatibilità con le versioni precedenti di Container Registry, poiché Container Registry utilizza il primo push di un'immagine contenitore per creare ogni registry multiregionale.

Per un elenco completo delle singole autorizzazioni in ogni ruolo, consulta Ruoli del Registry di elementi. Puoi anche utilizzare il comando gcloud iam roles describe per visualizzare un elenco delle autorizzazioni in ogni ruolo.

Ruoli IAM di base

I ruoli di base sono ruoli altamente permissivi esistenti prima dell'introduzione di IAM. Puoi utilizzare i ruoli di base per concedere ai principali accesso ampio alle risorse Google Cloud.

Usa i ruoli predefiniti per il repository quando possibile, in modo che gli utenti e gli account di servizio abbiano le autorizzazioni necessarie.

Per ulteriori informazioni sui ruoli di base, vedi Riferimento per i ruoli IAM di base e predefiniti.

Concessione di autorizzazioni

Concedi le autorizzazioni a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository del progetto. Se alcuni account richiedono livelli diversi di e concedere ruoli a livello di repository.

Se concedi le autorizzazioni su un repository virtuale, le autorizzazioni si applicano a tutti i repository upstream disponibili tramite a prescindere dalle autorizzazioni del singolo repository.

Se concedi i ruoli utilizzando il comando gcloud, puoi specificare una singola associazione di ruolo per un'entità o utilizza un file di criteri per definire più associazioni.

Concessione di autorizzazioni a livello di progetto

Assegna un ruolo a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente nel progetto.

Per aggiungere un utente o un account di servizio a un progetto e concedergli un ruolo del Registry degli elementi:

Concessione di autorizzazioni specifiche del repository

Concedi autorizzazioni a livello di repository quando vuoi che gli utenti o gli account di servizio abbiano diversi livelli di accesso per ogni repository del progetto.

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

Configurare l'accesso pubblico a un repository

Se hai elementi che vuoi rendere disponibili a chiunque su internet senza autenticazione, archiviali in un repository che rendi pubblico.

Per configurare un repository per l'accesso pubblico di sola lettura, concedi il ruolo Lettore del registry di elementi all'entità allUsers. Ti consigliamo inoltre limitare le quote per le richieste degli utenti, in modo che L'utente non può esaurire la quota complessiva del progetto.

Revocare le autorizzazioni

Per revocare l'accesso a un repository, rimuovi l'entità dall'elenco delle entità autorizzate tra cui scegliere.

Per rimuovere l'accesso pubblico da un repository, rimuovi l'entità allUsers.

Concedere l'accesso condizionale con i tag

Gli amministratori di progetto possono creare tag per le risorse in Google Cloud e gestirli in Resource Manager. Quando colleghi un tag a un repository Artifact Registry, gli amministratori possono utilizzarlo con le condizioni IAM per concedere l'accesso condizionale al repository.

Non puoi associare tag a singoli elementi.

Per ulteriori informazioni, consulta la seguente documentazione:

• Amministratori che configurano tag e controllo dell'accesso
  • Creare e gestire i tag
  • Tag e controllo dell'accesso.
• Sviluppatori che aggiungono tag ai repository
  • Tagging dei repository

Integrazione con i servizi Google Cloud

Per la maggior parte degli account di servizio Google Cloud, la configurazione dell'accesso a un registry richiede solo la concessione delle autorizzazioni IAM appropriate.

Autorizzazioni predefinite per i servizi Google Cloud

I servizi Google Cloud come Cloud Build o Google Kubernetes Engine utilizzano account di servizio predefinito oppure un agente di servizio usato per interagire all'interno dello stesso progetto.

Devi configurare o modificare le autorizzazioni autonomamente se:

• Il servizio Google Cloud si trova in un progetto diverso da Artifact Registry.
• Le autorizzazioni predefinite non soddisfano le tue esigenze. Ad esempio, l'account di servizio Compute Engine predefinito ha accesso di sola lettura allo spazio di archiviazione nello stesso progetto. Se vuoi eseguire il push di un'immagine da una VM ad Artifact Registry, puoi modificare le autorizzazioni per l'account di servizio della VM o utilizzare un account diverso con le autorizzazioni richieste.
• utilizzi un account di servizio fornito dall'utente per interagire Artifact Registry anziché l'account di servizio predefinito.

In genere, i seguenti account di servizio accedono ad Artifact Registry. L'ID o il numero del progetto Google Cloud del progetto in cui è in esecuzione il servizio.

Concessione dell'accesso alle istanze di Compute Engine

Le istanze VM che accedono ai repository devono avere sia Artifact Registry autorizzazioni e ambito di accesso dello spazio di archiviazione configurati.

Mentre il livello di accesso di un account di servizio è determinato Ruoli IAM concessi all'account di servizio, accesso agli ambiti su un'istanza VM determina gli ambiti OAuth predefiniti per le richieste effettuate gcloud CLI e le librerie client sull'istanza. Di conseguenza, gli ambiti di accesso possono limitare ulteriormente l'accesso ai metodi dell'API durante l'autenticazione con le credenziali predefinite dell'applicazione.

Compute Engine utilizza i seguenti valori predefiniti:

• L'account di servizio predefinito di Compute Engine è l'identità per la VM. di Compute Engine. L'indirizzo email dell'account di servizio ha il suffisso @developer.gserviceaccount.com.
• L'account di servizio predefinito ha la configurazione IAM di base Ruolo Editor, se non hai disattivato questo comportamento.
• Le istanze che crei con l'account di servizio predefinito hanno Gli ambiti di accesso predefiniti di Compute Engine, inclusi accesso di sola lettura allo spazio di archiviazione. Sebbene il ruolo Editor in genere conceda accesso allo spazio di archiviazione, l'ambito di accesso allo spazio di archiviazione read-only limita il servizio delle istanze per scaricare gli artefatti solo da qualsiasi repository nello stesso progetto.

Devi configurare l'ambito di accesso dell'account di servizio se:

• L'account di servizio della VM deve accedere a un repository in un progetto diverso.
• L'account di servizio della VM deve eseguire azioni diverse dalla lettura degli artefatti dai repository. In genere questo applica strumenti di terze parti su una VM che per eseguire il push delle immagini o eseguire i comandi gcloud di Artifact Registry.

Per configurare le autorizzazioni e impostare l'ambito di accesso:

1. Nel progetto con la tua istanza VM, trova il nome del Account di servizio predefinito Compute Engine. L'indirizzo email dell'account di servizio ha il suffisso @developer.gserviceaccount.com.

2. Nel progetto con il repository, concedi le autorizzazioni in modo che l'account di servizio possa accedere al repository.

3. Imposta l'ambito di accesso con l'opzione --scopes.

   1. Arresta l'istanza VM. Consulta: Arresto di un'istanza.

   2. Imposta l'ambito di accesso con il seguente comando:

      gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
      

      Sostituisci SCOPE con il valore appropriato.

      • Per Docker sono supportate le seguenti opzioni:

        • storage-ro: concede l'autorizzazione di lettura solo per il pull delle immagini.
        • storage-rw - Concede l'autorizzazione di lettura e scrittura per il push o estrarre immagini.
        • cloud-platform: visualizza e gestisci i dati, inclusi i metadati, su dal servizio Google Cloud.

      • Per altri formati, devi utilizzare l'ambito cloud-platform.

   3. Riavvia l'istanza VM. Consulta Avvio di un'istanza interrotta.

Concedere l'accesso ai cluster Google Kubernetes Engine

I cluster GKE e i pool di nodi possono eseguire il pull dei container senza configurazione aggiuntiva se sono soddisfatti tutti i seguenti requisiti:

• GKE si trova nello stesso progetto di Artifact Registry
• I nodi utilizzano l'account di servizio predefinito, ovvero l'account di servizio predefinito di Compute Engine
• I nodi sono stati creati con accesso in lettura allo spazio di archiviazione da:
  • Utilizzo degli ambiti di accesso predefiniti di Compute Engine.
  • Concedi l'ambito di accesso cloud-platform o un altro ambito che includa accesso in lettura allo spazio di archiviazione.
• stai utilizzando una versione supportata di GKE

Se il tuo ambiente GKE non soddisfa questi requisiti, le istruzioni per concedere l'accesso dipendono dal fatto che tu stia utilizzando il service account predefinito di Compute Engine o un service account fornito dall'utente come identità per i tuoi nodi.

Service account predefinito

I seguenti requisiti di configurazione si applicano Account di servizio predefinito Compute Engine:

1. Se GKE si trova in un progetto diverso da Artifact Registry, concedi le autorizzazioni richieste l'account di servizio.

2. Per eseguire il push delle immagini, interagisci con i repository per formati diversi da container o eseguire comandi gcloud dal cluster, devi impostare ambiti di accesso per l'account di servizio quando crei cluster o pool di nodi.

3. Se non usi una versione supportata di GKE, configura imagePullSecrets.

Account di servizio fornito dall'utente

Se vuoi utilizzare un account di servizio fornito dall'utente come identità per un cluster, devi:

1. Concedi all'account di servizio le autorizzazioni richieste dalla Progetto Google Cloud in cui è in esecuzione Artifact Registry.

2. Per impostazione predefinita, la creazione di un cluster o di un pool di nodi con un servizio fornito dall'utente l'account concede l'ambito di accesso cloud-platform.

   Se utilizzi il flag --scopes con il comando gcloud container clusters create o gcloud container node-pools create, devi includere gli ambiti di accesso appropriati per l'utilizzo con Artifact Registry.

Impostazione degli ambiti di accesso

Gli ambiti di accesso sono il metodo legacy per specificare l'autorizzazione per le VM Compute Engine. Per estrarre le immagini dai repository di Artifact Registry, i nodi GKE devono avere l'ambito di accesso di sola lettura allo spazio di archiviazione o un altro ambito di accesso allo spazio di archiviazione che includa l'accesso in lettura allo spazio di archiviazione.

Puoi impostare gli ambiti di accesso solo quando crei un cluster o un pool di nodi. Tu non possono modificare gli ambiti di accesso sui nodi esistenti.

• Se utilizzi l'account di servizio predefinito di Compute Engine, GKE crea i nodi con gli ambiti di accesso predefiniti di Compute Engine, che includono l'accesso di sola lettura allo spazio di archiviazione.
• Se utilizzi un account di servizio fornito dall'utente, GKE crea i nodi con l'ambito cloud-platform, l'ambito richiesto per la maggior parte dei servizi Google Cloud.

Per specificare gli ambiti di accesso durante la creazione di un cluster, esegui questo comando:

gcloud container clusters create NAME --scopes=SCOPES

Per specificare gli ambiti di accesso durante la creazione di un pool di nodi, esegui il seguente comando:

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

Sostituisci i seguenti valori:

• NAME è il nome del cluster o del pool di nodi.

• SCOPES è un elenco separato da virgole di ambiti di accesso da concedere.

  • Per accedere ai repository Docker, utilizza uno dei seguenti ambiti:

  • storage-ro - Concede l'autorizzazione di sola lettura per il pull delle immagini.

  • storage-rw - Concede l'autorizzazione di lettura e scrittura per il push o estrarre immagini.

  • cloud-platform: visualizza e gestisci i dati, inclusi i metadati, nel servizio Google Cloud.

  • Per accedere ad altri repository, devi utilizzare l'ambito cloud-platform.

  Per un elenco completo degli ambiti, consulta la documentazione gcloud container clusters create o gcloud container node-pools create.

Per saperne di più sugli ambiti che puoi impostare quando crei un nuovo cluster, consulta la documentazione per il comando gcloud container clusters create.

Configurazione di un'immaginePullSecret

Per configurare un imagePullSecret:

1. Nel progetto con GKE, trova Compute Engine predefinito l'account di servizio. L'indirizzo email dell'account ha il suffisso @developer.gserviceaccount.com

2. Scarica la chiave dell'account di servizio per l'account di servizio.

3. Nel progetto con il repository, verifica di aver conseguito le autorizzazioni per il repository.

4. Nel progetto con il cluster, crea un secret imagePullSecret chiamato artifact-registry con la chiave dell'account di servizio.

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

   Dove

   • LOCATION è la posizione regionale o multiregionale del repository.
   • SERVICE-ACCOUNT-EMAIL è l'indirizzo email del Account di servizio Compute Engine.
   • KEY-FILE è il nome del file della chiave dell'account di servizio. Ad esempio key.json.

5. Apri l'account di servizio predefinito:

   kubectl edit serviceaccount default --namespace default

   Ogni spazio dei nomi nel cluster Kubernetes ha un account di servizio predefinito denominato default. Questo account di servizio predefinito viene utilizzato per eseguire il pull dell'immagine container.

6. Aggiungi il secret imagePullSecret appena creato al servizio predefinito :

   imagePullSecrets:
   - name: artifact-registry
   

   Il tuo account di servizio dovrebbe avere il seguente aspetto:

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

Ora, tutti i nuovi pod creati nell'attuale spazio dei nomi default avranno il segreto imagePullSecret definito.

Account di servizio Artifact Registry

L'agente di servizio Artifact Registry è un account di servizio gestito da Google che agisce per conto di Artifact Registry quando interagisce con i servizi Google Cloud. Per ulteriori informazioni sull'account e sulle relative autorizzazioni, consulta Account di servizio Artifact Registry.

Passaggi successivi

Dopo aver configurato le autorizzazioni, scopri di più sull'utilizzo degli elementi.

• Immagini container: Docker, Helm
• Pacchetti di linguaggi: Java, Node.js, Python, Go
• Pacchetti del sistema operativo: Debian, RPM