gcr.io ospitato su Artifact Registry per impostazione predefinita

Scopri come configurare repository gcr.io in Artifact Registry e scopri le differenze tra le autorizzazioni di Artifact Registry e Container Registry e la configurazione dei bucket di archiviazione.

I passaggi manuali descritti in questo documento possono essere completati utilizzando lo strumento di migrazione automatica. Se vuoi utilizzare lo strumento di migrazione automatica per eseguire la transizione dei tuoi progetti che utilizzano Container Registry attivo ai repository standard di Artifact Registry o ai repository gcr.io, consulta Automatizzare la migrazione ad Artifact Registry.

Ritiro di Container Registry

I progetti Google Cloud che non hanno utilizzato Container Registry prima del 15 maggio 2024 supporteranno solo l'hosting e la gestione delle immagini in Artifact Registry. Questa modifica interessa:

Progetti appena creati.
Progetti esistenti per cui non hai eseguito il push di un'immagine in Container Registry.

Per impostazione predefinita, le organizzazioni che non hanno utilizzato Container Registry prima dell'8 gennaio 2024 avranno nuovi repository gcr.io ospitati su Artifact Registry.

Quando abiliti l'API Artifact Registry in questi progetti, Artifact Registry gestisce automaticamente la creazione di repository gcr.io in Artifact Registry e reindirizzerà le richieste al dominio gcr.io al repository Artifact Registry appropriato. A differenza del supporto per i domini gcr.io esistenti nei progetti con Container Registry attivo, il reindirizzamento ad Artifact Registry sarà automatico.

Container Registry rimarrà disponibile nei progetti in cui si è verificata una delle seguenti azioni prima del 15 maggio 2024:

Hai abilitato l'API Container Registry nel progetto.
Hai eseguito il push di un'immagine a un host del registro del progetto.

Per prepararti al cambiamento imminente, ti consigliamo di:

Segui le istruzioni in questo documento per configurare i progetti in cui non utilizzi Container Registry in modo che siano pronti per la gestione automatica delle richieste gcr.io quando le modifiche vengono applicate.
Testa l'assistenza per i domini gcr.io per verificare che l'automazione esistente continui a funzionare.

gcr.io repository ospitati su Artifact Registry vengono creati nelle stesse aree geografiche multiple supportate da Container Registry. Se vuoi archiviare le immagini in altre regioni, devi passare ai repository standard sul dominio pkg.dev.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare i repository "gcr.io", chiedi all'amministratore di concederti i ruoli IAM seguenti:

Per creare repository Artifact Registry e concedere l'accesso a singoli repository: Amministratore di Artifact Registry (roles/artifactregistry.admin) sul progetto
Per visualizzare e gestire la configurazione esistente di Container Registry applicata ai bucket di archiviazione Cloud Storage: Amministratore Storage (roles/storage.admin) sul progetto
Per concedere l'accesso al repository a livello di progetto: Amministratore IAM progetto (roles/resourcemanager.projectIamAdmin) o un ruolo che include autorizzazioni equivalenti, come Amministratore cartelle (roles/resourcemanager.folderAdmin) o Amministratore organizzazione (roles/resourcemanager.organizationAdmin) sul progetto, nella cartella o nell'organizzazione
Per elencare i servizi abilitati in un'organizzazione: Cloud Asset Viewer (roles/cloudasset.viewer) nell'organizzazione

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Potresti anche essere in grado di ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Prima di iniziare

Puoi elencare i progetti in cui è archiviata almeno un'immagine in Container Registry. Puoi quindi concentrarti sulla configurazione di altri progetti per l'hosting di richieste gcr.io in Artifact Registry utilizzando le istruzioni in questo documento.

Esegui questo comando per trovare qualsiasi utilizzo di Container Registry nella tua organizzazione Google Cloud.

  gcloud containers list-gcr-usage \
      --organization=ORGANIZATION

Sostituisci ORGANIZATION con il tuo ID organizzazione Google Cloud.

Puoi anche elencare l'utilizzo di Container Registry per il tuo progetto o la tua cartella. Per saperne di più sull'utilizzo di Container Registry, consulta Controllare l'utilizzo di Container Registry.

Abilita l'API

Abilita l'API Artifact Registry in modo che le richieste al dominio gcr.io vengano gestite automaticamente da Artifact Registry quando viene applicato l'hosting automatico di gcr.io.

Esegui questo comando:

gcloud services enable \
    artifactregistry.googleapis.com

Se normalmente posizioni l'API Container Registry in un perimetro di servizio Controlli di servizio VPC, assicurati di collocare anche l'API Artifact Registry in questo perimetro. Per le istruzioni, consulta Protezione dei repository in un perimetro di servizio.

