Controllo dell'accesso con IAM

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

Le autorizzazioni predefinite per Artifact Registry riducono al minimo lo sforzo di configurazione durante l'implementazione di una pipeline CI/CD. È inoltre possibile integrare Artifact Registry con strumenti CI/CD di terze parti e configurare le autorizzazioni e l'autenticazione necessarie per accedere ai repository.

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 dati in un repository Artifact Registry.

Un ruolo è una raccolta di autorizzazioni. Non puoi concedere autorizzazioni a un'entità direttamente, ma devi assegnarle un ruolo. Se concedi un ruolo a un'entità, le concedi tutte le autorizzazioni incluse nel ruolo. È possibile assegnare più ruoli allo stesso utente.

Google Cloud autorizzazioni predefinite

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

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

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 il ruolo richiesto al pool di identità dei carichi di lavoro o all'account di servizio per ogni servizio.
  • Stai utilizzando una versione di GKE che non supporta il pull delle immagini da Artifact Registry. Consulta la sezione GKE per le istruzioni di configurazione.
  • Si desidera che il account di servizio predefinito abbia accesso in lettura e scrittura ai repository. Per maggiori dettagli, consultare le seguenti informazioni:
  • Stai utilizzando 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 account di servizio il ruolo richiesto.

Integrazione di terze parti

Per i client di terze parti, è necessario configurare sia le autorizzazioni che l'autenticazione.

Tradizionalmente, le applicazioni in esecuzione all'esterno Google Cloud utilizzochiavi dell'account di servizio per accedere Google Cloud risorse. Tuttavia, le chiavi dei account di servizio sono credenziali potenti e possono rappresentare un rischio per la sicurezza se non vengono gestite correttamente.

La federazione delle identità per i workload ti consente di utilizzare Identity and Access Management per concedere alle identità esterne ruoli IAM, inclusa la possibilità di assumere l'identità di service account. Questo approccio elimina gli oneri di manutenzione e sicurezza associati alle chiavi degli account di servizio.

Utilizzare la federazione delle identità per i workload:

  1. Crea un pool di federazione delle identità per i workload.
  2. Crea un provider di federazione delle identità per i workload.
  3. Concedi il ruolo appropriato Artifact Registry al pool di identità del carico di lavoro per consentire l'accesso al repository. Per ulteriori informazioni, vedere Consenti al tuo carico di lavoro esterno di accedere a Google Cloud risorse.
  4. Se devi accedere ad Artifact Registry per periodi di tempo più lunghi, configura la scadenza del token OIDC per un periodo più lungo nella configurazione delle credenziali.

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

Utilizza un service account:

  1. Crea un account di servizio che agisca per conto della tua applicazione oppure scegli un account di servizio esistente da utilizzare per l'automazione CI/CD.
  2. Concedi il ruolo appropriato di Artifact Registry all'account di servizio per fornire l'accesso al repository.

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

Ruoli e autorizzazioni

Ogni metodo dell'API Artifact Registry richiede che il principal che effettua la richiesta abbia le autorizzazioni necessarie per utilizzare la risorsa. Le autorizzazioni vengono concesse alle entità impostando criteri che concedono all'entità un ruolo predefinito sulla risorsa.

È possibile assegnare ruoli sul progetto Google Cloud o sul repository Artifact Registry.

Ruoli predefiniti di Artifact Registry

IAM fornisce ruoli predefiniti che concedono l'accesso a risorse Google Cloud specifiche.

Utilizza i seguenti ruoli predefiniti per i repository:
Ruolo Descrizione
Lettore Artifact Registry
(roles/artifactregistry.reader)		 Visualizza e recupera artefatti, visualizza i metadati del repository.
Scrittore di Artifact Registry
(roles/artifactregistry.writer)		 Leggere e scrivere artefatti.
Amministratore repository Artifact Registry
(roles/artifactregistry.repoAdmin)		 Leggere, scrivere ed eliminare artefatti.
Amministratore di Artifact Registry
(roles/artifactregistry.admin)		 Crea e gestisci repository e artefatti.
Per un elenco completo delle singole autorizzazioni in ciascun ruolo, fare riferimento a Ruoli di Artifact Registry. 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. Non dovresti assegnare ruoli di base in un ambiente di produzione, ma puoi farlo in un ambiente di sviluppo o di test.

