Identity and Access Management

Utilizzo

Questa pagina fornisce una panoramica di Identity and Access Management (IAM) e del suo utilizzo per controllare l'accesso alle risorse bucket, cartelle gestite e oggetti in Cloud Storage.

Panoramica

IAM ti consente di controllare chi ha accesso alle risorse nel tuo Google Cloud progetto. Le risorse includono i bucket Cloud Storage, le cartelle gestite all'interno dei bucket e gli oggetti archiviati nei bucket, nonché altre Google Cloud entità come le istanze di Compute Engine.

Le entità sono il "chi" di IAM. Le entità possono essere singoli utenti, gruppi, domini o persino il pubblico nel suo complesso. Alle entità vengono concessi ruoli, che consentono loro di eseguire azioni in Cloud Storage e in modo più generale. Google Cloud Ogni ruolo è una raccolta di una o più autorizzazioni. Le autorizzazioni sono le unità di base di IAM: ogni autorizzazione consente di eseguire una determinata azione.

Ad esempio, l'autorizzazione storage.objects.create consente di creare oggetti. Questa autorizzazione è disponibile in ruoli come Creatore oggetti Storage (roles/storage.objectCreator), che concede le autorizzazioni utili per creare oggetti in un bucket, e Amministratore oggetti Storage (roles/storage.objectAdmin), che concede un'ampia gamma di autorizzazioni per lavorare con gli oggetti.

La raccolta di ruoli IAM impostati su una risorsa è chiamata criterio IAM. L'accesso concesso da questi ruoli si applica sia alla risorsa su cui è impostato il criterio sia a tutte le risorse contenute in quella risorsa. Ad esempio, puoi impostare un criterio IAM su un bucket che concede a un utente il controllo amministrativo del bucket e dei relativi oggetti. Puoi anche impostare un criterio IAM sull'intero progetto che consente a un altro utente di visualizzare gli oggetti in qualsiasi bucket all'interno del progetto.

Puoi anche utilizzare i criteri di negazione IAM per negare l'accesso alle risorse. Quando un criterio di negazione è collegato a una risorsa, l'entità nel criterio non può utilizzare l'autorizzazione specificata per accedere alla risorsa o a qualsiasi sotto-risorsa al suo interno, indipendentemente dai ruoli concessi. I criteri di negazione sostituiscono tutti i criteri di autorizzazione IAM.

Autorizzazioni

Le autorizzazioni consentono alle entità di eseguire azioni specifiche su bucket, cartelle gestite o oggetti in Cloud Storage. Ad esempio, l'autorizzazione storage.buckets.list consente a un'entità di elencare i bucket nel progetto. Non concedi direttamente le autorizzazioni alle entità, ma concedi i ruoli, che contengono una o più autorizzazioni.

Per un elenco di riferimento delle autorizzazioni IAM che si applicano a Cloud Storage, consulta Autorizzazioni IAM per Cloud Storage.

Ruoli

I ruoli sono un insieme di una o più autorizzazioni. Ad esempio, il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) contiene le autorizzazioni storage.objects.get e storage.objects.list. Concedi i ruoli alle entità, che consentono loro di eseguire azioni sui bucket, sulle cartelle gestite e sugli oggetti nel progetto.

Per un elenco di riferimento dei ruoli IAM che si applicano a Cloud Storage, consulta Ruoli IAM per Cloud Storage.

Concessione di ruoli a livello di progetto, di bucket o di cartella gestita

Puoi concedere i ruoli alle entità a livello di progetto, di bucket o di cartella gestita. Le autorizzazioni concesse da questi ruoli si applicano in modo additivo a tutta la gerarchia delle risorse. Puoi concedere i ruoli a diversi livelli della gerarchia delle risorse per una maggiore granularità nel modello di autorizzazioni.

Ad esempio, supponiamo che tu voglia concedere a un utente l'autorizzazione a leggere gli oggetti in qualsiasi bucket all'interno di un progetto, ma a creare oggetti solo nel bucket A. Per farlo, puoi assegnare all'utente il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) per il progetto, che consente all'utente di leggere qualsiasi oggetto archiviato in qualsiasi bucket all'interno del progetto, e il ruolo Creatore oggetti Storage (roles/storage.objectCreator) per il bucket A, che consente all'utente di creare oggetti solo in quel bucket.

