Panoramica di IAM

Questa pagina descrive come funziona il sistema di Identity and Access Management (IAM) di Google Cloud e come puoi utilizzarlo per gestire l'accesso in Google Cloud.

IAM ti consente di concedere l'accesso granulare a determinate risorse Google Cloud e aiuta a impedire l'accesso ad altre risorse. IAM ti consente di adottare il principio di sicurezza del privilegio minimo, che afferma che nessuno dovrebbe disporre di più autorizzazioni di quelle di cui ha effettivamente bisogno.

Come funziona IAM

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

In IAM, l'autorizzazione per 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 si riferiva spesso 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 fornisce un esempio di gestione delle autorizzazioni in IAM.

Un criterio di autorizzazione con due associazioni di ruolo. Le associazioni di ruoli associano entità specifiche a ruoli specifici.

Questo modello per la gestione dell'accesso è composto da tre parti principali:

  • Direttore/preside. Un'entità rappresenta un'identità che può accedere a una risorsa. Ogni entità ha il proprio identificatore.
  • 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 vincolano una o più entità a singoli ruoli. Quando vuoi definire chi (entità) dispone di quale tipo di accesso (ruolo) a una risorsa, crei una policy di autorizzazione e la associ alla risorsa.

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

Il resto della pagina descrive questi concetti in maggiore dettaglio.

In IAM, puoi concedere l'accesso alle entità, che rappresentano un'identità che può accedere a una risorsa. Nel contesto della gestione dell'accesso, gli utenti possono essere di uno dei seguenti tipi:

Per informazioni dettagliate sui formati degli identificatori per ogni tipo di principale, consulta Identificatori principali.

Account Google

Un Account Google rappresenta uno sviluppatore, un amministratore o un'altra persona che interagisce con Google Cloud utilizzando un account creato con Google. Qualsiasi indirizzo email associato a un Account Google può essere utilizzato come principale, inclusi gli indirizzi email gmail.com o gli indirizzi email con altri domini. I nuovi utenti possono creare un Account Google tramite 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 calcolo anziché per un singolo utente finale. Quando esegui un codice ospitato su Google Cloud, specifichi un account di servizio da utilizzare come identità per la tua applicazione. Puoi creare tutti gli account di servizio necessari per rappresentare i vari componenti logici dell'applicazione. Per ulteriori informazioni sull'utilizzo di un account di servizio per autenticare l'applicazione, consulta Account di servizio.

Gruppi 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, visita la home page di Google Gruppi.

I gruppi Google sono un modo comodo per applicare controlli di accesso a un insieme di utenti. Puoi concedere e modificare i controlli di accesso per un intero gruppo contemporaneamente, anziché concederli o modificarli uno alla volta per singoli utenti o account di servizio. Puoi anche aggiungere o rimuovere principali 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 utilizzarli per stabilire l'identità al fine di 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, questo Account Google viene aggiunto al gruppo virtuale per il tuo account Google Workspace.

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

Domini 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.

allAuthenticatedUsers

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 non 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 principale non include le identità federate, che sono gestite da provider di identità esterni (IdP). Se utilizzi la federazione delle identità della forza lavoro o la federazione delle identità per i carichi di lavoro, non utilizzare allAuthenticatedUsers. Utilizza invece una delle seguenti opzioni:

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

allUsers

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à.

Identità federate in un pool di identità della forza lavoro

Un'identità federata in un pool Workload Identity è un'identità utente gestita da un IdP esterno e federata utilizzando la Federazione delle identità per la forza lavoro. Puoi utilizzare un'identità specifica in un pool di identità della forza lavoro oppure puoi utilizzare determinati attributi per specificare un gruppo di identità utente in un pool di identità della forza lavoro. Per informazioni sugli identificatori delle entità per le identità federate, consulta Identificatori delle entità.

Identità federate in un pool di identità per i workload

Un'identità federata in un pool di identità per i carichi di lavoro è un'identità per i carichi di lavoro gestita da un provider di identità esterno e federata utilizzando la federazione delle identità per i carichi di lavoro. Puoi utilizzare un'identità di workload specifica in un pool di identità di workload oppure puoi utilizzare determinati attributi per specificare un gruppo di identità di workload in un pool di identità di workload. Per informazioni sugli identificatori delle entità per le identità federate, consulta Identificatori delle entità.

Pod GKE

I carichi di lavoro in esecuzione su GKE utilizzano Workload Identity Federation for GKE per accedere ai servizi Google Cloud. Per ulteriori informazioni sugli identificatori dei principali per i pod GKE, consulta Fare riferimento alle risorse Kubernetes nei criteri IAM.

