Panoramica di IAM

Questa pagina descrive il funzionamento del sistema di gestione di identità e accessi (IAM) di Google Cloud e come utilizzarlo per gestire l'accesso in Google Cloud.

IAM consente di concedere l'accesso granulare a specifiche risorse Google Cloud e aiuta a impedire l'accesso ad altre risorse. IAM consente di adottare il principio di sicurezza del privilegio minimo, secondo il quale nessuno deve disporre di più autorizzazioni di quelle di cui ha bisogno.

Come funziona IAM

IAM consente di gestire il controllo dell'accesso definendo chi (identità) dispone di quale accesso (ruolo) per quale risorsa. Ad esempio, le istanze di macchina virtuale 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 tue risorse sono risorse.

In IAM, l'autorizzazione ad accedere a una risorsa non viene concessa direttamente all'utente finale. Le autorizzazioni sono invece raggruppate in ruoli e i ruoli vengono concessi ai principali autenticati. In passato, IAM spesso indicato come entità membri. Alcune API usano ancora questo termine.

Un criterio di autorizzazione, noto anche come criterio IAM, definisce e applica i ruoli che vengono concessi alle entità. Ogni criterio di autorizzazione è associato a una risorsa. Quando un'entità autenticata tenta di accedere a una risorsa, IAM controlla se il criterio di autorizzazione della risorsa determina 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 è composto da tre elementi principali:

  • Entità. Un princip può essere un Account Google (per utenti finali), un account di servizio (per applicazioni e carichi di lavoro di calcolo), un gruppo Google o un account Google Workspace o un dominio Cloud Identity che può accedere a una risorsa. L'identità di un'entità è un indirizzo email associato a un utente, un account di servizio o un gruppo Google oppure un nome di dominio associato a un account Google Workspace o un dominio Cloud Identity.
  • Ruolo. Un ruolo è una raccolta di autorizzazioni. Le autorizzazioni determinano le operazioni consentite in una risorsa. Quando concedi un ruolo a un proprietario, concedi tutte le autorizzazioni che contiene.
  • Norme. Il criterio Consenti è una raccolta di associazioni di ruoli che vincolano una o più entità a singoli ruoli. Quando vuoi definire chi (principal) ha il tipo di accesso (ruolo) di una risorsa, puoi creare un criterio di autorizzazione e collegarla alla risorsa.

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

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

In IAM, puoi concedere l'accesso ai principali. Le entità possono essere dei seguenti 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 qualsiasi altra persona che interagisce con Google Cloud. Qualsiasi indirizzo email associato a un Account Google può essere un'identità, tra cui gmail.com o altri domini. I nuovi utenti possono creare un Account Google visitando la pagina di registrazione dell'Account Google.

Account di servizio

Un account di servizio è un account per un'applicazione o un carico di lavoro di computing anziché per un singolo utente finale. Quando esegui il codice ospitato su Google Cloud, il codice viene eseguito come nell'account specificato. Puoi creare tutti gli account di servizio necessari per rappresentare i diversi componenti logici della tua applicazione. Per ulteriori informazioni sull'utilizzo di un account di servizio nell'applicazione, consulta la guida introduttiva all'autenticazione.

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 sulla home page di qualsiasi gruppo Google. Per ulteriori informazioni su Google Gruppi, consulta la home page di Google Gruppi.

Google Gruppi consente di applicare facilmente i controlli dell'accesso a una raccolta di utenti. Puoi modificare e concedere i controlli di accesso a un intero gruppo contemporaneamente, anziché modificare o controllare i controlli di accesso per singoli utenti o account di servizio. Puoi anche aggiungere facilmente le entità a e rimuovere i principali da un gruppo Google, invece di aggiornare un criterio di autorizzazione per aggiungere o rimuovere utenti.

Google Gruppi non dispone delle credenziali di accesso e non puoi utilizzare Google Gruppi per stabilire l'identità per effettuare una richiesta di 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, tale 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 comoda 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 ulteriori informazioni, 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 hanno eseguito l'autenticazione 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.

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

Tutti gli utenti

Il valore allUsers è un identificatore speciale che rappresenta chiunque 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 verifica 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 risorsa Google Cloud specifica, puoi assegnargli 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 in modo più granulare rispetto al livello di progetto. Ad esempio, puoi concedere il ruolo Amministratore Storage (roles/storage.admin) a un utente per un determinato bucket Cloud Storage oppure concedere il ruolo Amministratore istanze Compute (roles/compute.instanceAdmin) a un utente per una specifica istanza di Compute Engine.

In altri casi, puoi concedere le autorizzazioni IAM a livello di progetto. Le autorizzazioni vengono ereditate da tutte le risorse del progetto. Ad esempio, per concedere l'accesso a tutti i bucket Cloud Storage di un progetto, concedi l'accesso al progetto anziché a ogni singolo bucket. Oppure, 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 sui ruoli che possono essere concessi sulle singole risorse, consulta Informazioni sui ruoli e consulta la colonna Risorsa più bassa per un determinato ruolo.

Autorizzazioni

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

Spesso le autorizzazioni corrispondono a due con i metodi API REST. Ciò significa che ogni servizio Google Cloud ha un set associato di autorizzazioni per ogni metodo API REST che espone. Il chiamante di quel metodo deve avere le autorizzazioni necessarie 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 l'argomento in questione.