Alcuni ruoli possono essere utilizzati a tutti i livelli della gerarchia delle risorse. Se utilizzati a livello di progetto, le autorizzazioni che contengono si applicano a tutti i bucket, le cartelle e gli oggetti del progetto. Se utilizzati a livello di bucket, le autorizzazioni si applicano solo a un bucket specifico e alle cartelle e agli oggetti al suo interno. Esempi di questi ruoli sono il ruolo Amministratore Storage (roles/storage.admin), il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) e il ruolo Creatore oggetti Storage (roles/storage.objectCreator).

Alcuni ruoli possono essere applicati solo a un livello. Ad esempio, puoi applicare il ruolo Proprietario oggetti Storage legacy (roles/storage.legacyObjectOwner) solo a livello di bucket o di cartella gestita. I ruoli IAM che consentono di controllare i criteri di negazione IAM possono essere applicati solo a livello di organizzazione.

Relazione con gli ACL

Oltre a IAM, i bucket e gli oggetti possono utilizzare un sistema di controllo dell'accesso legacy chiamato elenchi di controllo dell'accesso (ACL) se la funzionalità di accesso uniforme a livello di bucket non è abilitata per il bucket. In genere, dovresti evitare di utilizzare gli ACL e abilitare l'accesso uniforme a livello di bucket per il bucket. Questa sezione illustra cosa devi tenere presente se consenti l'utilizzo degli ACL per un bucket e gli oggetti al suo interno.

I ruoli IAM Bucket legacy funzionano in tandem con gli ACL dei bucket: quando aggiungi o rimuovi un ruolo Bucket legacy, gli ACL associati al bucket riflettono le modifiche. Allo stesso modo, la modifica di un ACL specifico del bucket aggiorna il ruolo IAM Bucket legacy corrispondente per il bucket.

Ruolo Bucket legacy ACL equivalente
Lettore bucket legacy Storage (roles/storage.legacyBucketReader) Lettore bucket
Scrittore bucket legacy Storage (roles/storage.legacyBucketWriter) Scrittore bucket
Proprietario bucket legacy Storage (roles/storage.legacyBucketOwner) Proprietario bucket

Tutti gli altri ruoli IAM a livello di bucket, inclusi i ruoli IAM Oggetto legacy, funzionano indipendentemente dagli ACL. Allo stesso modo, tutti i ruoli IAM a livello di progetto funzionano indipendentemente dagli ACL. Ad esempio, se assegni a un utente il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer), gli ACL rimangono invariati.

Poiché gli ACL degli oggetti funzionano indipendentemente dai ruoli IAM, non vengono visualizzati nella gerarchia dei criteri IAM. Quando valuti chi ha accesso a uno dei tuoi oggetti, assicurati di controllare gli ACL per l' oggetto, oltre a controllare i criteri IAM a livello di progetto e di bucket.

Criteri di negazione IAM rispetto agli ACL

I criteri di negazione IAM si applicano all'accesso concesso dagli ACL. Ad esempio, se crei un criterio di negazione che nega a un'entità l'autorizzazione storage.objects.get su un progetto, l'entità non può visualizzare gli oggetti nel progetto, anche se le viene concessa l'autorizzazione READER per i singoli oggetti.

Autorizzazione IAM per la modifica degli ACL

Puoi utilizzare IAM per concedere alle entità l'autorizzazione necessaria per modificare gli ACL degli oggetti. Le seguenti autorizzazioni storage.buckets insieme consentono agli utenti di lavorare con gli ACL dei bucket e gli ACL degli oggetti predefiniti: .get, .getIamPolicy, .setIamPolicy, e .update.

Allo stesso modo, le seguenti autorizzazioni storage.objects consentono agli utenti di lavorare con gli ACL degli oggetti: .get, .getIamPolicy, .setIamPolicy, e .update.

Ruoli personalizzati

Sebbene IAM disponga di molti ruoli predefiniti che coprono i casi d'uso comuni, potresti voler definire i tuoi ruoli che contengono bundle di autorizzazioni che specifichi. Per supportare questa funzionalità, IAM offre ruoli personalizzati.

Tipi di entità

Esistono diversi tipi di entità. Ad esempio, Google Cloud gli account rappresentano un tipo generale, mentre allAuthenticatedUsers e allUsers sono due tipi specializzati. Per un elenco dei tipi di entità in IAM, consulta Identificatori delle entità. Per ulteriori informazioni sulle entità in generale, consulta Entità IAM.

Valori di praticità

