Comprensione dei criteri di autorizzazione

Puoi concedere l'accesso alle risorse Google Cloud utilizzando i criteri di autorizzazione, noti anche come criteri IAM (Identity and Access Management), collegati alle risorse. Puoi collegare un solo criterio di autorizzazione a ogni risorsa. Il criterio di autorizzazione controlla l'accesso alla risorsa stessa e a tutti i relativi discendenti che ereditano il criterio di autorizzazione.

Questa pagina mostra i criteri di autorizzazione in formato JSON. Puoi anche utilizzare Google Cloud CLI per recuperare i criteri di autorizzazione in formato YAML.

Struttura dei criteri

Un criterio di autorizzazione è una raccolta di associazioni di ruoli e metadati. Un'associazione di ruoli specifica l'accesso da concedere a una risorsa. Associa, o vincola, una o più entità a un singolo ruolo IAM e a qualsiasi condizione specifica del contesto che modifichi le modalità e i tempi di concessione del ruolo. I metadati includono informazioni aggiuntive sul criterio di autorizzazione, come un etag e una versione per facilitare la gestione dei criteri.

Ogni associazione di ruolo può includere i seguenti campi:

Una o più entità, note anche come membri o identità. Esistono diversi tipi di entità, tra cui account utente, account di servizio, gruppi Google e domini. Per un elenco completo dei tipi di entità supportati, consulta Identificatori delle entità.
Un ruolo, ovvero una raccolta denominata di autorizzazioni che consentono di eseguire azioni sulle risorse Google Cloud.
Una condizione, ovvero un'espressione logica facoltativa che vincola ulteriormente l'associazione del ruolo in base agli attributi relativi alla richiesta, come l'origine o la risorsa di destinazione. In genere, le condizioni vengono utilizzate per controllare se l'accesso viene concesso in base al contesto di una richiesta.

Se un'associazione di ruoli contiene una condizione, viene definita associazione di ruoli condizionale.

Alcuni servizi Google Cloud non accettano le condizioni dei criteri di autorizzazione. Per un elenco dei servizi e dei tipi di risorse che accettano le condizioni, consulta Tipi di risorse che accettano associazioni di ruoli condizionali.

Le modifiche all'accesso di un'entità sono alla fine coerenti. Ciò significa che occorre del tempo prima che le modifiche all'accesso vengano propagate nel sistema. Per sapere quanto tempo richiede in media la propagazione delle modifiche all'accesso, consulta Propagazione delle modifiche di accesso.

Limiti sulle entità

Ogni criterio di autorizzazione può contenere fino a 1500 entità. Ai fini di questo limite, IAM conteggia tutte le visualizzazioni di ogni entità nelle associazioni di ruoli del criterio di autorizzazione, oltre alle entità che il criterio di autorizzazione esclude dall'audit logging di accesso ai dati. Non deduplica le entità presenti in più associazioni di ruoli. Ad esempio, se un criterio di autorizzazione contiene solo associazioni di ruoli per l'entità group:my-group@example.com e questa entità viene visualizzata in 50 associazioni di ruoli, puoi aggiungere altre 1450 entità alle associazioni di ruoli nel criterio di autorizzazione.

Fino a 250 delle entità in un criterio di autorizzazione possono essere domini e gruppi Google. Ai fini di questo limite, i domini e i gruppi Google vengono conteggiati come segue:

Per i domini, IAM conteggia tutte le occorrenze di ogni dominio nelle associazioni di ruolo del criterio di autorizzazione. Non deduplica i domini visualizzati in più di un'associazione di ruoli. Ad esempio, se un criterio di autorizzazione contiene un solo dominio, domain:example.com, e questo viene visualizzato nel criterio di autorizzazione 10 volte, puoi aggiungere altri 240 domini prima di raggiungere il limite.
Per Google Gruppi, ogni gruppo univoco viene conteggiato una sola volta, indipendentemente da quante volte il gruppo compare nel criterio di autorizzazione. Ad esempio, se un criterio di autorizzazione contiene solo un gruppo, group:my-group@example.com, e questo viene visualizzato nel criterio di autorizzazione 10 volte, puoi aggiungere altri 249 gruppi univoci prima di raggiungere il limite.