Utilizza i ruoli predefiniti per l'accesso al repository ogni volta che è possibile, in modo che utenti e service account dispongano solo delle autorizzazioni necessarie.

Per saperne di più sui ruoli di base, consulta il riferimento ai ruoli di base e predefiniti di IAM.

Concessione dei ruoli in corso…

Concedi i ruoli a livello di progetto se gli stessi ruoli si applicano a tutti i repository del progetto. Se alcuni account richiedono livelli di accesso diversi, concedi ruoli a livello di repository.

Se concedi ruoli utilizzando il comando gcloud, puoi specificare un singolo binding del ruolo per un principal oppure puoi apportare modifiche alle policy su larga scala recuperando la policy di autorizzazione di una risorsa, modificandola e poi impostando la policy di autorizzazione modificata. Per ulteriori informazioni, vedi Concedere o revocare più ruoli a livello di programmazione.

Concessione di ruoli a livello di progetto

Concedi un ruolo a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository del progetto.

Per aggiungere un utente o un account di servizio a un progetto e concedergli un ruolo Artifact Registry:

Console

  1. Apri la pagina IAM nella console Google Cloud .

    Apri la pagina IAM

  2. Fai clic su Seleziona un progetto, scegli il progetto in cui è in esecuzione Artifact Registry e fai clic su Apri.

  3. Fai clic su Aggiungi.

  4. Inserisci un indirizzo email. Puoi aggiungere privati, service account o gruppi Google come entità.

  5. Seleziona un ruolo per l'entità. In conformità al principio di sicurezza del privilegio minimo, valuta la possibilità di concedere il minor numero di privilegi necessario per accedere alle risorse Artifact Registry richieste. Per informazioni su ruoli e autorizzazioni predefiniti di Artifact Registry, consulta Ruoli predefiniti di Artifact Registry.

  6. Fai clic su Salva.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per concedere un ruolo a un singolo principal, esegui questo comando:

    gcloud projects add-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE

    dove

    • PROJECT è l'ID del progetto in cui è in esecuzione Artifact Registry.

    • PRINCIPAL è l'entità per la quale aggiungere l'associazione. Utilizza il modulo user|group|serviceAccount:email o domain:domain.

      Esempi: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com o domain:example.domain.com.

    • ROLE è il ruolo che vuoi concedere.

    Per ulteriori informazioni, consultare la documentazione add-iam-policy-binding.

    Per assegnare ruoli tramite un file di policy, vedere Assegnare o revocare più ruoli a livello di programmazione

Concessione di ruoli specifici per il repository

Assegna ruoli a livello di repository quando vuoi che utenti o service account abbiano livelli di accesso diversi per ogni repository del tuo progetto.

Console

Per concedere l'accesso a un repository specifico:

  1. Apri la pagina Repository nella console Google Cloud .

    Apri la pagina Repositori

  2. Seleziona il repository appropriato.

  3. Se il riquadro informazioni non è visualizzato, fai clic su Mostra riquadro informazioni nella barra dei menu.

  4. Nella scheda Autorizzazioni, fai clic su Aggiungi entità.

  5. Inserisci un indirizzo email. È possibile aggiungere come entità principali singoli utenti, account di servizio o gruppi Google.

  6. Seleziona un ruolo per l'entità. In conformità al principio di sicurezza del privilegio minimo, valuta la possibilità di concedere il minor numero di privilegi necessario per accedere alle risorse Artifact Registry richieste. Per informazioni su ruoli e autorizzazioni predefiniti di Artifact Registry, consulta Ruoli predefiniti di Artifact Registry.

  7. Fai clic su Salva.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Puoi impostare un insieme IAM di singole associazioni di policy o utilizzare un file di policy.

    Per concedere un ruolo a un singolo principal, esegui questo comando:

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE

    dove

    • REPOSITORY è l'ID del repository.

    • PRINCIPAL è l'entità per la quale aggiungere l'associazione. Utilizza il modulo user|group|serviceAccount:email o domain:domain.

      Esempi: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com o domain:example.domain.com.

    • ROLE è il ruolo che vuoi concedere.

    • LOCATION è la posizione regionale del repository.

    Ad esempio, per aggiungere un'associazione di policy IAM per il ruolo roles/artifactregistry.writer per l'utente write@gmail.com con il repository my-repo nella località --, esegui:

    gcloud artifacts repositories add-iam-policy-binding my-repo \
