Panoramica di IAM

In questa pagina viene descritto il funzionamento del sistema IAM (Identity and Access Management) di Google Cloud e come utilizzarlo per gestire l'accesso in Google Cloud.

IAM consente di concedere un accesso granulare a risorse Google Cloud specifiche, oltre a impedire l'accesso ad altre risorse. IAM consente di adottare il principio di sicurezza del privilegio minimo, secondo il quale nessuno dovrebbe avere più autorizzazioni di quelle di cui ha effettivamente bisogno.

Come funziona IAM

Con IAM, puoi gestire il controllo dell'accesso definendo chi (identità) ha quale accesso (ruolo) per quale risorsa. Ad esempio, le istanze di macchine virtuali di Compute Engine, i cluster Google Kubernetes Engine (GKE) e i bucket Cloud Storage sono tutte risorse di Google Cloud. Anche le organizzazioni, le cartelle e i progetti che utilizzi per organizzare le risorse sono risorse.

In IAM, l'autorizzazione ad accedere a una risorsa non viene concessa direttamente all'utente finale. Le autorizzazioni vengono invece raggruppate in ruoli e i ruoli vengono concessi alle entità autenticate. In passato, IAM faceva spesso riferimento alle entità come membri. Alcune API utilizzano ancora questo termine.)

Un criterio di autorizzazione, noto anche come criterio IAM, definisce e applica i ruoli concessi alle entità. Ogni criterio di autorizzazione è associato a una risorsa. Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla il criterio di autorizzazione della risorsa per determinare se l'azione è consentita.

Il seguente diagramma illustra la gestione delle autorizzazioni in IAM.

Un criterio di autorizzazione con due associazioni di ruoli. Le associazioni di ruoli associano membri specifici a ruoli specifici.

Questo modello per la gestione degli accessi si compone di tre parti principali:

  • Entità. Un'entità può essere un Account Google (per gli utenti finali), un account di servizio (per applicazioni e carichi di lavoro di computing), un gruppo Google, un account Google Workspace o un dominio Cloud Identity che può accedere a una risorsa. Ogni entità ha il proprio identificatore, che in genere è un indirizzo email.
  • Ruolo. Un ruolo è un insieme di autorizzazioni. Le autorizzazioni determinano quali operazioni sono consentite su una risorsa. Se concedi un ruolo a un'entità, concedi tutte le autorizzazioni incluse nel ruolo.
  • Norme. Il criterio di autorizzazione è una raccolta di associazioni di ruoli che associano una o più entità a singoli ruoli. Quando vuoi definire chi (entità) ha un determinato tipo di accesso (ruolo) su una risorsa, crea un criterio di autorizzazione e lo colleghi alla risorsa.

Nel diagramma precedente, ad esempio, il criterio di autorizzazione associa le entità, come user@example.com, ai ruoli come il ruolo Amministratore App Engine (roles/appengine.appAdmin). Se il criterio di autorizzazione è associato a un progetto, le entità ottengono i ruoli specificati all'interno del progetto.

Il resto della pagina descrive questi concetti in modo più dettagliato.

In IAM, concedi l'accesso alle entità. Le entità possono essere di questi tipi:

  • Account Google
  • Account di servizio
  • Gruppo Google
  • Account Google Workspace
  • Dominio Cloud Identity
  • Tutti gli utenti autenticati
  • Tutti gli utenti

Account Google

Un Account Google rappresenta uno sviluppatore, un amministratore o un'altra persona che interagisce con Google Cloud. Qualsiasi indirizzo email associato a un Account Google può essere un'identità, incluso gmail.com o altri domini. I nuovi utenti possono creare un Account Google tramite la pagina di registrazione di un Account Google.

Account di servizio

Un account di servizio è un account per un'applicazione o un carico di lavoro di computing, invece di un singolo utente finale. Quando esegui codice ospitato su Google Cloud, il codice viene eseguito con l'account specificato. Puoi creare tutti gli account di servizio necessari per rappresentare i diversi componenti logici dell'applicazione. Per ulteriori informazioni sull'uso di un account di servizio per autenticare l'applicazione, consulta Account di servizio.

Gruppo Google

Un gruppo Google è una raccolta denominata di Account Google e account di servizio. Ogni gruppo Google ha un indirizzo email univoco associato al gruppo. Puoi trovare l'indirizzo email associato a un gruppo Google facendo clic su Informazioni nella home page di qualsiasi gruppo Google. Per ulteriori informazioni su Google Gruppi, vedi la home page di Google Gruppi.