Se utilizzi le condizioni IAM o se concedi ruoli a molte entità con identificatori insolitamente lunghi, IAM potrebbe consentire meno entità nel criterio di autorizzazione.

Metadati dei criteri

I metadati per un criterio di autorizzazione includono i seguenti campi:

Un campo etag, che viene utilizzato per il controllo della contemporaneità, e garantisce che i criteri di autorizzazione vengano aggiornati in modo coerente. Per maggiori dettagli, consulta Utilizzare gli etag in un criterio in questa pagina.
Un campo version, che specifica la versione dello schema di un determinato criterio di autorizzazione. Per maggiori dettagli, vedi Versioni delle norme in questa pagina.

Per organizzazioni, cartelle, progetti e account di fatturazione, il criterio di autorizzazione può contenere anche un campo auditConfig, in cui sono specificati i tipi di attività che generano log di controllo per ciascun servizio. Per informazioni su come configurare questa parte di un criterio di autorizzazione, consulta Configurazione degli audit log di accesso ai dati.

Utilizzare gli etag in un criterio

Quando più sistemi tentano di scrivere nello stesso criterio di autorizzazione contemporaneamente, c'è il rischio che i sistemi possano sovrascrivere le modifiche degli altri. Questo rischio esiste perché i criteri di autorizzazione vengono aggiornati utilizzando il pattern lettura-modifica-scrittura, che prevede più operazioni:

Consultare il criterio di autorizzazione esistente
Modifica del criterio di autorizzazione.
Scrittura dell'intero criterio di autorizzazione

Se il sistema A legge un criterio di autorizzazione e il sistema B scrive immediatamente una versione aggiornata di quel criterio di autorizzazione, il sistema A non sarà a conoscenza delle modifiche del sistema B. Quando il sistema A scrive le proprie modifiche al criterio di autorizzazione, le modifiche del sistema B potrebbero andare perse.

Per evitare questo problema, Identity and Access Management (IAM) supporta il controllo della contemporaneità tramite l'utilizzo di un campo etag nel criterio di autorizzazione. Ogni criterio di autorizzazione contiene un campo etag il cui valore cambia ogni volta che viene aggiornato un criterio di autorizzazione. Se un criterio di autorizzazione contiene un campo etag, ma non sono presenti associazioni di ruoli, il criterio di autorizzazione non concede alcun ruolo IAM.

Il campo etag contiene un valore come BwUjMhCsNvY=. Quando aggiorni il criterio di autorizzazione, assicurati di includere il campo etag nel criterio di autorizzazione aggiornato. Se il criterio di autorizzazione è stato modificato dopo averlo recuperato, il valore etag non corrisponderà e l'aggiornamento non andrà a buon fine. Per l'API REST, ricevi il codice di stato HTTP 409 Conflict e il corpo della risposta è simile al seguente:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Se viene visualizzato questo errore, riprova a eseguire l'intera serie di operazioni: leggi di nuovo il criterio di autorizzazione, modificalo in base alle esigenze e scrivi il criterio di autorizzazione aggiornato. Dovresti eseguire i nuovi tentativi automaticamente, con un backoff esponenziale, in tutti gli strumenti che utilizzi per gestire i criteri di autorizzazione.

Esempio: criterio semplice

Considera il seguente criterio di autorizzazione che associa un'entità a un ruolo:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Nell'esempio precedente, a jie@example.com viene concesso il ruolo di base Proprietario senza alcuna condizione. Questo ruolo concede a jie@example.com accesso quasi illimitato.

Esempio: criterio con più associazioni di ruoli

