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.
Per scoprire altri modi per controllare l'accesso in Cloud Storage, consulta Panoramica del controllo dell'accesso.
Per una discussione dettagliata di IAM e delle sue funzionalità in generale, consulta Identity and Access Management.
Panoramica
IAM ti consente di controllare chi ha accesso alle risorse nel tuo progetto Google Cloud. Le risorse includono i bucket Cloud Storage, le cartelle gestite all'interno dei bucket e gli oggetti memorizzati al loro interno, nonché altre entità di Google Cloud come le istanze Compute Engine.
Le entità sono il "chi" di IAM. Le entità possono essere singoli utenti, gruppi, domini o persino il pubblico nel suo complesso. Ai principali vengono assegnati ruoli, che consentono loro di eseguire azioni in Cloud Storage e in Google Cloud in generale. 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
ti consente di creare
oggetti. Questa autorizzazione è disponibile in ruoli come Creatore di oggetti archiviazione
(roles/storage.objectCreator
), che concede le autorizzazioni utili per
creare oggetti in un bucket, e Amministratore oggetti archiviazione
(roles/storage.objectAdmin
), che concede una vasta 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 al suo interno. Ad esempio, puoi impostare un criterio IAM su un bucket che conferisca a un utente il controllo amministrativo del bucket e dei relativi oggetti. Puoi anche impostare un criterio IAM per il progetto complessivo che dia a un altro utente la possibilità di visualizzare gli oggetti in qualsiasi bucket all'interno del progetto.
Se hai una risorsa dell'organizzazione Google Cloud, puoi anche utilizzare i criteri di negazione IAM per negare l'accesso alle risorse. Quando un criterio di negazione è associato 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 rifiuto sostituiscono qualsiasi criterio di autorizzazione IAM.
Autorizzazioni
Le autorizzazioni consentono ai principali di eseguire azioni specifiche su bucket, directory gestite o oggetti in Cloud Storage. Ad esempio, l'autorizzazionestorage.buckets.list
consente a un entità di elencare i bucket nel progetto. Non concedi direttamente le autorizzazioni agli account principali, ma concedi
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
. Assegni i ruoli alle entità, che possono eseguire azioni sui bucket, sulle cartelle gestite e sugli oggetti del progetto.
Per un elenco di riferimento dei ruoli IAM applicabili a Cloud Storage, consulta Ruoli IAM per Cloud Storage.
Concedere i ruoli a livello di progetto, bucket o cartella gestita
Puoi assegnare 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 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, supponi di voler concedere a un utente l'autorizzazione a leggere gli oggetti in qualsiasi bucket all'interno di un progetto, ma di creare oggetti solo nel bucket A. Per farlo, 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 all'interno 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 utilizzati
a livello di progetto, le autorizzazioni in essi contenute si applicano a tutti i bucket,
le cartelle e gli oggetti del progetto. Se utilizzate a livello di bucket, le autorizzazioni si applicano solo a un bucket specifico, alle cartelle e agli oggetti al suo interno. Esempi di questi ruoli sono il ruolo Amministratore spazio di archiviazione (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 di oggetti legacy di archiviazione (roles/storage.legacyObjectOwner
) solo a livello di bucket o di cartella gestita. I ruoli IAM
che ti consentono di controllare i criteri di rifiuto IAM possono essere applicati solo
a livello di organizzazione.
Relazione con le ACL
Oltre a IAM, i bucket e gli oggetti possono utilizzare un sistema di controllo dell'accesso precedente chiamato elenchi di controllo dell'accesso (ACL) se la funzionalità di accesso uniforme a livello di bucket non è abilitata per il bucket. In genere, è consigliabile evitare di utilizzare gli ACL e attivare l'accesso uniforme a livello di bucket per il bucket. Questa sezione illustra cosa tenere presente se consenti l'utilizzo di ACL per un bucket e gli oggetti al suo interno.
I ruoli IAM Legacy Bucket funzionano in tandem con le ACL dei bucket: quando aggiungi o rimuovi un ruolo Legacy Bucket, le ACL associate al bucket riflettono le modifiche. Analogamente, la modifica di un ACL specifico del bucket aggiorna il corrispondente ruolo IAM del bucket legacy per il bucket.
Ruolo Legacy Bucket | ACL equivalente |
---|---|
Lettore legacy dei bucket di Storage (roles/storage.legacyBucketReader ) |
Lettore di bucket |
Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter ) |
Writer del bucket |
Proprietario bucket legacy Storage (roles/storage.legacyBucketOwner ) |
Proprietario del bucket |
Tutti gli altri ruoli IAM a livello di bucket, inclusi i ruoli IAM per gli oggetti legacy, 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 i criteri IAM a livello di progetto e di bucket.
Confronto tra criteri di rifiuto IAM e ACL
I criteri di negazione IAM si applicano all'accesso concesso dagli ACL. Ad esempio, se crei un criterio di rifiuto che nega a un'entità l'autorizzazione storage.objects.get
in un progetto, l'entità non può visualizzare gli oggetti nel progetto, anche se le viene concessa l'autorizzazione storage.objects.get
per i singoli oggetti.READER
Autorizzazione IAM per la modifica delle ACL
Puoi utilizzare IAM per concedere alle entità l'autorizzazione necessaria per modificare gli ACL degli oggetti. Le seguenti autorizzazioni storage.buckets
consentono agli utenti di lavorare con gli ACL dei bucket e gli ACL di oggetti predefiniti: .get
,
.getIamPolicy
, .setIamPolicy
e .update
.
Analogamente, le seguenti autorizzazioni storage.objects
consentono agli utenti di lavorare con gli ACL di oggetto: .get
, .getIamPolicy
, .setIamPolicy
e .update
.
Ruoli personalizzati
Sebbene IAM abbia molti ruoli predefiniti che coprono casi d'uso comuni, potrebbe essere opportuno definire i tuoi ruoli contenenti set di autorizzazioni da te specificate. Per supportare questa funzionalità, IAM offre ruoli personalizzati.
Tipi di entità
Esistono diversi tipi di principali. Ad esempio, gli account Google e i gruppi Google rappresentano due tipi generali, mentre allAuthenticatedUsers
e allUsers
sono due tipi specializzati. Per un elenco dei tipi di entità in IAM, consulta Identificatori delle entità. Per maggiori informazioni sugli amministratori in generale, consulta Concetti correlati all'identità.
Valori di convenienza
Cloud Storage supporta i valori di praticità, ovvero un insieme speciale di principi che possono essere applicati specificamente ai criteri dei bucket IAM. In genere, dovresti evitare di utilizzare valori di praticità negli ambienti di produzione, perché richiedono la concessione di ruoli di base, una pratica sconsigliata negli ambienti di produzione.
Un valore pratico è un identificatore in due parti costituito da un ruolo di base e da 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, in effetti, 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 visualizzatore
(roles/viewer
) di base 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 pratico projectViewer:my-example-project
, sia jane@example.com che john@example.com acquisiscono le autorizzazioni associate al ruolo Creatore oggetti Storage per my-bucket
.
Puoi concedere e revocare l'accesso ai valori di convenienza 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 ti consentono di impostare condizioni che controllano la modalità di concessione o diniego delle autorizzazioni agli entità. Cloud Storage supporta i seguenti tipi di attributi condizione:
resource.name
: concedi o nega l'accesso a bucket e oggetti in base al nome del bucket o dell'oggetto. Puoi anche utilizzareresource.type
per concedere l'accesso a bucket o oggetti, ma questa operazione è per lo più ridondante rispetto all'utilizzo diresource.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 del criterio 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 a un accesso uniforme a livello di bucket per impedire agli ACL di Cloud Storage di eseguire l'override delle 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.
- Quando utilizzi l'API JSON per chiamare
getIamPolicy
esetIamPolicy
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 condizioneresource.name
per limitare l'accesso all'elenco di 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 sulle autorizzazioni IAM che consentono agli utenti di eseguire azioni con diversi strumenti Cloud Storage, consulta Riferimenti IAM per Cloud Storage.
Passaggi successivi
- Scopri come utilizzare IAM con Cloud Storage.
- Esamina la tabella di riferimento IAM per Cloud Storage.
- Scopri le best practice per l'utilizzo di IAM.
- Gestisci i criteri IAM per tutte le tue risorse Google Cloud.