Concedi le autorizzazioni ai repository

Container Registry utilizza i ruoli di Cloud Storage per controllare l'accesso. Artifact Registry dispone di ruoli IAM propri e questi ruoli separano i ruoli di lettura, scrittura e amministrazione del repository in modo più chiaro rispetto a Container Registry.

Per mappare rapidamente le autorizzazioni esistenti concesse sui bucket di archiviazione ai ruoli di Artifact Registry suggeriti, utilizza lo strumento di mappatura dei ruoli.

In alternativa, puoi visualizzare un elenco di entità con accesso ai bucket di archiviazione utilizzando la console Google Cloud.

Nella console Google Cloud, vai alla pagina Bucket di Cloud Storage.

Vai a Bucket
Fai clic sul bucket di archiviazione relativo all'host del registro che vuoi visualizzare. Nei nomi dei bucket, PROJECT-ID è l'ID progetto Google Cloud.
- gcr.io: artifacts.PROJECT-ID.appspot.com
- asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
- eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
- us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
Fai clic sulla scheda Autorizzazioni.
Nella scheda Autorizzazioni, fai clic sulla scheda secondaria Visualizza per ruolo.
Espandi un ruolo per visualizzare le entità che lo hanno.

L'elenco include i ruoli IAM concessi direttamente nel bucket e i ruoli ereditati dal progetto padre. In base al ruolo, puoi scegliere il ruolo Artifact Registry più appropriato da concedere.

Cloud Storage e ruoli di base

Concedi agli utenti e agli account di servizio che attualmente accedono a Container Registry con accesso ai repository Artifact Registry. Per i ruoli Cloud Storage ereditati dal progetto padre, devi verificare che l'entità utilizzi attualmente Container Registry. Alcune entità potrebbero accedere solo ad altri bucket Cloud Storage non correlati a Container Registry.

I ruoli di base Proprietario, Editor e Visualizzatore esistenti prima di IAM hanno accesso limitato ai bucket di archiviazione. Non offrono intrinsecamente tutti gli accessi alle risorse Cloud Storage implicati dal loro nome, né forniscono autorizzazioni aggiuntive per altri servizi Google Cloud. Verifica quali utenti e account di servizio richiedono l'accesso ad Artifact Registry e utilizza la tabella di mappatura dei ruoli per concedere i ruoli appropriati se l'accesso ad Artifact Registry è appropriato.

La seguente tabella mappa i ruoli Artifact Registry in base alle autorizzazioni concesse dai ruoli Cloud Storage predefiniti per l'accesso a Container Registry.