--location= --member=user:write@gmail.com --role=roles/artifactregistry.writer

    Per concedere ruoli utilizzando un file di policy, utilizza la procedura descritta in Concedere o revocare più ruoli a livello di programmazione con i comandi gcloud artifacts repositories get-iam-policy e gcloud artifacts repositories set-iam-policy.

Terraform

Utilizza la risorsa google_artifact_registry_repository_iam per configurare una policy IAM. L'esempio seguente definisce un service account con il nome risorsa repo-account e gli concede l'accesso in lettura a un repository con il nome risorsa my-repo.

Se non hai mai utilizzato Terraform per Google Cloud, consulta la pagina Inizia a utilizzare - Google Cloud sul sito web di 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 è l'ID dell'account di servizio. Questa è la parte del campo email dell'account di servizio prima del simbolo @.

Per altri esempi, consulta la documentazione della risorsa google_artifact_registry_repository_iam.

Configurazione dell'accesso pubblico a un repository

Se hai artefatti 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 Artifact Registry all'entità allUsers. Ti consigliamo inoltre di limitare le quote delle richieste degli utenti in modo che un singolo utente non possa esaurire la quota complessiva del tuo progetto.

Console

  1. Apri la pagina Repository nella console Google Cloud .

    Apri la pagina Repositori

  2. Seleziona il repository appropriato.

  3. Se il riquadro informazioni non è visualizzato, fai clic su Mostra riquadro informazioni nella barra dei menu.

  4. Nella scheda Autorizzazioni, fai clic su Aggiungi entità.

  5. Nel campo Nuove entità, inserisci allUsers.

  6. Seleziona il ruolo Lettore Artifact Registry.

  7. Imposta un limite per utente per le richieste API Artifact Registry per impedire l'utilizzo improprio da parte di utenti non autenticati. Per istruzioni, vedi Limitare l'utilizzo.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Esegui questo comando:

    gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location=LOCATION --member=allUsers --role=ROLE

    dove

    • REPOSITORY è l'ID del repository.

    • ROLE è il ruolo che vuoi concedere. + LOCATION è la posizione regionale del repository.

      Ad esempio, configura il repository my-repo nella posizione -- come pubblico, esegui:

      gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location= --member=allUsers --role=roles/artifactregistry.reader

    • Imposta un limite per utente alle richieste API Artifact Registry per prevenire abusi da parte di utenti non autenticati. Per istruzioni, vedi Limitare l'utilizzo.

Revoca dei ruoli in corso

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

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

Console

Per revocare le autorizzazioni:

  1. Apri la pagina Repository nella console Google Cloud .

    Apri la pagina Repositori

  2. Seleziona il repository appropriato.

  3. Se il riquadro informazioni non è visualizzato, fai clic su Mostra riquadro informazioni nella barra dei menu.

  4. Nella scheda Autorizzazioni, espandi l'entità appropriata. Se rendi privato un repository pubblico, espandi l'entità allUsers.

  5. Fai clic su Rimuovi entità per revocare l'accesso.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per revocare un ruolo a livello di progetto, esegui questo comando:

    gcloud projects remove-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
    • PROJECT è l'ID progetto.

    • PRINCIPAL è l'entità per la quale rimuovere l'associazione. Utilizza il modulo user|group|serviceAccount:email o domain:domain.

      Esempi: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com o domain:example.domain.com.

    • ROLE è il ruolo che vuoi revocare.

    Per revocare un ruolo per un repository, eseguire il seguente comando:

    gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE

    dove

    • REPOSITORY è l'ID del repository.

    • PRINCIPAL è l'entità per la quale rimuovere l'associazione. Utilizza il modulo user|group|serviceAccount:email o domain:domain.

      Esempi: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com o domain:example.domain.com.

      Per revocare l'accesso pubblico al repository, specificare il principal allUsers.

    • ROLE è il ruolo che vuoi revocare.

    Ad esempio, per rimuovere un'associazione di policy per il ruolo roles/artifactregistry.writer per l'utente write@gmail.com con il repository my-repo nella località --, esegui:

    gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location= \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer

    Per revocare l'accesso pubblico a my-repo nella località --, esegui:

    gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location= \
   --member=allUsers \
   --role=roles/artifactregistry.reader