Prendi in considerazione il seguente criterio di autorizzazione che contiene più di un'associazione di ruolo. Ogni associazione di ruolo assegna un ruolo diverso:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Nell'esempio precedente, a Jie (jie@example.com) viene concesso il ruolo predefinito Amministratore organizzazione (roles/resourcemanager.organizationAdmin) nella prima associazione del ruolo. Questo ruolo contiene le autorizzazioni per le organizzazioni, le cartelle e le operazioni limitate dei progetti. Nella seconda associazione del ruolo, sia a Jie che a Raha (raha@example.com) viene concessa la possibilità di creare progetti tramite il ruolo Autore progetto (roles/resourcemanager.projectCreator). Insieme, queste associazioni di ruoli concedono un accesso granulare sia a Jie che a Raha e a Jie è concesso un accesso più ampio di Raha.

Esempio: criterio con associazione di ruolo condizionale

Considera il seguente criterio di autorizzazione, che associa le entità a un ruolo predefinito e utilizza un'espressione della condizione per vincolare l'associazione dei ruoli:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In questo esempio, il campo version è impostato su 3, perché il criterio di autorizzazione contiene un'espressione della condizione. L'associazione dei ruoli nel criterio di autorizzazione è condizionale; concede il ruolo al gruppo Google prod-dev@example.com e all'account di servizio prod-dev-example@appspot.gserviceaccount.com, ma solo fino al 1° luglio 2022.

Per maggiori dettagli sulle funzionalità supportate da ogni versione del criterio di autorizzazione, vedi Versioni dei criteri in questa pagina.

Esempio: criterio con associazioni di ruoli condizionali e incondizionali

Considera il seguente criterio di autorizzazione, che contiene associazioni di ruoli condizionali e incondizionali per lo stesso ruolo:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In questo esempio, l'account di servizio serviceAccount:prod-dev-example@appspot.gserviceaccount.com è incluso in due associazioni di ruoli per lo stesso ruolo. La prima associazione del ruolo non ha una condizione. La seconda associazione dei ruoli ha una condizione che concede il ruolo solo fino al 1° luglio 2022.

Di fatto, questo criterio di autorizzazione concede sempre il ruolo all'account di servizio. In IAM, le associazioni di ruoli condizionali non sostituiscono le associazioni di ruoli senza condizioni. Se un'entità è associata a un ruolo e l'associazione dei ruoli non ha una condizione, l'entità avrà sempre questo ruolo. L'aggiunta dell'entità a un'associazione di ruoli condizionale per lo stesso ruolo non ha alcun effetto.

Al contrario, il gruppo Google group:prod-dev@example.com è incluso solo nell'associazione dei ruoli condizionale. Di conseguenza, ha questo ruolo solo prima del 1° luglio 2022.

Esempio: criterio che associa un ruolo a un'entità eliminata

Prendi in considerazione il seguente criterio di autorizzazione. Questo criterio di autorizzazione associa un ruolo a un utente, donald@example.com, il cui account è stato eliminato. Di conseguenza, l'identificatore dell'utente ha ora un prefisso deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Se crei un nuovo utente denominato donald@example.com, le associazioni dei ruoli del criterio di autorizzazione per l'utente eliminato non si applicano al nuovo utente. Questo comportamento impedisce ai nuovi utenti di ereditare i ruoli concessi agli utenti eliminati. Se vuoi concedere ruoli al nuovo utente, aggiungi il nuovo utente alle associazioni di ruoli del criterio di autorizzazione, come mostrato in Criteri con entità eliminate in questa pagina.

Inoltre, il nome dell'utente ora include il prefisso deleted: e il suffisso ?uid=numeric-id, dove numeric-id è l'ID numerico univoco dell'utente eliminato. In questo esempio, anziché user:donald@example.com, il criterio di autorizzazione mostra l'identificatore deleted:user:donald@example.com?uid=123456789012345678901.

Gli account di servizio e i gruppi hanno lo stesso comportamento degli utenti. Se elimini un account di servizio o un gruppo, e quindi visualizzi un criterio di autorizzazione che include questa entità, il nome dell'entità eliminata ha il prefisso deleted: e il suffisso ?uid=numeric-id.

Criteri predefiniti

