Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Trusted Cloud di S3NS.

Questa pagina è stata tradotta dall'API Cloud Translation.

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. Puoi anche 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

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 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. Puoi concedere più ruoli alla stessa entità.

Trusted Cloud autorizzazioni predefinite

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

Compute Engine e le versioni supportate di Google Kubernetes Engine utilizzano l'account di servizio predefinito di Compute Engine, che dispone dell'accesso in sola lettura all'archiviazione.

Se tutti i tuoi servizi si trovano nello stesso progetto Trusted Cloud by S3NS 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.
Vuoi che il account di servizio predefinito abbia accesso in lettura e scrittura ai repository. Per maggiori dettagli, consulta le seguenti informazioni:
- Compute Engine
- GKE
Stai utilizzando un account di servizio fornito dall'utente per gli ambienti di runtime anziché ilaccount di serviziot predefinito. Nel progetto con Artifact Registry, concedi al 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 all'esterno di Trusted Cloud utilizzano chiavi dell'account di servizio per accedere alle risorse Trusted Cloud . 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 carichi di lavoro ti consente di utilizzare Identity and Access Management per concedere alle identità esterne ruoli IAM, inclusa la possibilità di impersonare service account. Questo approccio elimina l'onere di manutenzione e sicurezza associato alle chiavi del service account.

Utilizza la federazione di Workload Identity:

Crea un pool di federazione delle identità per i workload.
Crea un provider di federazione delle identità per i workload.
Concedi il ruolo Artifact Registry appropriato al pool di identità dei workload per consentire l'accesso al repository. Per maggiori informazioni, vedi Consentire al tuo workload esterno di accedere alle risorse Trusted Cloud by S3NS .
Se devi accedere ad Artifact Registry per periodi di tempo più lunghi, configura la scadenza del token OIDC su un periodo più lungo nella configurazione delle credenziali.
Configura il client di terze parti per l'autenticazione con Artifact Registry.
- Immagini container: Docker, Helm
- Pacchetti del sistema operativo: Debian, RPM

Utilizza un service account:

Crea un service account che agisca per conto della tua applicazione oppure scegli un service account 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 l'autenticazione con Artifact Registry.
- Immagini container: Docker, Helm
- Pacchetti del sistema operativo: Debian, RPM

Ruoli e autorizzazioni

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

Puoi concedere i ruoli sul progetto Trusted Cloud by S3NS o sul repository Artifact Registry.

Ruoli Artifact Registry predefiniti

IAM fornisce ruoli predefiniti che concedono l'accesso a risorse Trusted 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.
Writer Artifact Registry (`roles/artifactregistry.writer`)	Leggere e scrivere artefatti.
Amministratore repository Artifact Registry (`roles/artifactregistry.repoAdmin`)	Leggere, scrivere ed eliminare gli artefatti.
Amministratore Artifact Registry (`roles/artifactregistry.admin`)	Crea e gestisci repository e artefatti.

Per un elenco completo delle singole autorizzazioni in ogni ruolo, consulta la pagina 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 che esistevano prima dell'introduzione di IAM. Non devi concedere ruoli di base in un ambiente di produzione, ma puoi concederli in un ambiente di sviluppo o di test.

Utilizza i ruoli predefiniti per l'accesso al repository ogni volta che è 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, assegna ruoli a livello di repository.

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

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.

Nota: Trusted Cloud by S3NS utilizza un provider di identità esterno, pertanto devi utilizzare gli identificatori dei principal della federazione delle identità per la forza lavoro. Sostituisci le istanze degli identificatori principali dell'Account Google, come user:kiran@example.com, group:support@example.com e domain:example.com, con gli identificatori principali della federazione delle identità della forza lavoro appropriati.

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

Console

Apri la pagina IAM nella console Trusted Cloud .
Apri la pagina IAM
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 privati, service account o Gruppi Google come entità.
Seleziona un ruolo per l'entità. In conformità al principio di sicurezza del privilegio minimo, valuta la possibilità di concedere il livello di privilegio minimo necessario 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 Trusted Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Trusted 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 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 cui 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, consulta la documentazione relativa a add-iam-policy-binding.

Per concedere ruoli utilizzando un file di policy, vedi Concedere o revocare più ruoli in modo programmatico

Concessione di ruoli specifici per il repository

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

Console

Per concedere l'accesso a un repository specifico:

Apri la pagina Repository nella console Trusted Cloud .