Concessione dell'accesso condizionale con i tag

Gli amministratori del 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 utilizzare il tag con le condizioni IAM per concedere l'accesso condizionale al repository.

Non puoi collegare tag a singoli artefatti.

Per saperne di più, consulta la seguente documentazione:

Integrazione con i Google Cloud servizi

Per la maggior parte Google Cloud dei service account, la configurazione dell'accesso a un registro richiede solo la concessione dei ruoli IAM appropriati.

Service account predefiniti per i servizi Google Cloud

Google Cloud i servizi come Google Kubernetes Engine utilizzano un account di servizio predefinito o un agente di servizio per interagire con le risorse 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.
  • Stai utilizzando un account di servizio fornito dall'utente per interagire con Artifact Registry anziché l'account di servizio predefinito.
  • La configurazione dei criteri organizzativi impedisce l'assegnazione automatica dei ruoli agli account di servizio predefiniti.

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

Servizio Service account Indirizzo email
Compute Engine Account di servizio predefinito Compute Engine PROJECT-NUMBER-compute@
GKE Account di servizio predefinito di Compute Engine
Il service account predefinito per i nodi.		 PROJECT-NUMBER-compute@

A seconda della configurazione della policy dell'organizzazione, al service account predefinito potrebbe essere assegnato automaticamente il ruolo Editor nel progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli forzando l'applicazione del vincolo iam.automaticIamGrantsForDefaultServiceAccounts della policy dell'organizzazione. Se hai creato la tua organizzazione dopo il 3 maggio 2024, questo vincolo viene imposto per impostazione predefinita.

Se disattivi la concessione automatica dei ruoli, devi decidere quali ruoli concedere ai service account predefiniti, quindi concedere personalmente questi ruoli.

Se il service account predefinito dispone già del ruolo Editor, ti consigliamo di sostituire il ruolo Editor con ruoli meno permissivi.

Concessione dell'accesso alle istanze Compute Engine

Le istanze VM che accedono ai repository devono avere configurati sia i permessi di Artifact Registry sia l'ambito di accesso allo storage accessscope.

Mentre il livello di accesso di un account di servizio è determinato dai ruoli IAM concessi alaccount di serviziot, gli ambiti di accesso di un'istanza VM determinano gli ambiti OAuth predefiniti per le richieste effettuate tramite gcloud CLI e le librerie client nell'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 le istanze VM. L'indirizzo email dell'account di servizio ha il suffisso@.
  • Il account di servizio predefinito ha il ruolo Editor di base IAM, se non hai disattivato questo comportamento.
  • Le istanze create con il account di servizio predefinito hanno gli ambiti di accesso predefiniti di Compute Engine, incluso l'accesso in sola lettura allo spazio di archiviazione. Sebbene il ruolo Editor conceda generalmente l'accesso in scrittura, l'ambito di accesso allo spazio di archiviazione read-only limita il service account dell'istanza al download di artefatti solo da qualsiasi repository nello stesso progetto.

È necessario configurare l'ambito di accesso del account di servizio se:

  • Il account di servizio VM deve accedere a un repository in un altro progetto.
  • Il account di servizio VM deve eseguire azioni diverse dalla lettura degli artefatti dai repository. In genere, questo vale per gli strumenti di terze parti su una VM che devono trasferire immagini o eseguire comandi gcloud di Artifact Registry.

