Panoramica di IAM

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

IAM ti consente di concedere l'accesso granulare a le risorse Google Cloud e contribuisce 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. Per istanze di macchine virtuali Compute Engine, Google Kubernetes Engine (GKE) e bucket Cloud Storage sono tutti dell'accesso a specifiche risorse Google Cloud. Anche le organizzazioni, le cartelle e i progetti che utilizzi per organizzare le risorse sono risorse.

In IAM non è concessa l'autorizzazione per accedere a una risorsa direttamente all'utente finale. Le autorizzazioni vengono invece raggruppate in ruoli vengono concessi ruoli alle entità autenticate. (In passato, IAM spesso chiama le entità membri. alcune API utilizzano ancora questo termine).

Un criterio di autorizzazione, chiamato anche criterio IAM, definisce e consente di applicare in modo forzato i ruoli assegnati a quali entità. Ogni criterio di autorizzazione non è collegato a una risorsa. Quando un'entità autenticata tenta di accedere a un risorsa, IAM controlla il criterio di autorizzazione della risorsa per determinare se l'azione è consentita.

Il seguente diagramma illustra la gestione delle autorizzazioni in o 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:

  • Direttore/preside. Un'entità rappresenta un'identità che può accedere a un risorsa. Ogni entità ha il proprio identificatore.
  • Ruolo. Un ruolo è un insieme di autorizzazioni. Determinazione delle autorizzazioni le operazioni 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à) ha il tipo di accesso (ruolo) a una risorsa, crei di autorizzazione e di collegarlo alla risorsa.

Nel diagramma precedente, ad esempio, il criterio di autorizzazione vincola le entità, come come user@example.com, a ruoli come il ruolo Amministratore App Engine (roles/appengine.appAdmin). Se il criterio di autorizzazione è collegato a un progetto, alle 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à, che rappresentano una che possono accedere a una risorsa. Nel contesto della gestione dell'accesso, gli utenti possono essere di uno dei seguenti tipi:

Per maggiori dettagli sui formati degli identificatori per ciascun tipo di entità, consulta Identificatori entità.

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 è invece un account per un'applicazione o un carico di lavoro di computing di 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. 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 conveniente per applicare controlli di accesso a una raccolta utenti. Puoi modificare e concedere i controlli di accesso a un intero gruppo contemporaneamente anziché concedere o modificare i controlli dell'accesso uno alla volta per i singoli utenti o account di servizio. Puoi anche aggiungere entità o rimuoverle di un gruppo Google anziché aggiornare un criterio di autorizzazione per aggiungere rimuovere gli utenti.

I gruppi Google non hanno credenziali di accesso e non puoi utilizzare Google gruppi per stabilire l'identità ed effettuare una richiesta di accesso a una risorsa.

Account Google Workspace

Un account Google Workspace rappresenta un gruppo virtuale di tutti i servizi Google Gli account che contiene. Gli account Google Workspace sono associati a il 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, che Google L'account viene aggiunto al gruppo virtuale per il tuo account Google Workspace.

Come per i gruppi Google, gli account Google Workspace non possono essere usati per stabilire dell'identità, ma consentono una pratica gestione delle autorizzazioni.

Domini Cloud Identity

Un dominio Cloud Identity è come 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, vedi 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. Utenti non autenticati, ad esempio utenti anonimi visitatori, non sono inclusi.

Questo tipo di entità non include identità federate, che sono gestite o provider di identità esterni. Se utilizzi Federazione delle identità per la forza lavoro o Federazione delle identità per i carichi di lavoro non usare 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 risorsa non supportano questo tipo di entità.

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

Un'identità federata in un pool di identità della forza lavoro è un'identità utente che viene gestiti da un IdP esterno e federato utilizzando Federazione delle identità per la forza lavoro. Puoi utilizzare un'identità specifica in un forza lavoro oppure puoi usare determinati attributi per specificare un gruppo e le identità degli utenti in un pool di identità della forza lavoro. Per informazioni sugli identificatori principali per le identità federate, consulta Identificatori principali.

Identità federate in un pool di identità per i carichi di lavoro

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 carico di lavoro specifica in un pool di identità di carico di lavoro oppure puoi utilizzare determinati attributi per specificare un gruppo di identità di carico di lavoro in un pool di identità di carico di lavoro. Per informazioni sugli identificatori principali per le identità federate, consulta Identificatori principali.

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 projects, istanze di 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 istanza 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 in 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 one-to-one all'API REST di machine learning. Ciò significa che a ogni servizio Google Cloud è associato un insieme autorizzazioni per ogni metodo dell'API REST che espone. Il chiamante del metodo necessita di queste autorizzazioni per chiamare questo metodo. Ad esempio, se utilizzi Pub/Sub e devi chiamare il metodo topics.publish(), devi disponi dell'autorizzazione pubsub.topics.publish per quell'argomento.

Non concedi le autorizzazioni direttamente agli utenti, Devi identificare i ruoli che contengono le autorizzazioni appropriate e poi concedere questi ruoli utente. Si tratta di un elenco di tutte le autorizzazioni disponibili e dei ruoli consulta la documentazione di riferimento sulle autorizzazioni.

Ruoli

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

Autorizzazione alla mappatura dei ruoli.

In IAM esistono 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 un controllo dell'accesso più granulare rispetto ai ruoli di base. Ad esempio, il ruolo predefinito Pub/Sub Publisher (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 dei dell'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 un una raccolta di istruzioni che definiscono chi ha un determinato tipo di accesso. Un criterio di autorizzazione è associato a una risorsa e viene utilizzato per applicare il 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 è 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 una o più entità, come descritto in Concetti relativi all'identità in 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 un account Google Cloud o un dominio Cloud Identity (domain:). Nell'esempio seguente snippet di codice, il ruolo storage.objectAdmin viene concesso a quanto segue 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"
      ]
    }
  ]
}

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(): ottiene 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 delle API per questi metodi nella documentazione per ogni 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 elementi figlio 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 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 di autorizzazione 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 nel 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 effettivamente il ruolo Editor per example-prod 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 e le risorse principali. 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'ereditarietà dei criteri. Ad esempio, se sposti un progetto in un'organizzazione, il progetto eredita il criterio di autorizzazione dell'organizzazione.

Supporto 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 un controllo 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 Per maggiori dettagli, consulta l'elenco di tutti i ruoli predefiniti. Se hai bisogno un controllo ancora maggiore sulle autorizzazioni, creando 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, per poi leggere immediatamente quei dati, 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 questo 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 service account 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