Non concedi le autorizzazioni direttamente agli utenti. Identifichi invece i ruoli che contengono le autorizzazioni appropriate e concedi loro tali ruoli all'utente. Per un elenco di tutte le autorizzazioni disponibili e dei ruoli che le contengono, consulta il riferimento sulle autorizzazioni.

Ruoli

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

Autorizzazione per la mappatura dei ruoli.

In IAM esistono diversi tipi di ruoli:

  • Ruoli di base: i ruoli storicamente disponibili in Google Cloud Console. Questi ruoli sono Proprietario, Editor e Visualizzatore.

  • Ruoli predefiniti: ruoli che offrono un 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 solo pubblicare 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:

Consenti criterio

Per assegnare ruoli agli utenti, puoi creare un criterio di autorizzazione, ovvero una raccolta di istruzioni che definisce chi dispone di un determinato tipo di accesso. Un criterio di autorizzazione viene associato a una risorsa e viene usato per applicare il controllo dell'accesso per ogni accesso alla risorsa.

Criterio IAM.

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

  • role: il ruolo che vuoi concedere all'entità. role è 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à in questo documento. Ogni tipo di entità è identificato da 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 esempio di snippet di codice, il ruolo storage.objectAdmin viene concesso ai 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 è stato 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"
      ]
    }
  ]
}

IAM e API di criteri

IAM fornisce un set di metodi che puoi utilizzare per creare e gestire criteri di autorizzazione per le risorse Google Cloud. Questi metodi sono esposti dai servizi che supportano IAM. Ad esempio, i metodi IAM sono esposti dalle risorse Resource Manager, Pub/Sub e Cloud Life Sciences, per citarne solo alcuni.

I metodi IAM sono:

  • setIamPolicy(): imposta i criteri di autorizzazione per le tue risorse.
  • getIamPolicy(): riceve 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 ogni servizio che supporta IAM.

Gerarchia delle risorse

Le risorse Google Cloud sono strutturate in modo gerarchico:

  • L'organizzazione è il nodo radice nella gerarchia.
  • Le cartelle sono elementi secondari dell'organizzazione.
  • I progetti sono elementi secondari dell'organizzazione o di una cartella.
  • Le risorse per ciascun servizio sono discendenti dei progetti.

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

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

Gerarchia per le risorse IAM.

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

L'ereditarietà di questo criterio è transitiva, ovvero le risorse ereditano i criteri dal progetto, che ereditano i criteri di autorizzazione dalle cartelle, che ereditano i criteri di autorizzazione dall'organizzazione. Pertanto, 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 Editor a song@example.com per topic_a, concedi effettivamente il ruolo Editor a topic_ah.@example.com e il ruolo Editor a brano@example.com.

I criteri di autorizzazione per le risorse figlio ereditano i criteri di autorizzazione per le risorse principali. Ad esempio, se concedi il ruolo Editor a un utente per un progetto e concedi il ruolo Visualizzatore allo stesso utente per una risorsa secondaria, l'utente avrà ancora la concessione del ruolo Editor per la risorsa secondaria. Se modifichi la gerarchia delle risorse, cambia anche l'ereditarietà dei criteri. Ad esempio, se sposti un progetto in un'organizzazione, questo erediterà il 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 forniscono un controllo degli accessi granulare. Ad esempio, Compute Engine offre ruoli quali Amministratore istanze Compute e Amministratore rete Compute, mentre App Engine offre ruoli come Amministratore App Engine e Amministratore del servizio App Engine.

Sono disponibili ruoli predefiniti 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 maggiore sulle autorizzazioni, ti consigliamo di creare un ruolo personalizzato.

Puoi concedere agli utenti determinati ruoli per accedere alle risorse con un livello di granularità maggiore rispetto al livello di progetto. Ad esempio, puoi creare un criterio di autorizzazione che concedi all'utente il ruolo Sottoscrittore per un determinato argomento Pub/Sub. L'elenco di tutti i ruoli predefiniti mostra il tipo di risorsa di livello più basso, o granulare, che accetta ciascun ruolo.

Modello di coerenza per l'API IAM

Quando leggi i dati dall'API IAM, ogni lettura è finalmente coerente. In altre parole, se scrivi i dati con l'API IAM e leggi immediatamente i dati, l'operazione di lettura potrebbe restituire una versione precedente dei dati. Dopo un breve ritardo, puoi leggere la nuova versione dei dati. Questo ritardo viene generalmente misurato in secondi, non in minuti.

Al contrario, la scrittura di dati nell'API IAM è coerente in sequenza. In altre parole, le operazioni di scrittura vengono sempre elaborate nell'ordine in cui sono state ricevute.

Questi modelli di coerenza influiscono sul funzionamento dell'API IAM. Ad esempio, se crei un account di servizio e fai subito riferimento all'account di servizio in un'altra richiesta, l'API IAM potrebbe comunicare che non è stato possibile trovare l'account di servizio. Questo comportamento si verifica perché le operazioni di lettura sono coerenti; può essere necessario del tempo prima che il nuovo account di servizio diventi visibile.

Per gestire questo comportamento, l'applicazione può ritentare la richiesta con backoff esponenziale troncato.

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