Google Gruppi consente di applicare facilmente i controlli di accesso a un insieme di utenti. Puoi modificare e concedere i controlli di accesso a un intero gruppo contemporaneamente anziché concedere o modificare uno alla volta i controlli di accesso per singoli utenti o account di servizio. Puoi anche aggiungere e rimuovere facilmente entità da un gruppo Google anziché aggiornare un criterio di autorizzazione per aggiungere o rimuovere utenti.

I gruppi Google non dispongono di credenziali di accesso e non puoi utilizzare Google Gruppi per stabilire l'identità e richiedere l'accesso a una risorsa.

Account Google Workspace

Un account Google Workspace rappresenta un gruppo virtuale di tutti gli Account Google che contiene. Gli account Google Workspace sono associati al nome di dominio internet della tua organizzazione, ad esempio example.com. Quando crei un Account Google per un nuovo utente, ad esempio username@example.com, questo Account Google viene aggiunto al gruppo virtuale del tuo account Google Workspace.

Come Google Gruppi, gli account Google Workspace non possono essere utilizzati per stabilire l'identità, ma consentono una pratica gestione delle autorizzazioni.

Dominio Cloud Identity

Un dominio Cloud Identity è simile a un account Google Workspace, perché rappresenta un gruppo virtuale di tutti gli Account Google di un'organizzazione. Tuttavia, gli utenti del dominio Cloud Identity non hanno accesso alle applicazioni e alle funzionalità di Google Workspace. Per maggiori dettagli, consulta Informazioni su Cloud Identity.

Tutti gli utenti autenticati

Il valore allAuthenticatedUsers è un identificatore speciale che rappresenta tutti gli account di servizio e tutti gli utenti su internet che si sono autenticati con un Account Google. Questo identificatore include gli account che non sono collegati a un account Google Workspace o a un dominio Cloud Identity, ad esempio gli account Gmail personali. Gli utenti non autenticati, come i visitatori anonimi, non sono inclusi.

Questo tipo di entità non include le identità che provengono da provider di identità (IdP) esterni. Se utilizzi la federazione delle identità per la forza lavoro o la federazione delle identità per i carichi di lavoro, non utilizzare allAuthenticatedUsers. Utilizza invece uno dei seguenti:

Alcuni tipi di risorse non supportano questo tipo di entità.

Tutti gli utenti

Il valore allUsers è un identificatore speciale che rappresenta chiunque si trovi su internet, inclusi gli utenti autenticati e non autenticati.

Alcuni tipi di risorse non supportano questo tipo di entità.

Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla il criterio di autorizzazione della risorsa per determinare se l'azione è consentita.

Questa sezione descrive le entità e i concetti coinvolti nel processo di autorizzazione.

Risorsa

Se un utente ha bisogno di accedere a una specifica risorsa Google Cloud, puoi concedergli un ruolo per quella risorsa. Alcuni esempi di risorse sono progetti, istanze di Compute Engine e bucket di Cloud Storage.

Alcuni servizi supportano la concessione di autorizzazioni IAM a un livello di granularità superiore rispetto al livello di progetto. Ad esempio, puoi concedere il ruolo Amministratore Storage (roles/storage.admin) a un utente per un particolare bucket Cloud Storage oppure il ruolo Amministratore istanze Compute (roles/compute.instanceAdmin) a un utente per una specifica istanza di Compute Engine.

In altri casi, puoi concedere autorizzazioni IAM a livello di progetto. Le autorizzazioni vengono quindi ereditate da tutte le risorse all'interno del progetto. Ad esempio, per concedere l'accesso a tutti i bucket Cloud Storage in un progetto, concedi l'accesso al progetto anziché a ogni singolo bucket. In alternativa, per concedere l'accesso a tutte le istanze di Compute Engine in un progetto, concedi l'accesso al progetto anziché a ogni singola istanza.

Per informazioni su quali ruoli possono essere concessi e per determinate risorse, consulta Informazioni sui ruoli e fai riferimento alla colonna Risorsa più bassa per un determinato ruolo.

Autorizzazioni

Le autorizzazioni determinano quali operazioni sono consentite su una risorsa. Nel mondo IAM, le autorizzazioni sono rappresentate nel formato service.resource.verb, ad esempio pubsub.subscriptions.consume.