Apri la pagina Repositori
Seleziona il repository appropriato.
Se il riquadro informazioni non è 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 privati, service account o gruppi Google come entità.
Seleziona un ruolo per l'entità. In conformità al principio di sicurezza del privilegio minimo, valuta la possibilità di concedere il livello di privilegio minimo necessario 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 Trusted Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Trusted 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 singoli binding dei criteri o utilizzare un file di criteri.

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 cui 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 località 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à --u-france-east1, esegui:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=u-france-east1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
Per concedere ruoli utilizzando un file di criteri, 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 un criterio 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 Trusted Cloud by S3NS, consulta la pagina Guida introduttiva - Trusted Cloud by S3NS 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 del account di servizio. Si tratta della parte del campo email delaccount di serviziot 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 di richieste degli utenti in modo che un singolo utente non possa esaurire la quota complessiva del tuo progetto.

Console

Apri la pagina Repository nella console Trusted Cloud .

Apri la pagina Repositori
Seleziona il repository appropriato.
Se il riquadro informazioni non è 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 impedire l'uso improprio da parte di utenti non autenticati. Per istruzioni, consulta Limitare l'utilizzo.

gcloud

In the Trusted Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Trusted 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 del repository.
  
  Ad esempio, configura il repository my-repo nella posizione --u-france-east1 come pubblico, esegui:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=u-france-east1 --member=allUsers --role=roles/artifactregistry.reader
```
- Imposta un limite per utente per le richieste API Artifact Registry per impedire l'uso improprio da parte di utenti non autenticati. Per istruzioni, consulta 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:

Apri la pagina Repository nella console Trusted Cloud .

Apri la pagina Repositori
Seleziona il repository appropriato.
Se il riquadro informazioni non è visualizzato, fai clic su Mostra riquadro informazioni nella barra del menu.
Nella scheda Autorizzazioni, espandi l'entità appropriata. Se stai rendendo privato un repository pubblico, espandi l'entità allUsers.
Fai clic su Rimuovi entità per revocare l'accesso.

gcloud

In the Trusted Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Trusted 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 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, 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 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, 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'utente write@gmail.com con il repository my-repo nella località --u-france-east1, esegui:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=u-france-east1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer
```
Per revocare l'accesso pubblico a my-repo nella località --u-france-east1, esegui:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=u-france-east1 \
   --member=allUsers \
   --role=roles/artifactregistry.reader