Accesso richiesto	Ruolo attuale	Ruolo Artifact Registry	Dove concedere il ruolo
Estrai solo immagini (sola lettura)	Visualizzatore oggetti Storage (`roles/storage.objectViewer`)	Lettore Artifact Registry (`roles/artifactregistry.reader)`	Repository Artifact Registry o progetto Google Cloud
Esegui il push e il pull delle immagini (lettura e scrittura) Elimina immagini	Writer bucket legacy di Storage (`roles/storage.legacyBucketWriter`)	Amministratore repository Artifact Registry (`roles/artifactregistry.repoAdmin)`	Repository Artifact Registry o progetto Google Cloud
Crea un repository gcr.io in Artifact Registry la prima volta che viene eseguito il push di un'immagine a un nome host gcr.io in un progetto.	Amministratore Storage (`roles/storage.admin`)	Amministratore repository Create-on-push di Artifact Registry `(roles/artifactregistry.createOnPushRepoAdmin)`	Progetto Google Cloud
Creare, gestire ed eliminare i repository	Amministratore Storage (`roles/storage.admin`)	Amministratore di Artifact Registry `(roles/artifactregistry.Admin)`	Progetto Google Cloud

Ruoli dell'agente di servizio ereditati dal progetto

Gli account di servizio predefiniti per i servizi Google Cloud hanno i propri ruoli concessi a livello di progetto. Ad esempio, l'agente di servizio per Cloud Run ha il ruolo Agente di servizio Cloud Run.

Nella maggior parte dei casi, questi ruoli degli agenti di servizio contengono autorizzazioni predefinite equivalenti per Container Registry e Artifact Registry e non è necessario apportare ulteriori modifiche se esegui Artifact Registry nello stesso progetto del servizio Container Registry esistente.

Per maggiori dettagli sulle autorizzazioni nei ruoli di agente di servizio, consulta la documentazione sul ruolo di agente di servizio.

Ruoli personalizzati

Utilizza la tabella di mappatura dei ruoli per decidere il ruolo da concedere a utenti o account di servizio in base al livello di accesso richiesto.

Per istruzioni sulla concessione dei ruoli Artifact Registry, consulta Configurare ruoli e autorizzazioni.

Configurazione del bucket di archiviazione

Quando crei un repository in Artifact Registry, Artifact Registry non crea bucket Cloud Storage corrispondenti nel tuo progetto. Se utilizzi l'automazione per Container Registry che interagisce direttamente con i bucket di archiviazione, devi aggiornarla per apportare le modifiche corrispondenti al repository Artifact Registry.

Ad esempio, se concedi in modo programmatico le autorizzazioni Cloud Storage sui bucket di archiviazione per Container Registry, devi aggiornare l'automazione per concedere le autorizzazioni ad Artifact Registry sui repository Artifact Registry che ospitano immagini per il dominio gcr.io.

In Artifact Registry, imposti il metodo di crittografia per i dati archiviati in un repository anziché in un bucket di archiviazione. L'hosting automatico di gcr.io su Artifact Registry crea gcr.io repository criptati con chiavi di crittografia gestite da Google. Se vuoi utilizzare chiavi di crittografia gestite dal cliente (CMEK), devi creare personalmente i repository gcr.io e specificare CMEK come metodo di crittografia al momento della creazione.

Per creare manualmente un repository gcr.io:

Se utilizzi CMEK, crea la chiave che utilizzerai con questo repository e concedi le autorizzazioni per utilizzarla. Vedi Abilitazione delle chiavi di crittografia gestite dal cliente.
Aggiungi il repository.
Console
1. Apri la pagina Repositories nella console Google Cloud.
  
  Apri la pagina Repository
2. Fai clic su Crea repository.
3. Specifica il nome del repository.
  
  Nome host di Container Registry Nome repository Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
4. Specifica Docker come formato del repository.
5. In Tipo di località, specifica più regioni per il repository:
  
  Nome host di Container Registry Posizione del repository Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
6. Aggiungi una descrizione per il repository. Non includere dati sensibili, poiché le descrizioni dei repository non sono criptate.
7. Nella sezione Crittografia, scegli il meccanismo di crittografia per il repository.
  - Chiave gestita da Google: cripta i contenuti del repository con una chiave di crittografia gestita da Google.
  - Chiave gestita dal cliente: cripta i contenuti del repository con una chiave che puoi controllare tramite Cloud Key Management Service. Per le istruzioni di configurazione delle chiavi, consulta Configurare CMEK per i repository.
8. Fai clic su Crea.
gcloud
Esegui questo comando per creare un nuovo repository.
```
gcloud artifacts repositories create REPOSITORY \
    --repository-format=docker \
    --location=LOCATION \
    --description=DESCRIPTION \
    --kms-key=KMS-KEY
```
Sostituisci i seguenti valori:
- REPOSITORY è il nome del repository.
  
  Nome host di Container Registry Nome repository Artifact Registry
  
  gcr.io gcr.io
  
  asia.gcr.io asia.gcr.io
  
  eu.gcr.io eu.gcr.io
  
  us.gcr.io us.gcr.io
- LOCATION è la località a più regioni per il repository:
  
  Nome host di Container Registry Posizione del repository Artifact Registry
  
  gcr.io us
  
  asia.gcr.io asia
  
  eu.gcr.io europe
  
  us.gcr.io us
- DESCRIPTION è una descrizione del repository. Non includere dati sensibili, poiché le descrizioni dei repository non sono criptate.
- KMS-KEY è il percorso completo della chiave di crittografia di Cloud KMS, se utilizzi una chiave di crittografia gestita dal cliente per criptare i contenuti del repository. Il percorso ha il seguente formato:
  projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
  Sostituisci i seguenti valori:
  - KMS-PROJECT è il progetto in cui è archiviata la chiave.
  - KMS-LOCATION è la posizione della chiave.
  - KEY-RING è il nome del keyring.
  - KEY è il nome della chiave.
Puoi confermare che il repository sia stato creato elencando i tuoi repository con il seguente comando:
```
gcloud artifacts repositories list
```

Nome host di Container Registry	Nome repository Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome host di Container Registry	Posizione del repository Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Nome host di Container Registry	Nome repository Artifact Registry
gcr.io	gcr.io
asia.gcr.io	asia.gcr.io
eu.gcr.io	eu.gcr.io
us.gcr.io	us.gcr.io

Nome host di Container Registry	Posizione del repository Artifact Registry
gcr.io	us
asia.gcr.io	asia
eu.gcr.io	europe
us.gcr.io	us

Passaggi successivi

Configura il supporto per i domini gcr.io in un progetto di test per verificare che l'automazione e l'integrazione esistenti con servizi come Cloud Build, Google Kubernetes Engine o Cloud Functions funzionino come previsto.