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 di bucket, cartelle gestite e oggetti in Cloud Storage.

Panoramica

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

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

Ad esempio, l'autorizzazione storage.objects.create ti 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.

L'insieme di ruoli IAM che imposti su una risorsa è chiamato criterio IAM. L'accesso concesso da questi ruoli si applica sia alla risorsa su cui è impostato il criterio sia a tutte le risorse contenute al suo interno. Ad esempio, puoi impostare un criterio IAM su un bucket che conferisce a un utente il controllo amministrativo del bucket e dei relativi oggetti. Puoi anche impostare un criterio IAM per l'intero progetto che consenta a un altro utente di visualizzare gli oggetti in qualsiasi bucket all'interno del progetto.

Se hai una Google Cloud risorsa organizzazione, 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 risorsa secondaria al suo interno, indipendentemente dai ruoli assegnati. I criteri di negazione sostituiscono qualsiasi criterio di autorizzazione IAM.

Autorizzazioni

Le autorizzazioni consentono ai principal 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 tuo progetto. Non concedi direttamente le autorizzazioni alle entità, ma assegni ruoli, che includono 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. Assegni i ruoli alle entità, che possono eseguire azioni sui bucket, sulle cartelle gestite e sugli oggetti del tuo progetto.

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

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

Puoi concedere ruoli alle entità a livello di progetto, bucket o cartella gestita. Le autorizzazioni concesse da questi ruoli vengono applicate in modo cumulativo in tutta la gerarchia delle risorse. Puoi concedere 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 ottenere questo risultato, puoi assegnare all'utente il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) per il progetto, che gli consente di leggere qualsiasi oggetto archiviato in qualsiasi bucket del progetto, e il ruolo Creatore oggetti Storage (roles/storage.objectCreator) per il bucket A, che gli consente di creare oggetti solo in quel bucket.

Alcuni ruoli possono essere utilizzati a tutti i livelli della gerarchia delle risorse. Se utilizzate a livello di progetto, le autorizzazioni che contengono si applicano a tutti i bucket, alle cartelle e agli oggetti del progetto. Se utilizzate 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 Amministratore spazio di archiviazione (roles/storage.admin), Visualizzatore oggetti Storage (roles/storage.objectViewer) e Storage Object Creator (roles/storage.objectCreator).

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

Relazione con le ACL

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

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

Ruolo bucket legacy ACL equivalente
Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) Lettore bucket
Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) Bucket Writer
Proprietario bucket legacy Storage (roles/storage.legacyBucketOwner) Proprietario del bucket

Tutti gli altri ruoli IAM a livello di bucket, inclusi i ruoli IAM Legacy Object, funzionano indipendentemente dalle ACL. Analogamente, 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 le ACL per l'oggetto, oltre a controllare le policy IAM a livello di progetto e di bucket.

Criteri di negazione IAM e ACL

I criteri di negazione IAM si applicano all'accesso concesso dagli elenchi ACL. Ad esempio, se crei un criterio di negazione che nega a un'entità l'autorizzazione storage.objects.get per un progetto, l'entità non può visualizzare gli oggetti in quel 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.

Analogamente, 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 casi d'uso comuni, potresti voler definire ruoli personalizzati che contengano bundle di autorizzazioni che specifichi. Per supportare questa funzionalità, IAM offre ruoli personalizzati.

Tipi di entità

Esistono diversi tipi di responsabili. Ad esempio, gli accountGoogle Cloud 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 maggiori informazioni sulle entità in generale, consulta Entità IAM.

Valori di convenienza

Cloud Storage supporta i valori di convenienza, un insieme speciale di principal che possono essere applicati in modo specifico alle tue norme <x0A>del bucket IAM. In genere, è consigliabile evitare di utilizzare valori di convenienza 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 costituito da un ruolo di base e un ID progetto:

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

Un valore di convenienza 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 convenienza 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 che 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 saperne di più, consulta comportamento modificabile per i ruoli di base in Cloud Storage.

Condizioni

Le condizioni IAM consentono di impostare condizioni che controllano il modo in cui 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 rispetto all'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 del Common Expression Language (CEL). Specifichi le condizioni nelle associazioni di ruolo dei criteri IAM di un bucket.

Tieni presenti 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 del 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 nel tuo progetto.
  • 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 nella policy 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 autorizzazioni IAM possono comunque utilizzare l'API XML, nonché qualsiasi altro strumento per accedere a Cloud Storage.

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

Passaggi successivi