Le autorizzazioni spesso corrispondono uno a uno con i metodi dell'API REST. Ciò significa che a ogni servizio Google Cloud è associato un insieme di autorizzazioni per ogni metodo dell'API REST esposto. Il chiamante di quel metodo deve avere queste autorizzazioni per chiamare quel metodo. Ad esempio, se utilizzi Pub/Sub e devi chiamare il metodo topics.publish(), devi disporre dell'autorizzazione pubsub.topics.publish per quell'argomento.

Non concedi le autorizzazioni direttamente agli utenti. Puoi invece identificare i ruoli che contengono le autorizzazioni appropriate e assegnare questi ruoli all'utente. Per un elenco di tutte le autorizzazioni disponibili e i ruoli che le contengono, consulta la documentazione di riferimento sulle autorizzazioni.

Ruoli

Un ruolo è una raccolta di autorizzazioni. Non puoi concedere un'autorizzazione direttamente all'utente. ma concedi loro un ruolo. Quando concedi un ruolo a un utente, gli concedi tutte le autorizzazioni incluse nel ruolo.

Autorizzazione per la mappatura dei ruoli.

In IAM esistono diversi tipi di ruoli:

  • Ruoli di base: ruoli disponibili cronologicamente nella console Google Cloud. Questi ruoli sono Proprietario, Editor e Visualizzatore.

  • Ruoli predefiniti: ruoli che offrono controllo dell'accesso più granulare rispetto ai ruoli di base. Ad esempio, il ruolo predefinito Publisher Pub/Sub (roles/pubsub.publisher) fornisce l'accesso per pubblicare solo messaggi in un argomento Pub/Sub.

  • Ruoli personalizzati: ruoli che crei per personalizzare le autorizzazioni in base alle esigenze della tua organizzazione quando i ruoli predefiniti non soddisfano le tue esigenze.

Per ulteriori informazioni sui ruoli, consulta le seguenti risorse:

Criterio di autorizzazione

Puoi concedere i ruoli agli utenti creando un criterio di autorizzazione, ovvero una raccolta di istruzioni che definiscono chi deve disporre di un determinato tipo di accesso. Un criterio di autorizzazione è collegato a una risorsa e viene utilizzato per applicare controllo dell'accesso ogni volta che si accede alla risorsa.

criterio IAM.

Un criterio di autorizzazione è costituito da un elenco di associazioni di ruoli. Un'associazione di ruolo collega un elenco di entità a un ruolo

  • role: il ruolo che vuoi concedere all'entità. role viene specificato nel formato roles/service.roleName. Ad esempio, Cloud Storage fornisce i ruoli roles/storage.objectAdmin, roles/storage.objectCreator e roles/storage.objectViewer, tra gli altri.

  • members: un elenco di una o più entità come descritto nella sezione Concetti relativi all'identità di questo documento. Ogni tipo di entità è identificato con un prefisso, ad esempio un Account Google (user:), un account di servizio (serviceAccount:), un gruppo Google (group:) o un account Google Workspace o un dominio Cloud Identity (domain:). Nel seguente snippet di codice di esempio, il ruolo storage.objectAdmin viene concesso alle seguenti entità utilizzando il prefisso appropriato: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. Il ruolo objectViewer viene concesso a user:maria@example.com.

Il seguente snippet di codice mostra la struttura di un criterio di autorizzazione.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

API IAM e criteri

IAM mette a disposizione una serie di metodi che puoi utilizzare per creare e gestire i criteri di autorizzazione nelle risorse Google Cloud. Questi metodi sono esposti dai servizi che supportano IAM. Ad esempio, i metodi IAM sono esposti dalle API Resource Manager, Pub/Sub e Cloud Life Sciences, solo per citarne alcuni.

I metodi IAM sono:

  • setIamPolicy(): imposta i criteri di autorizzazione sulle tue risorse.
  • getIamPolicy(): ottiene un criterio di autorizzazione impostato in precedenza.
  • testIamPermissions(): verifica se il chiamante dispone delle autorizzazioni specificate per una risorsa.

Puoi trovare gli argomenti di riferimento delle API per questi metodi nella documentazione di ciascun servizio che supporta IAM.

Gerarchia delle risorse