```

Concessione dell'accesso condizionale con i tag

Gli amministratori dei progetti possono creare tag per le risorse in Trusted 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 ulteriori informazioni, consulta la seguente documentazione:

Amministratori che configurano tag e controllo dell'accesso
- Creazione e gestione dei tag
- Tag e controllo dell'accesso.
Sviluppatori che aggiungono tag ai repository
- Tagging dei repository

Integrazione con i servizi Trusted Cloud

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

Service account predefiniti per i servizi Trusted Cloud by S3NS

I serviziTrusted Cloud 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 Trusted Cloud by S3NS servizio 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é il account di servizio predefinito.
La configurazione della policy dell'organizzazione impedisce le concessioni automatiche di ruoli agli account di servizio predefiniti.

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

Servizio	Service account	Indirizzo email
Compute Engine	Account di servizio predefinito Compute Engine	`PROJECT-NUMBER`-compute@developer.s3ns-system.iam.gserviceaccount.com
GKE	Account di servizio predefinito di Compute Engine Il service account predefinito per i nodi.	`PROJECT-NUMBER`-compute@developer.s3ns-system.iam.gserviceaccount.com

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 configurate sia le autorizzazioni Artifact Registry sia l'ambito di accesso di archiviazione.

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:

Il service account predefinito di Compute Engine è l'identità delle istanze VM. L'indirizzo email del account di servizio ha il suffisso @developer.s3ns-system.iam.gserviceaccount.com.
Il account di servizio predefinito ha il ruolo IAM di base Editor, 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.

Devi 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:

Nel progetto con l'istanza VM, recupera il nome del service account predefinito di Compute Engine. L'indirizzo email del account di servizio ha il suffisso @developer.s3ns-system.iam.gserviceaccount.com.
Nel progetto con il repository, concedi le autorizzazioni in modo che il account di servizio possa accedere al repository.
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 l'autorizzazione di lettura solo per il recupero 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 servizio Trusted Cloud .
  - Per gli altri formati, devi utilizzare l'ambito cloud-platform.
3. Riavvia l'istanza VM. Consulta Avvia un'istanza arrestata.

Concessione dell'accesso ai cluster Google Kubernetes Engine

I cluster e i node pool 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 il service account predefinito, ovvero l'account di servizio predefinito di Compute Engine
I nodi sono stati creati con accesso in lettura all'archiviazione da:
- Utilizzando gli ambiti di accesso predefiniti di Compute Engine.
- Concedere l'ambito di accesso cloud-platform o un altro ambito che includa l'accesso in lettura allo spazio di archiviazione.
Stai eseguendo 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 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:

Se GKE si trova in un progetto diverso da Artifact Registry, concedi le autorizzazioni richieste all'account di servizio.
Per eseguire il push delle immagini, interagire con i repository per formati diversi dai container o eseguire comandi gcloud dal cluster, devi impostare gli ambiti di accesso per il account di servizio quando crei il cluster o il pool di nodi.
Se non utilizzi una versione supportata di GKE, configura imagePullSecrets.

Account di servizio fornito dall'utente

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

Concedi le autorizzazioni richieste al account di servizio dal progettoTrusted 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 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 estrarre immagini dai repository Artifact Registry, i nodi GKE devono avere l'ambito di accesso in 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 pool di nodi. Non puoi modificare gli ambiti di accesso nei nodi esistenti.

Se utilizzi il service account predefinito di Compute Engine, GKE crea nodi con gli ambiti di accesso predefiniti di Compute Engine, che includono l'accesso in sola lettura allo spazio di archiviazione.
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 serviziTrusted 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 servizio Trusted 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:

Nel progetto con GKE, trova il account di servizio predefinito di Compute Engine. L'indirizzo email dell'account ha il suffisso @developer.s3ns-system.iam.gserviceaccount.com.
Scarica la chiave dell'account di servizio per l'account di servizio.

Nota :le chiavi dei service account comportano un rischio per la sicurezza se non vengono gestite correttamente. Dovresti scegliere un'alternativa più sicura alle account di servizio account quando è possibile. Se devi eseguire l'autenticazione con una chiave dell'account di servizio, sei responsabile della sicurezza della chiave privata e di altre operazioni descritte in Best practice per la gestione delle chiavi degli account di servizio. Se non riesci a creare una chiave del account di servizio, la creazione di chiavi del account di servizio potrebbe essere disabilitata per la tua organizzazione. Per saperne di più, consulta Gestione delle risorse dell'organizzazione sicure per impostazione predefinita.
Se hai acquisito la chiave dell'account di servizio da una fonte esterna, devi convalidarla prima dell'utilizzo. Per maggiori informazioni, consulta Requisiti di sicurezza per le credenziali di origine esterna.
Nel progetto con il repository, verifica di aver concesso le autorizzazioni al repository.
Nel progetto con il tuo cluster, crea un secret imagePullSecret denominato artifact-registry con la chiave del account di servizio.
```
kubectl create secret docker-registry artifact-registry \
--docker-server=https://LOCATION-docker.s3nsregistry.fr \
--docker-email=SERVICE-ACCOUNT-EMAIL \
--docker-username=_json_key \
--docker-password="$(cat KEY-FILE)"
```
Sostituisci quanto segue:
- LOCATION è la località regionale del repository.
- SERVICE-ACCOUNT-EMAIL è l'indirizzo email del account di servizio Compute Engine.
- KEY-FILE è il nome del file della chiave del account di servizio. Ad esempio `key.json`.
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 eseguire il pull dell'immagine container.

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

imagePullSecrets:
- name: artifact-registry

Il tuo account di servizio dovrebbe ora avere questo 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 nello spazio dei nomi default corrente avranno il secret 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. Trusted Cloud by S3NSPer ulteriori informazioni sull'account e sulle relative autorizzazioni, consulta Service account Artifact Registry.

Passaggi successivi

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

Immagini container: Docker, Helm
Pacchetti del sistema operativo: Debian, RPM

Controllo dell'accesso con IAM

Prima di iniziare

Panoramica

Trusted Cloud autorizzazioni predefinite

Integrazione di terze parti

Ruoli e autorizzazioni

Ruoli Artifact Registry predefiniti

Ruoli IAM di base

Concessione dei ruoli in corso…

Concessione di ruoli a livello di progetto

Console

gcloud

Concessione di ruoli specifici per il repository

Console

gcloud

Terraform

Configurazione dell'accesso pubblico a un repository

Console

gcloud

Revoca dei ruoli in corso

Console

gcloud

Concessione dell'accesso condizionale con i tag

Integrazione con i servizi Trusted Cloud

Service account predefiniti per i servizi Trusted Cloud by S3NS

Concessione dell'accesso alle istanze Compute Engine

Concessione dell'accesso ai cluster Google Kubernetes Engine

Impostazione degli ambiti di accesso

Configurazione di un imagePullSecret

Account di servizio Artifact Registry

Passaggi successivi

Configurazione di un `imagePullSecret`