Risorsa

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

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

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

Per informazioni sui ruoli che possono essere concessi sulle 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 sotto forma di service.resource.verb, ad esempio pubsub.subscriptions.consume.

Le autorizzazioni spesso corrispondono in modo uno a uno ai metodi dell'API REST. In altre parole, a ogni servizio Google Cloud è associato un insieme di autorizzazioni per ogni metodo dell'API REST che espone. Il chiamante di quel metodo ha bisogno di queste autorizzazioni per chiamarlo. 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. Devi invece identificare i ruoli che contengono le autorizzazioni appropriate e poi assegnarli all' utente. Per un elenco di tutte le autorizzazioni disponibili e dei ruoli che le contengono, consulta il riferimento alle autorizzazioni.

Ruoli

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

Mappatura delle autorizzazioni ai ruoli.

In IAM sono disponibili diversi tipi di ruoli:

  • Ruoli di base: ruoli storicamente disponibili 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) consente di accedere solo alla pubblicazione di messaggi in un argomento Pub/Sub.

  • Ruoli personalizzati: i 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

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

Puoi concedere ruoli agli utenti creando un criterio di autorizzazione, ovvero una raccolta di istruzioni che definisce chi dispone di un determinato tipo di accesso. Un criterio di autorizzazione è associato 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 ruoli associa un elenco di entità a un ruolo.

  • role: il ruolo che vuoi concedere all'entità. role è specificato nella forma di 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 uno o più principali come descritto nella sezione Concetti correlati all'identità di questo documento. Ogni tipo di principale è 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 snippet di codice di esempio, il ruolo storage.objectAdmin viene concesso ai seguenti principali utilizzando il prefisso appropriato: user:my-user@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com e group:my-group@example.com. Il ruolo objectViewer viene concesso a user:my-user@example.com.

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

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

API IAM e dei criteri

IAM fornisce un insieme di metodi che puoi utilizzare per creare e gestire i 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 API Resource Manager, Pub/Sub e Cloud Life Sciences, solo per citarne alcuni.

I metodi IAM sono:

  • setIamPolicy(): imposta i criteri di autorizzazione per le risorse.
  • getIamPolicy(): recupera un criterio di autorizzazione impostato in precedenza.
  • testIamPermissions(): verifica se chi chiama dispone delle autorizzazioni specificate per una risorsa.

Puoi trovare gli argomenti di riferimento dell'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 figli 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 seguente diagramma è un esempio di gerarchia delle 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, di cartella, di progetto o di risorsa. Le risorse ereditano i criteri di autorizzazione di tutte le risorse principali. Il criterio di autorizzazione effettivo per una risorsa è l'unione del criterio di autorizzazione impostato su la risorsa e dei criteri di autorizzazione ereditati dal livello superiore della gerarchia.

Questa eredità dei criteri è transitiva; in altre parole, le risorse ereditano i criteri consenti dal progetto, che ereditano i criteri consenti dalle cartelle, che ereditano i criteri consenti 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 nel progetto example-prod. Di conseguenza, se concedi il ruolo Editor a un utente su example-prod, gli concedi effettivamente il ruolo Editor per topic_a.

I criteri di autorizzazione per le risorse figlio vengono ereditati dai criteri di autorizzazione per le risorse parent. Ad esempio, se concedi il ruolo Editor a un utente per un progetto e il ruolo Visualizzatore allo stesso utente per una risorsa secondaria, l'utente manterrà la concessione del ruolo Editor per la risorsa secondaria. Se modifichi la gerarchia delle risorse, cambia anche l'eredità dei criteri. Ad esempio, se sposti un progetto in un'organizzazione, il progetto eredita i criteri di autorizzazione dell'organizzazione.

Supporto di IAM per i servizi Google Cloud

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

I servizi Google Cloud offrono ruoli predefiniti che forniscono controllo dell'accesso granulare dell'accesso. Ad esempio, Compute Engine offre ruoli come Amministratore istanza Compute e Amministratore rete Compute, mentre Cloud Storage offre ruoli come Amministratore cartella archiviazione e Utente oggetto archiviazione.

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, ti consigliamo di creare un ruolo personalizzato.

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

Modello di coerenza per l'API IAM

L'API IAM è a coerenza finale. 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 del tempo prima di 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 subito riferimento a quell'account di servizio in un'altra richiesta, l'API IAM potrebbe indicare che l'account di servizio non è stato trovato. Questo comportamento si verifica perché le operazioni sono infine coerenti. Potrebbe essere necessario del tempo prima che il nuovo account di servizio diventi visibile alle 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