Autenticazione Cloud Storage

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

La maggior parte delle operazioni eseguite in Cloud Storage deve essere autenticata. Le uniche eccezioni riguardano le operazioni su oggetti che consentono l'accesso anonimo. Gli oggetti sono accessibili in modo anonimo se il gruppo allUsers dispone dell'autorizzazione READ. Il gruppo allUsers include tutti gli utenti su Internet.

OAuth 2.0

Autenticazione

Cloud Storage utilizza OAuth 2.0 per l'autenticazione e l'autorizzazione dell'API. L'autenticazione è il processo di determinazione dell'identità di un client. I dettagli dell'autenticazione variano in base al modo in cui accedi a Cloud Storage, ma rientrano in due tipi generali:

  • Un flusso incentrato sul server consente a un'applicazione di conservare direttamente le credenziali di un account di servizio per completare l'autenticazione. Utilizza questo flusso se l'applicazione utilizza i propri dati anziché i dati utente. I progetti Google Cloud hanno account di servizio predefiniti che puoi utilizzare oppure puoi crearne di nuovi.

  • Un flusso incentrato sugli utenti consente a un'applicazione di ottenere le credenziali da un utente finale. L'utente accede per completare l'autenticazione. Utilizza questo flusso se la tua applicazione deve accedere ai dati utente. Consulta la sezione Credenziali dell'account utente più avanti in questa pagina per gli scenari in cui è appropriato un flusso incentrato sugli utenti.

Tieni presente che puoi utilizzare entrambi i tipi di autenticazione in un'applicazione. Per ulteriori informazioni sull'autenticazione, consulta la guida all'autenticazione di Google Cloud.

Ambiti

L'autorizzazione è il processo di determinazione delle autorizzazioni di cui dispone un'identità autenticata su un insieme di risorse specificate. OAuth 2.0 utilizza gli ambiti per determinare se un'identità autenticata è autorizzata. Le applicazioni utilizzano una credenziale (ottenuta da un flusso di autenticazione incentrato sugli utenti o sui server) insieme a uno o più ambiti per richiedere un token di accesso da un server di autorizzazione di Google per accedere alle risorse protette. Ad esempio, l'applicazione A con un token di accesso con ambito read-only può solo leggere, mentre l'applicazione B con un token di accesso con ambito read-write può leggere e modificare i dati. Nessuna delle applicazioni può leggere o modificare gli elenchi di controllo dell'accesso per oggetti e bucket; solo un'applicazione con ambito full-control può farlo.

Tipo Descrizione URL ambito
read-only Consente solo l'accesso in lettura ai dati, inclusi i bucket di elenco. https://www.googleapis.com/auth/devstorage.read_only
read-write Consente l'accesso per leggere e modificare i dati, ma non metadati come i criteri IAM. https://www.googleapis.com/auth/devstorage.read_write
full-control Consente il controllo completo dei dati e della possibilità di modificare i criteri IAM. https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Visualizzare i dati in tutti i servizi Google Cloud. Per Cloud Storage, è uguale a devstorage.read-only. https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform Visualizzare e gestire dati in tutti i servizi Google Cloud. Per Cloud Storage, è uguale a devstorage.full-control. https://www.googleapis.com/auth/cloud-platform

Autenticazione gsutil

Con gsutil installato dall'interfaccia a riga di comando gcloud, è necessario eseguire l'autenticazione con le credenziali dell'account di servizio.

  1. Utilizza un account di servizio esistente o creane uno nuovo e scarica la chiave privata associata. Tieni presente che puoi scaricare i dati della chiave privata per una chiave dell'account di servizio solo quando la chiave viene creata.

  2. Utilizza gcloud auth activate-service-account per eseguire l'autenticazione con l'account di servizio:

    gcloud auth activate-service-account --key-file KEY_FILE

    Dove KEY_FILE è il nome del file che contiene le credenziali per l'account di servizio.

gcloud auth utilizza l'ambito cloud-platform quando riceve un token di accesso.

Autenticazione libreria client