Le risorse Google Cloud sono organizzate in modo gerarchico:

  • L'organizzazione è il nodo radice della gerarchia.
  • Le cartelle sono secondarie dell'organizzazione o di un'altra cartella.
  • I progetti sono elementi secondari dell'organizzazione o di una cartella.
  • Le risorse per ogni servizio sono discendenti dei progetti.

Ogni risorsa ha un solo elemento padre. Per ulteriori informazioni, consulta la gerarchia delle risorse di Resource Manager.

Il diagramma seguente è un esempio di gerarchia di risorse Google Cloud.

Gerarchia per le risorse IAM.

Puoi impostare un criterio di autorizzazione a qualsiasi livello nella gerarchia delle risorse: a livello di organizzazione, di cartella, di progetto o di risorsa. Le risorse ereditano i criteri di autorizzazione di tutte le risorse padre. Il criterio di autorizzazione effettiva per una risorsa è l'unione del criterio di autorizzazione impostato su quella risorsa e i criteri di autorizzazione ereditati dai livelli superiori nella gerarchia.

Questa ereditarietà dei criteri è transitiva. In altre parole, le risorse ereditano i criteri di autorizzazione dal progetto, che ereditano i criteri di autorizzazione dalle cartelle, che ereditano i criteri di autorizzazione dall'organizzazione. Di conseguenza, i criteri di autorizzazione a livello di organizzazione si applicano anche a livello di risorsa.

Ad esempio, nel diagramma precedente, topic_a è una risorsa Pub/Sub che si trova all'interno del progetto example-prod. Se concedi il ruolo Editor a micah@example.com per example-prod e il ruolo Editore a song@example.com per topic_a, concedi di fatto il ruolo Editor topic_a a micah@example.com e il ruolo Editore a song@example.com.

I criteri di autorizzazione per le risorse figlio ereditano dai criteri di autorizzazione per le risorse padre. Ad esempio, se concedi il ruolo Editor a un utente per un progetto e lo concedi allo stesso utente per una risorsa figlio, l'utente continua a disporre della concessione del ruolo Editor per la risorsa figlio. Se modifichi la gerarchia delle risorse, cambia anche l'ereditarietà dei criteri. Ad esempio, lo spostamento di un progetto in un'organizzazione fa sì che il progetto erediti le impostazioni del criterio di autorizzazione dell'organizzazione.

Supporto IAM per i servizi Google Cloud

Con IAM, ogni metodo API in tutti i servizi Google Cloud viene controllato per garantire che l'account che effettua la richiesta API disponga dell'autorizzazione appropriata per utilizzare la risorsa.

I servizi Google Cloud offrono ruoli predefiniti che fornisconocontrollo dell'accessoo granulare. Ad esempio, Compute Engine offre ruoli come Amministratore istanze Compute e Amministratore rete Compute, mentre App Engine offre ruoli quali Amministratore App Engine e Amministratore servizi App Engine.

I ruoli predefiniti sono disponibili per la maggior parte dei servizi Google Cloud. Per maggiori dettagli, consulta l'elenco di tutti i ruoli predefiniti. Se hai bisogno di un controllo ancora maggiore sulle autorizzazioni, valuta la possibilità di creare un ruolo personalizzato.

Puoi concedere agli utenti determinati ruoli per accedere alle risorse a una granularità più precisa rispetto al livello di progetto. Puoi ad esempio creare un criterio di autorizzazione che assegna a un utente il ruolo di Sottoscrittore per un particolare argomento Pub/Sub. L'elenco di tutti i ruoli predefiniti mostra il tipo di risorsa di livello più basso (o più granulare) che accetta ciascun ruolo.

Modello di coerenza per l'API IAM

L'API IAM è finalmente coerente. In altre parole, se scrivi dati con l'API IAM e li leggi immediatamente, l'operazione di lettura potrebbe restituire una versione precedente dei dati. Inoltre, le modifiche apportate potrebbero richiedere tempo per influire sui controlli di accesso.

Questo modello di coerenza influisce sul funzionamento dell'API IAM. Ad esempio, se crei un account di servizio e fai riferimento immediatamente a quell'account in un'altra richiesta, l'API IAM potrebbe indicare che non è stato possibile trovare l'account di servizio. Questo comportamento si verifica perché le operazioni sono alla fine coerenti. Può essere necessario del tempo prima che il nuovo account di servizio diventi visibile per le richieste di lettura.

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia gratuitamente