Tutte le risorse che accettano i criteri di autorizzazione vengono create con i criteri di autorizzazione predefiniti. La maggior parte dei criteri di autorizzazione predefiniti della maggior parte delle risorse sono vuoti. Tuttavia, i criteri di autorizzazione predefiniti di alcune risorse contengono automaticamente determinate associazioni di ruoli. Ad esempio, quando crei un nuovo progetto, il criterio di autorizzazione per il progetto ha automaticamente un'associazione di ruolo che ti concede il ruolo Proprietario (roles/owner) per il progetto.

Queste associazioni di ruoli vengono create dal sistema, quindi l'utente non ha bisogno delle autorizzazioni getIamPolicy o setIamPolicy per la risorsa per creare le associazioni di ruoli.

Per sapere se una risorsa è stata creata con un criterio di autorizzazione, consulta la documentazione della risorsa.

Ereditarietà dei criteri e gerarchia delle risorse

Le risorse Google Cloud sono organizzate in modo gerarchico, dove il nodo organizzazione è il nodo radice della gerarchia, poi facoltativamente le cartelle e infine i progetti. La maggior parte delle altre risorse viene creata e gestita all'interno di un progetto. Ogni risorsa ha un solo elemento padre, tranne l'organizzazione. L'organizzazione, in quanto nodo radice della gerarchia, non ha un elemento padre. Per ulteriori informazioni, consulta l'argomento Gerarchia delle risorse.

La gerarchia delle risorse è importante da considerare quando si imposta un criterio di autorizzazione. Quando imposti un criterio di autorizzazione a un livello superiore nella gerarchia, ad esempio a livello di organizzazione, cartella o progetto, l'ambito di accesso concesso include il livello delle risorse a cui è associato il criterio di autorizzazione e tutte le risorse al di sotto di quel livello. Ad esempio, un criterio di autorizzazione impostato a livello di organizzazione si applica all'organizzazione e a tutte le risorse al suo interno. Analogamente, un criterio di autorizzazione impostato a livello di progetto si applica al progetto e a tutte le risorse del progetto.

Eredità dei criteri è il termine che descrive in che modo i criteri di autorizzazione si applicano alle risorse al di sotto del relativo livello nella gerarchia delle risorse. Criterio effettivo è il termine che descrive in che modo tutti i criteri di autorizzazione padre nella gerarchia delle risorse vengono ereditati per una risorsa. È l'unione dei seguenti elementi:

Il criterio di autorizzazione impostato sulla risorsa
I criteri di autorizzazione impostati su tutti i livelli delle risorse di discendenza della risorsa nella gerarchia

Ogni nuova associazione di ruoli (ereditata dalle risorse padre) che influisce sul criterio di autorizzazione effettiva della risorsa viene valutata in modo indipendente. Una richiesta di accesso specifica alla risorsa viene concessa se una delle associazioni di ruoli di livello superiore concede l'accesso alla richiesta.

Se viene introdotta una nuova associazione di ruoli a qualsiasi livello del criterio di autorizzazione ereditato di una risorsa, l'ambito di concessione dell'accesso aumenta.

Esempio: ereditarietà dei criteri

Per comprendere l'ereditarietà dei criteri, considera uno scenario in cui concedi a un utente, Raha, due diversi ruoli IAM a due diversi livelli nella gerarchia delle risorse.

Per concedere a Raha un ruolo a livello di organizzazione, imposta i seguenti criteri di autorizzazione sulla tua organizzazione:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo criterio di autorizzazione concede a Raha il ruolo roles/storage.objectViewer Visualizzatore oggetti Storage, che contiene le autorizzazioni get e list per i progetti e gli oggetti Cloud Storage. Poiché hai impostato il criterio di autorizzazione nella tua organizzazione, Raha può utilizzare queste autorizzazioni per tutti i progetti e tutti gli oggetti Cloud Storage della tua organizzazione.

Per concedere a Raha un ruolo a livello di progetto, imposta il seguente criterio di autorizzazione sul progetto myproject-123:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo criterio di autorizzazione concede a Raha il ruolo Creatore oggetti Storage (roles/storage.objectCreator), che gli permette di creare oggetti Cloud Storage. Poiché imposti il criterio di autorizzazione su myproject-123, Raha può creare oggetti Cloud Storage solo in myproject-123.