Cloud Storage supporta i valori di praticità, ovvero un insieme speciale di entità che possono essere applicate in modo specifico ai criteri IAM dei bucket. In genere, dovresti evitare di utilizzare i valori di praticità negli ambienti di produzione , perché richiedono la concessione di ruoli di base, una pratica sconsigliata negli ambienti di produzione.

Un valore di praticità è un identificatore in due parti composto da un ruolo di base e un ID progetto:

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Un valore di praticità funge da ponte tra le entità a cui è stato concesso il ruolo di base e un ruolo IAM: il ruolo IAM concesso al valore di praticità viene, di fatto, concesso anche a tutte le entità del ruolo di base specificato per l'ID progetto specificato.

Ad esempio, supponiamo che jane@example.com e john@example.com abbiano il ruolo di base Visualizzatore (roles/viewer) per un progetto denominato my-example-project e che tu abbia un bucket in quel progetto denominato my-bucket. Se concedi il ruolo Creatore oggetti Storage (roles/storage.objectCreator) per my-bucket al valore di praticità projectViewer:my-example-project, sia jane@example.com sia john@example.com ottengono le autorizzazioni associate al ruolo Creatore oggetti Storage per my-bucket.

Puoi concedere e revocare l'accesso ai valori di praticità per i tuoi bucket, ma tieni presente che Cloud Storage li applica automaticamente in determinate circostanze. Per ulteriori informazioni, consulta Comportamento modificabile per i ruoli di base in Cloud Storage.

Condizioni

Le condizioni IAM consentono di impostare condizioni che controllano come le autorizzazioni vengono concesse o negate alle entità. Cloud Storage supporta i seguenti tipi di attributi di condizione:

  • resource.name: concedi o nega l'accesso a bucket e oggetti in base al nome del bucket o dell'oggetto. Puoi anche utilizzare resource.type per concedere l'accesso a bucket o oggetti, ma questa operazione è per lo più ridondante con l'utilizzo di resource.name. La seguente condizione di esempio applica un'impostazione IAM a tutti gli oggetti con lo stesso prefisso: 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • Data/ora: imposta una data di scadenza per l'autorizzazione. 

    request.time < timestamp('2019-01-01T00:00:00Z')

Queste espressioni condizionali sono istruzioni logiche che utilizzano un sottoinsieme di Common Expression Language (CEL). Specifichi le condizioni nelle associazioni di ruolo del criterio IAM di un bucket.

Tieni presente queste limitazioni:

  • Devi abilitare l'accesso uniforme a livello di bucket su un bucket prima di aggiungere condizioni a livello di bucket. Sebbene le condizioni siano consentite a livello di progetto, devi eseguire la migrazione di tutti i bucket nel progetto all'accesso uniforme a livello di bucket per impedire che gli ACL di Cloud Storage sostituiscano le condizioni IAM a livello di progetto. Puoi applicare un vincolo di accesso uniforme a livello di bucket per abilitare l'accesso uniforme a livello di bucket per tutti i nuovi bucket del progetto.
  • Le cartelle gestite possono essere specificate come risorsa nelle condizioni dei criteri di autorizzazione IAM. Le cartelle gestite non possono essere specificate come risorsa nelle condizioni dei criteri di negazione IAM. Le condizioni dei criteri di negazione IAM possono essere impostate solo utilizzando i tag e i tag non supportano le cartelle gestite.
  • I criteri di negazione IAM possono essere applicati solo alle risorse di progetto, cartella e organizzazione. Non possono essere applicati a bucket o cartelle gestite.
  • Quando utilizzi l'API JSON per chiamare getIamPolicy e setIamPolicy sui bucket con condizioni, devi impostare la versione del criterio IAM su 3.
  • Poiché l'autorizzazione storage.objects.list viene concessa a livello di bucket, non puoi utilizzare l'attributo di condizione resource.name per limitare l'accesso all'elenco degli oggetti a un sottoinsieme di oggetti nel bucket.
  • Le condizioni scadute rimangono nel criterio IAM finché non le rimuovi.

Utilizzo con gli strumenti di Cloud Storage

Sebbene le autorizzazioni IAM non possano essere impostate tramite l'API XML, gli utenti a cui sono state concesse le autorizzazioni IAM possono comunque utilizzare l'API XML, nonché qualsiasi altro strumento per accedere a Cloud Storage.

Per i riferimenti alle autorizzazioni IAM che consentono agli utenti di eseguire azioni con diversi strumenti di Cloud Storage, consulta Riferimenti IAM per Cloud Storage.

Passaggi successivi