Le librerie client possono utilizzare le credenziali predefinite dell'applicazione per eseguire facilmente l'autenticazione con le API di Google e inviare richieste a tali API. Con Credenziali predefinite dell'applicazione, puoi testare la tua applicazione in locale ed eseguirne il deployment senza modificare il codice sottostante. Per ulteriori informazioni, tra cui esempi di codice, consulta la guida all'autenticazione in Google Cloud .

Autenticazione API

Per effettuare richieste utilizzando OAuth 2.0 all'API XML o all'API JSON di Cloud Storage, includi il token di accesso della tua applicazione nell'intestazione Authorization in ogni richiesta che richiede l'autenticazione. Puoi generare un token di accesso da Playground OAuth 2.0:

  1. In OAuth 2.0 Playground, fai clic su API Cloud Storage v1 e seleziona un livello di accesso per la tua applicazione (full_control, read_only o read_write).

  2. Fai clic su Autorizza API.

  3. Accedi al tuo Account Google quando richiesto. Nella finestra di dialogo visualizzata fai clic su Consenti.

  4. Nel passaggio 2 del parco giochi, fai clic su Codice di autorizzazione di Exchange per i token in corrispondenza del codice di autorizzazione visualizzato.

  5. Copia il token di accesso e includilo nell'intestazione Authorization della richiesta:

    Authorization: Bearer OAUTH2_TOKEN

Di seguito è riportato un esempio di richiesta che elenca oggetti in un bucket.

API JSON

Utilizza il metodo list della risorsa Oggetti.

GET /storage/v1/b/example-bucket/o HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Per autorizzare le richieste dalla riga di comando o per i test, puoi utilizzare il comando curl con la seguente sintassi:

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"

Per il test locale, puoi utilizzare il comando gcloud auth application-default print-access-token per generare un token.

API XML

Utilizza una richiesta List object (Elenca oggetti).

GET / HTTP/1.1
Host: example-bucket.storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Per autorizzare le richieste dalla riga di comando o per i test, puoi utilizzare il comando curl con la seguente sintassi:

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://BUCKET_NAME.storage.googleapis.com"

Per il test locale, puoi utilizzare il comando gcloud auth application-default print-access-token per generare un token.

Considerata la complessità della gestione e l'aggiornamento dei token di accesso e il rischio per la sicurezza correlato alla gestione diretta di applicazioni crittografiche, ti invitiamo vivamente a utilizzare una libreria client verificata.

Se stai cercando le chiavi HMAC da utilizzare con l'API XML per l'accesso interoperabile con Amazon S3, consulta la pagina Gestire le chiavi HMAC per gli account di servizio.

Credenziali dell'account utente

Utilizza le credenziali dell'account utente per l'autenticazione quando l'applicazione richiede l'accesso ai dati per conto di un utente; in caso contrario, utilizza le credenziali dell'account di servizio. Di seguito sono riportati alcuni esempi di scenari in cui è possibile utilizzare le credenziali degli account utente:

  • Applicazioni server web
  • Applicazioni installate e desktop
  • Applicazioni mobili
  • JavaScript lato client
  • Applicazioni su dispositivi di input limitato

Per saperne di più su questi scenari, vedi Scenari OAuth 2.0.

Se stai progettando un'applicazione per supportare più opzioni di autenticazione per gli utenti finali, utilizza Firebase Authentication, che supporta l'autenticazione di email e password, e l'accesso federato con provider di identità come Google, Facebook, Twitter e GitHub. Consulta la pagina Da dove inizio con Firebase Authentication per maggiori dettagli su come configurare i sistemi di autenticazione per diversi casi d'uso.

Quando a un'applicazione viene concesso un token di accesso in un flusso di autenticazione incentrato sull'utente da un utente finale, il token di accesso avrà solo le autorizzazioni a disposizione dell'utente che concede il token. Ad esempio, se jane@gmail.com ha accesso read-only a example-bucket, un'applicazione a cui Jane ha concesso l'accesso a read-write non potrà scrivere a example-bucket per suo conto.

Passaggi successivi