Ora che ci sono due associazioni di ruolo che concedono a Raha l'accesso agli oggetti Cloud Storage di destinazione in myproject-123, si applicano i seguenti criteri di autorizzazione:

Un criterio di autorizzazione a livello di organizzazione concede la possibilità di elencare e recuperare tutti gli oggetti Cloud Storage in questa organizzazione.
Un criterio di autorizzazione a livello di progetto per il progetto myproject-123 concede la possibilità di creare oggetti all'interno di quel progetto.

La tabella seguente riassume la norma effettiva di Raha:

Autorizzazioni concesse tramite il ruolo "storage.objectViewer" a livello di organizzazione	Autorizzazioni concesse tramite il ruolo "storage.objectCreator" in "myproject-123"	Ambito della concessione effettivo per Raha in "myproject-123"
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list	resourcemanager.projects.get resourcemanager.projects.list storage.objects.create	resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create

Versioni del criterio

Nel tempo, IAM potrebbe aggiungere nuove funzionalità che aggiungono o modificano in modo significativo i campi nello schema dei criteri di autorizzazione. Per evitare di interrompere le integrazioni esistenti che si basano sulla coerenza nella struttura dei criteri di autorizzazione, queste modifiche vengono introdotte nelle nuove versioni dello schema dei criteri di autorizzazione.

Se è la prima volta che esegui l'integrazione con IAM, ti consigliamo di utilizzare la versione più recente dello schema dei criteri di autorizzazione disponibile in quel momento. Di seguito illustreremo le diverse versioni disponibili e come utilizzarle. Inoltre, ti spiegheremo come specificare la versione che preferisci e ti illustreremo alcuni scenari di risoluzione dei problemi.

Ogni criterio di autorizzazione esistente specifica un campo version all'interno dei metadati del criterio di autorizzazione. Considera la parte evidenziata di seguito:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Questo campo specifica la versione dello schema di sintassi del criterio di autorizzazione. Ogni versione del criterio di autorizzazione contiene uno schema di sintassi specifico che può essere utilizzato dalle associazioni di ruoli. La versione più recente può contenere associazioni di ruoli con lo schema di sintassi più recente non supportato dalle versioni precedenti. Questo campo non è destinato a essere utilizzato per scopi diversi dal controllo dello schema di sintassi per il criterio di autorizzazione.

Versioni del criterio valide

I criteri di autorizzazione possono utilizzare le seguenti versioni dei criteri di autorizzazione:

Versione	Descrizione
`1`	La prima versione dello schema di sintassi IAM per i criteri. Supporta l'associazione di un ruolo a una o più entità. Non supporta le associazioni di ruoli condizionali.
`2`	Riservato per uso interno.
`3`	Introduce il campo `condition` nell'associazione dei ruoli, che vincola l'associazione dei ruoli tramite regole basate sul contesto e sugli attributi. Per maggiori informazioni, consulta la panoramica delle condizioni IAM.

Specificare una versione del criterio durante il recupero di un criterio

Per l'API REST e le librerie client, quando ricevi un criterio di autorizzazione, ti consigliamo di specificare nella richiesta una versione del criterio di autorizzazione. Quando una richiesta specifica una versione del criterio di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità in quella versione del criterio e che sia in grado di gestirle correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM presuppone che il chiamante voglia un criterio di autorizzazione 1 della versione.

Quando ottieni un criterio di autorizzazione, IAM controlla la versione del criterio di autorizzazione nella richiesta o la versione predefinita se nella richiesta non è stata specificata una versione. IAM verifica inoltre la presenza nel criterio di autorizzazione dei campi non supportati in un criterio di autorizzazione della versione 1. Utilizza queste informazioni per decidere il tipo di risposta da inviare:

Se il criterio di autorizzazione non contiene condizioni, IAM restituisce sempre un criterio di autorizzazione 1 per la versione, indipendentemente dal numero di versione nella richiesta.
Se il criterio di autorizzazione contiene delle condizioni e il chiamante ha richiesto un criterio di autorizzazione della versione 3, IAM restituisce un criterio di autorizzazione della versione 3 che include le condizioni. Per un esempio, vedi lo scenario 1 in questa pagina.
Se il criterio di autorizzazione contiene delle condizioni e il chiamante ha richiesto un criterio di autorizzazione della versione 1 o non ha specificato una versione, IAM restituisce un criterio di autorizzazione 1 della versione.

Per le associazioni di ruoli che includono una condizione, IAM aggiunge la stringa _withcond_ al nome del ruolo, seguita da un valore hash; ad esempio, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La condizione in sé non è presente. Per un esempio, vedi scenario 2 in questa pagina.

Scenario 1: versione del criterio che supporta pienamente le condizioni IAM

Supponi di chiamare il seguente metodo dell'API REST per ottenere il criterio di autorizzazione per un progetto:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Il corpo della richiesta contiene il seguente testo:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

La risposta contiene il criterio di autorizzazione del progetto. Se il criterio di autorizzazione contiene almeno un'associazione di ruoli condizionale, il campo version è impostato su 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Se il criterio di autorizzazione non contiene associazioni di ruoli condizionali, il relativo campo version viene impostato su 1, anche se la versione specificata nella richiesta 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Scenario 2: versione del criterio con supporto limitato per le condizioni IAM

Supponi di chiamare il seguente metodo dell'API REST per ottenere il criterio di autorizzazione per un progetto:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Il corpo della richiesta è vuoto e non specifica un numero di versione. Di conseguenza, IAM utilizza la versione predefinita del criterio di autorizzazione, 1.

Il criterio di autorizzazione contiene un'associazione di ruolo condizionale. Poiché la versione del criterio di autorizzazione è 1, la condizione non viene visualizzata nella risposta. Per indicare che l'associazione dei ruoli utilizza una condizione, IAM aggiunge la stringa _withcond_ al nome del ruolo, seguita da un valore hash:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Specificare una versione del criterio durante l'impostazione di un criterio

Quando imposti un criterio di autorizzazione, ti consigliamo di specificare nella richiesta una versione del criterio di autorizzazione. Quando una richiesta specifica una versione del criterio di autorizzazione, IAM presuppone che il chiamante sia a conoscenza delle funzionalità di tale versione e sia in grado di gestirle correttamente.

Se la richiesta non specifica una versione del criterio di autorizzazione, IAM accetta solo i campi che possono essere visualizzati in un criterio di autorizzazione della versione 1. Come best practice, non modificare le associazioni di ruoli condizionali in un criterio di autorizzazione della versione 1. Poiché il criterio di autorizzazione non mostra la condizione per ogni associazione di ruoli, non sai quando o dove viene effettivamente concessa l'associazione dei ruoli. Recupera invece la rappresentazione della versione 3 del criterio di autorizzazione, che mostra la condizione per ogni associazione di ruoli, e utilizza questa rappresentazione per aggiornare le associazioni di ruoli.

Scenario: versioni dei criteri nelle richieste e nelle risposte

Supponi di utilizzare l'API REST per ricevere un criterio di autorizzazione e di specificare la versione 3 nella richiesta. La risposta contiene il seguente criterio di autorizzazione, che utilizza la versione 3:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Decidi che raha@example.com deve avere il ruolo Amministratore Storage (roles/storage.admin) per tutta la settimana, non solo nei giorni feriali. Rimuovi la condizione dall'associazione del ruolo e invii una richiesta API REST per impostare il criterio di autorizzazione. Ancora una volta, specifichi la versione 3 nella richiesta:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

La risposta contiene il criterio di autorizzazione aggiornato:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

Il criterio di autorizzazione nella risposta utilizza la versione 1, anche se la richiesta specifica la versione 3, perché il criterio di autorizzazione utilizza solo i campi supportati in un criterio di autorizzazione 1 della versione.