Per configurare i ruoli e impostare l'ambito di accesso:

  1. Nel progetto con l'istanza VM, recupera il nome del service account predefinito di Compute Engine. L'indirizzo email dell'account di servizio ha il suffisso@.

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

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

    1. Arresta l'istanza VM. Consulta Arrestare 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 solo l'autorizzazione di lettura per il download delle immagini.
        • storage-rw: concede l'autorizzazione di lettura e scrittura per il push o il pull delle immagini.
        • cloud-platform: visualizza e gestisci i dati, inclusi i metadati, nel servizioGoogle Cloud .

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

    3. Riavvia l'istanza VM. Vedi Avvio di un'istanza arrestata.

Concessione dell'accesso ai cluster Google Kubernetes Engine

I cluster e i pool di nodi GKE possono scaricare container senza alcuna configurazione aggiuntiva se vengono soddisfatti tutti i seguenti requisiti:

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

Service account predefinito

I seguenti requisiti di configurazione si applicano all'account di servizio predefinito di Compute Engine:

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

  2. Per eseguire il push delle immagini, interagire con i repository per formati diversi dai container o eseguire comandi gcloud dal cluster, devi impostare ambiti di accesso per iaccount di serviziont quando crei il cluster o il pool di nodi.

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

Account di servizio fornito dall'utente

Se si desidera utilizzare un account di servizio fornito dall'utente come identità per un cluster, è necessario:

  1. Concedi le autorizzazioni richieste al account di servizio del progettoGoogle Cloud in cui è in esecuzione Artifact Registry.

  2. Per impostazione predefinita, la creazione di un cluster o di un pool di nodi con un service account fornito dall'utente 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 da utilizzare con Artifact Registry.

Impostazione degli ambiti di accesso

Gli ambiti di accesso sono il metodo legacy per specificare l'autorizzazione per le VM di Compute Engine. Per eseguire il pull delle immagini dai repository Artifact Registry, i nodi GKE devono disporre dell'ambito di accesso in sola lettura allo spazio di archiviazione o di 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 pool di nodi. Non puoi modificare gli ambiti di accesso sui nodi esistenti.

  • Se si utilizza l'account di servizio predefinito di Compute Engine (Compute Engine), GKE crea nodi con gli ambiti di accesso predefiniti di Compute Engine (default access scopes, che includono l'accesso in sola lettura allo storage.
  • Se utilizzi un account di servizio fornito dall'utente, GKE crea nodi con l'ambito cloud-platform, l'ambito richiesto per la maggior parte dei serviziGoogle 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 questo 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 il pull delle immagini.

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

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

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

Per saperne di più sugli ambiti che puoi impostare durante la creazione di un nuovo cluster, consulta la documentazione del comando gcloud container clusters create.

Configurazione di un imagePullSecret

Per configurare un imagePullSecret:

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

  2. Scarica la account di servizio account per il account di servizio.

  3. Nel progetto con il repository, verifica di aver concesso le autorizzazioni al repository.

  4. Nel progetto con il tuo cluster, crea un segreto 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)"

    Sostituisci quanto segue:

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

  5. Apri il account di servizio predefinito:

    kubectl edit serviceaccount default --namespace default

    Ogni spazio dei nomi nel tuo cluster Kubernetes ha un account di servizio predefinito chiamato default. Questo account di servizio predefinito viene utilizzato per fare il pull della tua immagine container.

  6. Aggiungi il secret imagePullSecret appena creato al tuo service account predefinito:

    imagePullSecrets:
- name: artifact-registry

    Il tuo account di servizio dovrebbe ora apparire così:

    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 nello spazio dei nomi default corrente avranno il secret imagePullSecret definito.

Service agent Artifact Registry

L'agente del servizio di Artifact Registry è un account di servizio gestito da Google che agisce per conto di Artifact Registry quando interagisce con i servizi Google Cloud. Per saperne di più sull'account e sulle relative autorizzazioni, consulta Service Agent di Artifact Registry.

Passaggi successivi

Dopo aver configurato le autorizzazioni, scopri di più su come utilizzare gli artefatti.