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 necessarie per accedere ai repository.
Se utilizzi Artifact Analysis per lavorare con i metadati dei container, ad esempio le vulnerabilità rilevate nelle immagini, consulta la documentazione di Artifact Analysis per informazioni su come concedere l'accesso per visualizzare o gestire i metadati.Prima di iniziare
- Abilita Artifact Registry, inclusa l'abilitazione dell'API e l'installazione di Google Cloud CLI.
- 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 direttamente autorizzazioni a un'entità, ma devi concederle un ruolo. Se concedi un ruolo a un'entità, gli concedi tutte le autorizzazioni incluse nel ruolo. Puoi concedere più ruoli alla stessa entità.
Google Cloud autorizzazioni predefinite
Per impostazione predefinita, le seguenti autorizzazioni si applicano ai Google Cloud servizi CI/CD 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 Google Cloud progetto e le autorizzazioni predefinitesoddisfano 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 il ruolo richiesto al pool di identità del carico di lavoro o all'account di servizio per ogni servizio. Se ti connetti a Cloud Run, concedi all'agente di servizio Cloud Run il ruolo richiesto.
- Utilizzi una versione di GKE che non ha il supporto integrato per il recupero delle immagini da Artifact Registry. Consulta la sezione GKE per le istruzioni di configurazione.
- Vuoi che l'account di servizio predefinito abbia accesso in lettura e scrittura ai repository. Per maggiori dettagli, consulta 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 Google Cloud utilizzano chiavi degli account di servizio per accedere Google Cloud alle risorse. Tuttavia, le chiavi degli account di servizio sono credenziali molto potenti e possono rappresentare un rischio per la sicurezza se non vengono gestite correttamente.
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 workload:
- Crea un pool di federazione delle identità per i workload.
- Crea un provider di federazione delle identità per i carichi di lavoro.
- Concedi il ruolo Artifact Registry appropriato al pool di identità del workload per consentire l'accesso al repository. Per ulteriori informazioni, consulta Consentire al tuo carico di lavoro esterno di accedere alle Google Cloud risorse.
- Se devi accedere ad Artifact Registry per periodi di tempo più lunghi, configura la data e l'ora di scadenza del token OIDC su un periodo più lungo nella configurazione delle credenziali.
Configura il client di terze parti per eseguire l'autenticazione con Artifact Registry.
Utilizza un account di servizio:
- Crea un account di servizio per agire per conto della tua applicazione oppure scegli un account di servizio esistente da utilizzare per l'automazione CI/CD.
- Concedi il ruolo Artifact Registry appropriato all'account di servizio per fornire l'accesso al repository.
Configura il client di terze parti per eseguire l'autenticazione con Artifact Registry.
GitLab su Google Cloud
L'integrazione di GitLab su Google Cloud utilizza la federazione Workload Identity per l'autorizzazione e l'autenticazione dei carichi di lavoro GitLab su Google Cloud senza la necessità di account di servizio o chiavi degli account di servizio. Per ulteriori informazioni su come viene utilizzata la federazione di Workload Identity in questa partnership, consulta Google Cloud Workload Identity Federation e i criteri IAM.
Per configurare la federazione delle identità per i carichi di lavoro e i ruoli IAM necessari per GitLab su Google Cloud, consulta il tutorial di GitLab Google Cloud Federazione delle identità per i carichi di lavoro 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 il principale che effettua la richiesta abbia le autorizzazioni necessarie per utilizzare la risorsa. Le autorizzazioni vengono assegnate alle entità impostando criteri che concedono all'entità un ruolo predefinito nella risorsa.
Puoi concedere i ruoli nel Google Cloud progetto o nel repository Artifact Registry.
Ruoli predefiniti di Artifact Registry
IAM fornisce ruoli predefiniti che consentono l'accesso a risorse Google Cloud specifiche.
Utilizza i seguenti ruoli predefiniti per i repository nel dominiopkg.dev
:
Ruolo | Descrizione |
---|---|
Artifact Registry Reader ( roles/artifactregistry.reader ) |
Visualizza e recupera gli elementi, visualizza i metadati del repository. |
Artifact Registry Writer ( roles/artifactregistry.writer ) |
Leggere e scrivere elementi. |
Artifact Registry Repository Administrator ( roles/artifactregistry.repoAdmin ) |
Leggere, scrivere ed eliminare elementi. |
Amministratore di Artifact Registry ( roles/artifactregistry.admin ) |
Crea e gestisci repository e artefatti. |
Ruolo | Descrizione |
---|---|
Container Registry -> Artifact Registry Migration Admin
(roles/artifactregistry.containerRegistryMigrationAdmin ) |
Include tutte le autorizzazioni necessarie per eseguire gli strumenti di migrazione |
Artifact Registry Create-on-push Writer
(roles/artifactregistry.createOnPushWriter ) |
Leggere e scrivere elementi. Crea repository gcr.io quando esegui push verso URL gcr.io .
|
Artifact Registry Create-on-push Repository Administrator
(roles/artifactregistry.createOnPushRepoAdmin ) |
Leggere, scrivere ed eliminare elementi. Crea repository gcr.io. |
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 concedere i 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 ove possibile in modo che gli utenti e gli account di servizio dispongano solo delle autorizzazioni necessarie.
Per saperne di più sui ruoli di base, consulta 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 i ruoli a livello di repository.
Se concedi i ruoli a un repository virtuale, questi ruoli si applicano a tutti i repository a monte disponibili tramite il repository virtuale, indipendentemente dalle autorizzazioni dei singoli repository.Se concedi i ruoli utilizzando il comando gcloud
, puoi specificare un singolo assegnamento dei ruoli per un'entità oppure apportare modifiche ai criteri su larga scala recuperando il criterio di autorizzazione di una risorsa, modificandolo e impostando il criterio di autorizzazione modificato. Per ulteriori informazioni, consulta Concedere o revocare più ruoli tramite programmazione.
Concedere 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 del Registry degli elementi:
Console
Apri la pagina IAM nella console Google Cloud.
Fai clic su Seleziona un progetto, scegli il progetto in cui è in esecuzione Artifact Registry e fai clic su Apri.
Fai clic su Aggiungi.
Inserisci un indirizzo email. Puoi aggiungere singoli utenti, account di servizio o gruppi Google come entità.
Seleziona un ruolo per l'entità. In conformità con il principio di sicurezza del privilegio minimo, ti consigliamo di concedere il minor numero di privilegi necessari per accedere alle risorse Artifact Registry richieste. Per informazioni su ruoli e 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.
Per concedere un ruolo a un singolo principale, esegui il seguente 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 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
odomain: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 di criteri, consulta Concedere o revocare più ruoli in modo programmatico
Concedere ruoli specifici per il repository
Concedi i ruoli a livello di repository se vuoi che gli utenti o gli account di servizio abbiano diversi livelli di accesso per ogni repository del progetto.
Console
Per concedere l'accesso a un repository specifico:
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, fai clic su Aggiungi entità.
Inserisci un indirizzo email. Puoi aggiungere singoli utenti, account di servizio o gruppi Google come entità.
Seleziona un ruolo per l'entità. In conformità con il principio di sicurezza del privilegio minimo, ti consigliamo di concedere il minor numero di privilegi necessari per accedere alle risorse Artifact Registry richieste. Per informazioni sui ruoli e sulle autorizzazioni predefiniti di Artifact Registry, consulta la sezione 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 un singolo principale, esegui il seguente 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
odomain:example.domain.com
.ROLE è il ruolo che vuoi concedere.
LOCATION è la posizione regionale o multiregionale del repository.
Ad esempio, per aggiungere un'associazione della policy IAM per il ruolo
roles/artifactregistry.writer
per l'utentewrite@gmail.com
con il repositorymy-repo
nella posizione--us-west1
, esegui:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
Per concedere i ruoli utilizzando un file di criteri, utilizza la procedura descritta in Concedere o revocare più ruoli tramite 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 un criterio IAM. L'esempio seguente definisce un account di servizio con il nome della risorsa repo-account
e gli concede l'accesso in lettura a un repository con il nome della risorsa my-repo
.
Se non hai mai utilizzato Terraform per Google Cloud, consulta la pagina Inizia sul sito web di HashiCorp. Google Cloud
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. Si tratta della parte del campo email dell'account di servizio precedente al simbolo @
.
Per altri esempi, consulta la documentazione della risorsa google_artifact_registry_repository_iam.
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 il ruolo
Lettore del registry di elementi all'entità allUsers
. Ti consigliamo inoltre di limitare le quote di richieste degli utenti in modo che un singolo utente non possa utilizzare tutta la quota complessiva del progetto.
Console
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, fai clic su Aggiungi entità.
Nel campo Nuove entità, inserisci
allUsers
.Seleziona il ruolo Lettore del registry degli elementi.
Imposta un limite per utente per le richieste dell'API Artifact Registry per impedire l'uso improprio da parte di utenti non autenticati. Per le istruzioni, consulta Impostare un limite di 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 posizione--us-west1
come pubblico, esegui:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-west1 --member=allUsers --role=roles/artifactregistry.reader
Imposta un limite per utente per le richieste dell'API Artifact Registry per impedire l'uso improprio da parte di utenti non autenticati. Per le istruzioni, consulta Impostare un limite di utilizzo.
Revoca dei ruoli in corso
Per revocare l'accesso a un repository, rimuovi l'entità dall'elenco di quelle autorizzate.
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 il seguente 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
odomain:example.domain.com
.ROLE è il ruolo che vuoi revocare.
Per revocare un ruolo per un repository, esegui 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 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 il repositorymy-repo
nella posizione--us-west1
, esegui:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-west1 \ --member=user:write@gmail.com \ --role=roles/artifactregistry.writer
Per revocare l'accesso pubblico a
my-repo
nella località--us-west1
, esegui:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-west1 \ --member=allUsers \ --role=roles/artifactregistry.reader
Concedere l'accesso condizionale con i tag
Gli amministratori dei progetti 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 collegare i tag ai singoli elementi.
Per ulteriori informazioni, consulta la seguente documentazione:
- Amministratori che configurano i tag e il controllo dell'accesso
- Sviluppatori che aggiungono tag ai repository
Integrazione con i Google Cloud servizi
Per la maggior parte degli account di servizio, la configurazione dell'accesso a un registry richiede solo l'assegnazione dei ruoli IAM appropriati. Google Cloud
Account di servizio predefiniti per i Google Cloud servizi
Google Cloud servizi come Cloud Build o 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 Google Cloud servizio si trova in un progetto diverso da Artifact Registry.
- Le autorizzazioni predefinite non soddisfano le tue esigenze.
- Utilizzi un account di servizio fornito dall'utente per interagire con Artifact Registry anziché l'account di servizio predefinito.
- La configurazione dei criteri dell'organizzazione impedisce le concessioni automatiche dei ruoli agli account di servizio predefiniti.
In genere, i seguenti account di servizio accedono ad Artifact Registry. L'ID o il numero di progetto del progetto in cui è in esecuzione il servizio. Google Cloud
Servizio | Service account | Indirizzo email |
---|---|---|
Ambiente flessibile di App Engine | Account di servizio App Engine | PROJECT-ID@appspot.gserviceaccount.com |
Compute Engine | Account di servizio predefinito Compute Engine | PROJECT-NUMBER-compute@developer.gserviceaccount.com |
Cloud Build | Account di servizio Compute Engine oppure account di servizio Cloud Build precedente |
A seconda delle impostazioni dell'organizzazione, l'indirizzo email dell'account di servizio predefinito è uno dei seguenti:
|
Cloud Run |
Agente di servizio Cloud Run Agente di servizio per run.googleapis.com . |
service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com |
GKE |
Account di servizio predefinito Compute Engine L'account di servizio predefinito per i nodi. |
PROJECT-NUMBER-compute@developer.gserviceaccount.com |
A seconda della configurazione delle norme dell'organizzazione, all'account di servizio predefinito potrebbe essere assegnato automaticamente il ruolo Editor nel progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli
applicando il vincolo iam.automaticIamGrantsForDefaultServiceAccounts
delle norme dell'organizzazione. Se hai creato la tua organizzazione dopo il 3 maggio 2024, questo vincolo viene applicato per impostazione predefinita.
Se disattivi la concessione automatica dei ruoli, devi decidere quali ruoli concedere agli account di servizio predefiniti, quindi concedere personalmente questi ruoli.
Se l'account di servizio predefinito dispone già del ruolo Editor, ti consigliamo di sostituire il ruolo Editor con ruoli meno permissivi.Per modificare in sicurezza i ruoli dell'account di servizio, utilizza Policy Simulator per vedere l'impatto della modifica, quindi concedi e revoca i ruoli appropriati.
Concedere l'accesso alle istanze 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.
Sebbene il livello di accesso di un account di servizio sia determinato dai ruoli IAM concessi all'account di servizio, gli ambiti di accesso su un'istanza VM determinano gli ambiti OAuth predefiniti per le richieste effettuate tramite la CLI gcloud 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 @developer.gserviceaccount.com.
- L'account di servizio predefinito ha il ruolo Editor di IAM di base, se non hai disattivato questo comportamento.
- Le istanze create con l'account di servizio predefinito hanno gli ambiti di accesso predefiniti di Compute Engine, incluso l'accesso di sola lettura allo spazio di archiviazione. Sebbene il ruolo Editor in genere conceda l'accesso in scrittura, l'ambito di accesso allo spazio di archiviazione
read-only
limita il service account dell'istanza al download di elementi 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 altro progetto.
- L'account di servizio della VM deve eseguire azioni diverse dalla lettura degli elementi
dai repository. In genere, si applicano strumenti di terze parti su una VM che devono spingere le immagini o eseguire comandi
gcloud
di Artifact Registry.
Per configurare i ruoli e impostare l'ambito di accesso:
Nel progetto con l'istanza VM, ottieni il nome dell'account di servizio predefinito Compute Engine. L'indirizzo email dell'account di servizio ha il suffisso @developer.gserviceaccount.com.
Nel progetto con il repository, concedi le autorizzazioni in modo che l'account di servizio possa accedere al repository.
Imposta l'ambito di accesso con l'opzione --scopes.
Arresta l'istanza VM. Consulta Arrestare un'istanza.
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 recupero delle immagini.storage-rw
: concede l'autorizzazione di lettura e scrittura per l'invio o il recupero di immagini.cloud-platform
: visualizza e gestisci i dati, inclusi i metadati, nel servizio.Google Cloud
Per altri formati, devi utilizzare l'ambito
cloud-platform
.
Riavvia l'istanza VM. Consulta Avvio di un'istanza interrotta.
Concedere l'accesso ai cluster Google Kubernetes Engine
I cluster e i pool di nodi GKE possono estrarre i container senza alcuna configurazione aggiuntiva se vengono 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 all'account di servizio predefinito di Compute Engine:
Se GKE si trova in un progetto diverso da Artifact Registry, concedi le autorizzazioni richieste all'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 utilizzi una versione supportata di GKE, configura imagePullSecrets.
- Service account fornito dall'utente
Se vuoi utilizzare un account di servizio fornito dall'utente come identità per un cluster, devi:
Conceda le autorizzazioni richieste all'account di servizio dal Google Cloud progetto 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 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. 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 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 serviziGoogle Cloud .
Per specificare gli ambiti di accesso durante la creazione di un cluster, esegui il seguente 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 node pool.
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 recupero delle immagini.storage-rw
: concede l'autorizzazione di lettura e scrittura per l'invio o il recupero di immagini.cloud-platform
: visualizza e gestisci i dati, inclusi i metadati, nel servizio.Google CloudPer 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 ulteriori informazioni 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
:
Nel progetto con GKE, trova l'account di servizio predefinito di Compute Engine. 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 aver concessi le autorizzazioni 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)"
Sostituisci quanto segue:
- LOCATION è la posizione regionale o multiregionale del repository.
- SERVICE-ACCOUNT-EMAIL è l'indirizzo email dell'account di servizio Compute Engine.
- KEY-FILE è il nome del file della chiave dell'account di servizio. Ad 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 segreto
imagePullSecret
appena creato al tuo account di servizio predefinito:imagePullSecrets: - name: artifact-registry
L'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 CloudPer 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