Criteri con entità eliminate

Se un'associazione di ruoli in un criterio di autorizzazione include un'entità eliminata e aggiungi un'associazione di ruolo per una nuova entità con lo stesso nome, l'associazione dei ruoli viene sempre applicata alla nuova entità.

Ad esempio, considera questo criterio di autorizzazione che include un'associazione di ruoli a un utente eliminato, donald@example.com, e un account di servizio eliminato, my-service-account@project-id.iam.gserviceaccount.com. Di conseguenza, l'identificatore per ogni entità ha un prefisso deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Supponi di creare un nuovo utente denominato donald@example.com e di voler concedere al nuovo utente il ruolo Autore progetto (roles/resourcemanager.projectCreator), che consente alle entità di creare progetti Google Cloud. Per concedere il ruolo al nuovo utente, aggiorna il criterio di autorizzazione come mostrato in questo esempio:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Per semplificare il controllo dei criteri di autorizzazione IAM, puoi anche rimuovere l'utente eliminato dall'associazione dei ruoli al ruolo Proprietario:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Best practice relative alle norme

Le seguenti best practice si applicano alle organizzazioni con molti utenti Google Cloud:

Quando gestisci più account utente con le stesse configurazioni di accesso, utilizza invece Google Gruppi. Inserisci ogni singolo account utente nel gruppo e concedi al gruppo i ruoli previsti anziché gli account utente singoli.
Autorizzazioni concesse a livello di organizzazione: valuta attentamente a quali entità sono concesse le autorizzazioni di accesso a livello di organizzazione. Per la maggior parte delle organizzazioni, solo ad alcuni team specifici, ad esempio i team di sicurezza e di rete, dovrebbe essere concesso l'accesso a questo livello della gerarchia delle risorse.
Autorizzazioni concesse a livello di cartella: valuta la possibilità di riflettere la struttura operativa della tua organizzazione utilizzando livelli di cartelle, in cui ogni cartella principale/secondaria può essere configurata con diversi set di concessioni di accesso in linea con le esigenze aziendali e operative. Ad esempio, una cartella padre potrebbe riflettere un reparto, una delle cartelle figlio potrebbe riflettere l'accesso alle risorse e il funzionamento da parte di un gruppo, mentre un'altra cartella secondaria potrebbe riflettere un piccolo team. Entrambe queste cartelle potrebbero contenere progetti per le esigenze operative del loro team. L'utilizzo delle cartelle in questo modo può garantire una corretta separazione degli accessi, rispettando al contempo i criteri di autorizzazione ereditati dalle cartelle padre e dall'organizzazione. Questa pratica richiede meno manutenzione dei criteri di autorizzazione durante la creazione e la gestione delle risorse Google Cloud.
Autorizzazioni concesse a livello di progetto: concedi le associazioni di ruoli a livello di progetto se necessario per seguire il principio del privilegio minimo. Ad esempio, se un'entità deve accedere a tre dei dieci progetti in una cartella, devi concedere l'accesso a ciascuno dei tre progetti singolarmente. Al contrario, se hai concesso un ruolo nella cartella, l'entità otterrà l'accesso di cui non ha bisogno per altri sette progetti.

In alternativa, puoi utilizzare le condizioni IAM per concedere ruoli a livello di organizzazione o cartella, ma solo per un sottoinsieme di cartelle o progetti.

Passaggi successivi

Scopri come risolvere i problemi dei criteri di autorizzazione che contengono la stringa withcond nei nomi dei ruoli.
Scopri come gestire le associazioni di ruoli in un criterio di autorizzazione.
Panoramica delle condizioni IAM, che utilizzano i criteri di autorizzazione della versione 3.
Esplora gli strumenti Policy Intelligence, che ti consentono di comprendere e gestire i criteri di autorizzazione per migliorare in modo proattivo la tua configurazione di sicurezza.
Utilizza l'API Cloud Asset per utilizzare i criteri di autorizzazione per la ricerca.
Utilizza l'API Cloud Asset per visualizzare i criteri di autorizzazione effettivi.