In questa pagina viene descritto il controllo dell'accesso con Identity and Access Management (IAM) in Artifact Registry.
Le autorizzazioni predefinite per Artifact Registry riducono al minimo il lavoro di configurazione implementando una pipeline CI/CD. Puoi anche integrare Artifact Registry con strumenti CI/CD di terze parti e configurare le autorizzazioni e l'autenticazione necessarie 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
- Abilita Artifact Registry, tra cui l'abilitazione dell'API e l'installazione di Google Cloud CLI.
- Se vuoi applicare autorizzazioni specifiche del repository, crea un repository Artifact Registry per i tuoi pacchetti.
Panoramica
Autorizzazioni IAM e ruoli determinano la tua capacità di creare, visualizzare o eliminare 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, alle autorizzazioni dei servizi CI/CD di Google Cloud nello stesso progetto di Artifact Registry si applicano le seguenti autorizzazioni:
- Autorizzazioni di Cloud Build includi le autorizzazioni per caricare e scaricare gli artefatti.
- Compute Engine, versioni di Google Kubernetes Engine supportate e Cloud Run utilizza Compute Engine account di servizio predefinito, che dispone dell'accesso di sola lettura allo spazio di archiviazione.
Se tutti i tuoi servizi si trovano nello stesso progetto Google Cloud e lo spazio le autorizzazioni soddisfino le tue esigenze, non devi configurarle.
Devi configurare le autorizzazioni 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 la classe pool di identità per i carichi di lavoro o account di servizio per ciascun servizio ruolo richiesto. Se ti connetti a Cloud Run, concedi la all'agente di servizio Cloud Run le informazioni richieste 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 ai repository. Per informazioni dettagliate, leggi le seguenti informazioni:
- utilizzi un account di servizio fornito dall'utente per i tuoi ambienti di runtime invece dell'account di servizio predefinito. Nel progetto con Artifact Registry, concedi al tuo account di servizio il ruolo richiesto.
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 rappresentare un rischio per la sicurezza se non vengono gestite in modo corretto.
La federazione delle identità per i carichi di lavoro consente di utilizzare Identity and Access Management concedere ruoli IAM a identità esterne, inclusa la possibilità di impersonare account di servizio. Questo approccio elimina l'onere della manutenzione e della sicurezza associato al servizio chiavi dell'account.
Utilizza la federazione delle identità per i carichi di lavoro:
- Crea un pool federazione di Workload Identity.
- Crea un provider di federazione delle identità per i carichi di lavoro.
- Concedi il ruolo Artifact Registry appropriato al carico di lavoro. per consentire l'accesso al repository.
Configura il client di terze parti per eseguire l'autenticazione con Artifact Registry.
Utilizza un account di servizio:
- Creare un servizio di agire per conto della tua applicazione o di scegliere un servizio esistente per l'automazione CI/CD.
- Concedi al servizio il ruolo Artifact Registry appropriato per fornire l'accesso al repository.
Configura il client di terze parti per l'autenticazione con Artifact Registry.
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 sulla federazione delle identità per i carichi di lavoro è usata in questa partnership, vedi 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 di GitLab su 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 e concedere all'entità un ruolo predefinito nella risorsa.
Puoi concedere ruoli nel progetto Google Cloud o in Artifact Registry repository Git.
Ruoli predefiniti di Artifact Registry
IAM fornisce ruoli predefiniti che concedono l'accesso a risorse Google Cloud specifiche e impediscono accesso non autorizzato ad altre risorse.
Utilizza i seguenti ruoli predefiniti per standard, virtuali e remoti
repository sul dominio pkg.dev
:
Ruolo | Descrizione |
---|---|
Lettore Artifact Registry ( roles/artifactregistry.reader ) |
Visualizza e ottieni gli artefatti, visualizza i metadati del repository. |
Writer Artifact Registry ( roles/artifactregistry.writer ) |
Lettura e scrittura degli artefatti. |
Amministratore repository Artifact Registry ( roles/artifactregistry.repoAdmin ) |
Leggere, scrivere ed eliminare elementi. |
Amministratore Artifact Registry ( roles/artifactregistry.admin ) |
Crea e gestisci repository e artefatti. |
I seguenti ruoli predefiniti aggiuntivi includono le autorizzazioni per creare
repository gcr.io per ospitare le immagini per il dominio gcr.io
. La
i ruoli non includono autorizzazioni per creare altri formati di repository
Artifact Registry nel dominio pkg.dev
. Questi ruoli supportano le operazioni precedenti
compatibilità con Container Registry, poiché Container Registry utilizza il primo
push di un'immagine container per creare ciascun registry multiregionale.
Ruolo | Descrizione |
---|---|
Artifact Registry Create-on-push Writer
(roles/artifactregistry.createOnPushWriter ) |
Leggere e scrivere elementi. Creare repository gcr.io. |
Amministratore repository Create-on-push Artifact Registry
(roles/artifactregistry.createOnPushRepoAdmin ) |
Leggere, scrivere ed eliminare elementi. Creare repository gcr.io. |
Per un elenco completo delle singole autorizzazioni in ogni ruolo, consulta
Ruoli del Registry di elementi.
Puoi utilizzare anche
gcloud iam roles describe
per visualizzare un elenco delle autorizzazioni per ciascun 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 alle entità più ampie 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
Concedere autorizzazioni a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente nel 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 account utente o di servizio a un progetto e concedere all'utente un Ruolo Artifact Registry:
Console
Apri la pagina IAM nella console Google Cloud.
Fai clic su Seleziona un progetto e scegli il progetto in cui Artifact Registry è in esecuzione e fai clic su Apri.
Fai clic su Aggiungi.
Inserisci un indirizzo email. Puoi aggiungere singoli utenti, account di servizio Google Gruppi come entità.
Seleziona un ruolo per l'entità. In conformità con le principio del privilegio minimo, valuta la possibilità di concedere il minor numero di privilegio necessario per accedere alle risorse Artifact Registry richieste. Per informazioni su Per i ruoli e le autorizzazioni predefiniti di Artifact Registry, consulta Ruoli di Artifact Registry predefiniti.
Fai clic su Salva.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Per concedere un ruolo a una singola entità, esegui questo comando:
gcloud projects add-iam-policy-binding PROJECT \ --member=PRINCIPAL \ --role=ROLE
dove
- PROJECT è l'ID del progetto in cui Artifact Registry in esecuzione.
PRINCIPAL è l'entità per cui aggiungere l'associazione. Utilizza il modulo
user|group|serviceAccount:email
odomain:domain
.Esempi:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oppuredomain:example.domain.com
.ROLE è il ruolo che vuoi concedere.
Per ulteriori informazioni, consulta la documentazione di add-iam-policy-binding.
Per concedere i ruoli utilizzando un file dei criteri, esegui questo comando:
gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml
Dove
- PROJECT è l'ID del progetto o dell'identificatore completo per il progetto in cui è in esecuzione Artifact Registry.
- /PATH/TO/policy.yaml è il percorso e il nome del file delle norme.
Per ottenere il criterio attualmente configurato, esegui questo comando:
gcloud projects get-iam-policy PROJECT
dove PROJECT è l'ID del progetto o l'identificatore completo del progetto.
Per ulteriori informazioni, consulta la sezione set-iam-policy documentazione.
Concedere autorizzazioni specifiche per il repository
Concedi autorizzazioni a livello di repository quando vuoi che utenti o account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.
Console
Per concedere l'accesso a un repository specifico:
Apri la pagina Repository nella console Google Cloud.
Seleziona il repository appropriato.
Se il riquadro informazioni non viene visualizzato, fai clic su Mostra riquadro informazioni nella barra del menu.
Nella scheda Autorizzazioni, fai clic su Aggiungi entità.
Inserisci un indirizzo email. Puoi aggiungere singoli utenti, account di servizio o Gruppi come entità.
Seleziona un ruolo per l'entità. In conformità con le principio del privilegio minimo, valuta la possibilità di concedere il minor numero di privilegio necessario per accedere alle risorse Artifact Registry richieste. Per informazioni sui ruoli e sulle autorizzazioni predefiniti di Artifact Registry, consulta Ruoli predefiniti di Artifact Registry.
Fai clic su Salva.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Puoi impostare un insieme IAM di singole associazioni di criteri o utilizzare un file di criteri.
Per concedere un ruolo a una singola entità, 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 cui aggiungere l'associazione. Utilizza il modulo
user|group|serviceAccount:email
odomain:domain
.Esempi:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oppuredomain:example.domain.com
.ROLE è il ruolo che vuoi concedere.
LOCATION è la posizione regionale o multiregionale del repository.
Ad esempio, per aggiungere un'associazione di criteri IAM per il ruolo
roles/artifactregistry.writer
per l'utentewrite@gmail.com
con repositorymy-repo
nella località--us-central1
, esegui:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
Per concedere i ruoli utilizzando un file dei criteri, esegui questo comando:
gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION
Dove
- REPOSITORY è l'ID del repository.
- /PATH/TO/policy.yaml sono il percorso e il nome del file del criterio.
- LOCATION indica una o più regioni località del repository.
Ad esempio, per impostare il criterio IAM per il repository
my-repo
nella località--us-central1
con il criterio definito inpolicy.yaml
, esegui:gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
Terraform
Utilizza la risorsa google_artifact_registry_repository_iam per
e configurare un criterio IAM. L'esempio seguente definisce un servizio
con il nome risorsa repo-account
e gli concede l'accesso in lettura
con il nome risorsa my-repo
.
Se non hai mai utilizzato Terraform per Google Cloud, consulta Inizia - Google Cloud nella 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. Questo è il
la parte del campo email dell'account di servizio prima del simbolo @
.
Per ulteriori esempi, consulta la documentazione google_artifact_registry_repository_iam risorsa.
Configurazione dell'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 la
Ruolo Lettore Artifact Registry per l'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.
Console
Apri la pagina Repository nella console Google Cloud.
Seleziona il repository appropriato.
Se il riquadro informazioni non viene visualizzato, fai clic su Mostra riquadro informazioni nella barra del menu.
Nella scheda Autorizzazioni, fai clic su Aggiungi entità.
Nel campo Nuove entità, inserisci
allUsers
.Seleziona il ruolo Lettore Artifact Registry.
Imposta un limite per utente per le richieste API Artifact Registry per evitare l'uso improprio da parte di utenti non autenticati. Per le istruzioni, consulta la sezione Limitazione dell'utilizzo.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
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 o multiregionale del repository.
Ad esempio, configura il repository
my-repo
nella località--us-central1
come pubblico, esegui:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
Imposta un limite per utente per le richieste API Artifact Registry per evitare l'uso improprio da parte di utenti non autenticati. Per le istruzioni, consulta Impostare un limite di utilizzo.
Revoca delle 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
.
Console
Per revocare le autorizzazioni:
Apri la pagina Repositories (Repositoi) nella console Google Cloud.
Seleziona il repository appropriato.
Se il riquadro informazioni non viene visualizzato, fai clic su Mostra riquadro informazioni nella barra del menu.
Nella scheda Autorizzazioni, espandi l'entità appropriata. Se hai deciso di rendere privato un repository pubblico, espandi il principale
allUsers
.Fai clic su Rimuovi entità per revocare l'accesso.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
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 cui rimuovere l'associazione. Utilizza il modulo
user|group|serviceAccount:email
odomain:domain
.Esempi:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oppuredomain:example.domain.com
.ROLE è il ruolo che vuoi revocare.
Per revocare un ruolo per un repository, esegui questo 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 cui rimuovere l'associazione. Utilizza il modulo
user|group|serviceAccount:email
odomain:domain
.Esempi:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
odomain:example.domain.com
.Per revocare l'accesso pubblico al repository, specifica l'entità
allUsers
.ROLE è il ruolo che vuoi revocare.
Ad esempio, per rimuovere un'associazione di criteri per il ruolo
roles/artifactregistry.writer
per l'utentewrite@gmail.com
con repositorymy-repo
nella località--us-central1
, esegui:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-central1 \ --member=user:write@gmail.com \ --role=roles/artifactregistry.writer
Per revocare l'accesso pubblico a
my-repo
nella località--us-central1
, esegui:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-central1 \ --member=allUsers \ --role=roles/artifactregistry.reader
Concessione dell'accesso condizionale con i tag
Gli amministratori di progetto possono creare tag per le risorse in Google Cloud e gestirli in Resource Manager. Quando alleghi un tag a un Artifact Registry, gli amministratori possono utilizzare il tag 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
- Sviluppatori che collegano tag ai repository
Integrazione con i servizi Google Cloud
Per la maggior parte degli account di servizio Google Cloud, la configurazione dell'accesso a un registro 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 personalmente 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, può modificare le autorizzazioni per l'account di servizio della VM o usare 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.
I seguenti account di servizio in genere accedono ad Artifact Registry. La l'indirizzo email dell'account di servizio include Google Cloud ID o numero di progetto del progetto in cui è in esecuzione il servizio.
Servizio | Service account | Indirizzo email | Autorizzazioni |
---|---|---|---|
Ambiente flessibile di App Engine | App Engine account di servizio | PROJECT-ID@appspot.gserviceaccount.com | Ruolo Editor, che consente di leggere e scrivere nei repository |
Compute Engine | Account di servizio predefinito Compute Engine | PROJECT-NUMBER-compute@developer.gserviceaccount.com | Ruolo Editor, limitato all'accesso di sola lettura ai repository |
Cloud Build | Servizio Cloud Build account. | PROJECT-NUMBER@cloudbuild.gserviceaccount.com |
Autorizzazioni predefinite includono l'accesso in lettura e scrittura ai repository e la possibilità di creare repository gcr.io. |
Cloud Run |
Agente di servizio Cloud Run L'agente di servizio di run.googleapis.com . |
service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com | Autorizzazioni di lettore, limitate all'accesso di sola lettura ai repository |
GKE |
Account di servizio predefinito Compute Engine L'account di servizio predefinito per i nodi. |
PROJECT-NUMBER-compute@developer.gserviceaccount.com | Ruolo Editor, limitato all'accesso di sola lettura ai repository |
Concessione dell'accesso alle istanze di Compute Engine
Le istanze VM che accedono ai repository devono avere configurate sia le autorizzazioni di Artifact Registry sia l'ambito di accesso allo spazio di archiviazione.
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 limitare ulteriormente l'accesso ai metodi API durante l'autenticazione con 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 @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:
Nel progetto con la tua istanza VM, trova il nome Account di servizio predefinito Compute Engine. L'indirizzo email dell'account di servizio ha suffisso @developer.gserviceaccount.com.
Nel progetto con il repository, concedi le autorizzazioni in modo che l'account di servizio può accedere al repository.
Imposta l'ambito di accesso con --scopes.
Arresta l'istanza VM. Consulta Arresto di un'istanza.
Imposta l'ambito di accesso con il comando seguente:
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 recupero 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 gli altri formati, devi utilizzare l'ambito
cloud-platform
.
Riavvia l'istanza VM. Consulta Avvio di un'istanza arrestata.
Concessione dell'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.
- Concessione dell'ambito di accesso
cloud-platform
o di un altro ambito che include accesso in lettura allo spazio di archiviazione.
- stai eseguendo una versione supportata di GKE
Se il tuo ambiente GKE non soddisfa questi requisiti, istruzioni per concedere l'accesso variano a seconda che tu stia utilizzando o meno Account di servizio predefinito Compute Engine o un account di servizio fornito dall'utente come e l'identità dei nodi.
- Service account predefinito
I seguenti requisiti di configurazione si applicano Account di servizio predefinito Compute Engine:
Se GKE si trova in un progetto diverso da Artifact Registry, concedi le autorizzazioni richieste l'account di servizio.
Per eseguire push di immagini, interagire con repository per formati diversi dai contenitori o eseguire comandi
gcloud
dal cluster, devi impostare gli ambiti di accesso per l'account di servizio quando crei il cluster o il pool di nodi.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:
Concedi all'account di servizio le autorizzazioni richieste dalla Progetto Google Cloud in cui è in esecuzione Artifact Registry.
Per impostazione predefinita, la creazione di un cluster o di un pool di nodi con un account di servizio fornito dall'utente concede l'ambito di accesso
cloud-platform
.Se utilizzi il flag
--scopes
con gcloud container clusters create o il comando gcloud container node-pools create, devi includere l'appropriata ambiti di accesso da utilizzare con Artifact Registry.
Impostazione degli ambiti di accesso
Gli ambiti di accesso sono il metodo legacy per specificare l'autorizzazione di 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. Non puoi modificare gli ambiti di accesso nei nodi esistenti.
- Se utilizzi l'account di servizio predefinito di Compute Engine, GKE crea i nodi con ambiti di accesso predefiniti, che includono l'accesso di sola lettura 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 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 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 imagePullSecret
Per configurare un imagePullSecret
:
Nel progetto con GKE, trova Compute Engine predefinito l'account di servizio. L'indirizzo email dell'account ha il suffisso @developer.gserviceaccount.com
Scarica la chiave dell'account di servizio per l'account di servizio.
Nel progetto con il repository, verifica di avere le autorizzazioni concesse al repository.
Nel progetto con il cluster, crea un secret
imagePullSecret
chiamatoartifact-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. Per
esempio
key.json
.
Apri il tuo 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.Aggiungi il secret
imagePullSecret
appena creato al tuo account di 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
imagePullSecret
secret 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, vedi 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