Risoluzione dei problemi relativi a "withcond" nei criteri e nei binding dei ruoli.

Quando visualizzi un criterio di autorizzazione, potresti vedere i nomi dei ruoli che includono la stringa withcond, seguita da un valore hash. Ad esempio, potresti vedere il nome di un ruolo come roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

Questa pagina spiega quando e perché potresti vedere la stringa withcond in un criterio di autorizzazione. Inoltre, ti consiglia azioni da intraprendere se vedi questa stringa.

Versioni dei criteri e associazioni di ruoli condizionali

Un criterio di autorizzazione può essere rappresentato in diverse forme. Ogni modulo è noto come versione del criterio di autorizzazione.

In un criterio di autorizzazione che utilizza la versione 1, alcune associazioni di ruoli potrebbero contenere la stringa withcond in un nome di ruolo, seguita da un valore hash:

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

Questo formato indica che l'associazione del ruolo è conditional. In altre parole, il ruolo viene concesso solo se vengono soddisfatte determinate condizioni.

I criteri di autorizzazione della versione 1 non mostrano queste condizioni. Se vedi la stringa withcond e un valore hash, l'associazione dei ruoli include una condizione che non puoi vedere.

Soluzione: specifica la versione 3 del criterio

Per assicurarti di poter visualizzare e aggiornare l'intero criterio di autorizzazione, incluse le sue condizioni, devi sempre specificare la versione 3 quando ricevi o imposti un criterio di autorizzazione. Per specificare la versione 3, completa le attività nelle sezioni seguenti.

Aggiorna lo strumento gcloud

Se utilizzi Google Cloud CLI, esegui gcloud version per controllare il numero di versione. L'output include una stringa simile a Google Cloud CLI 279.0.0.

Se il numero di versione è inferiore a 263.0.0, esegui gcloud components update per aggiornare gcloud CLI. Nella versione 263.0.0 e successive, gcloud CLI specifica automaticamente una versione del criterio di autorizzazione che supporta le condizioni.

Aggiornamento delle librerie client

Se la tua applicazione utilizza una libreria client, segui questi passaggi:

  1. Trova il nome e il numero di versione della libreria client, quindi controlla l'elenco di librerie client che supportano le versioni dei criteri di autorizzazione.

    • Se utilizzi già una versione recente della libreria client che supporta l'autorizzazione delle versioni dei criteri, non è necessario aggiornare la libreria client. Vai al passaggio successivo.

    • Se utilizzi una versione precedente della libreria client e una versione successiva supporta le versioni dei criteri di autorizzazione, aggiorna la libreria client alla versione più recente.

    • Se utilizzi una libreria client che non supporta le versioni dei criteri di autorizzazione, puoi aggiungerne un'altra alla tua applicazione. Puoi utilizzare questa libreria client per gestire i criteri di autorizzazione. In alternativa, puoi utilizzare direttamente l'API REST IAM.

  2. Aggiorna qualsiasi codice nella tua applicazione che riceve e imposta criteri di autorizzazione:

Aggiorna chiamate API REST

Se la tua applicazione utilizza direttamente l'API REST IAM, aggiorna qualsiasi codice che riceve e imposta i criteri di autorizzazione:

Aggiorna gli strumenti di gestione per i criteri

Se conservi copie locali dei tuoi criteri di autorizzazione, ad esempio se li archivi in un sistema di controllo della versione e li tratti come codice, assicurati che tutti gli strumenti che utilizzi soddisfino i seguenti criteri:

  • Tutte le richieste per ottenere o impostare un criterio di autorizzazione specificano la versione 3
  • Tutte le richieste per impostare un criterio di autorizzazione includono il campo etag nella richiesta

Se uno strumento non soddisfa questi criteri, verifica se è disponibile una versione aggiornata dello strumento.

Inoltre, assicurati che i tuoi strumenti di gestione conservino le concessioni di ruoli condizionali, anziché aggiungere una concessione di ruoli duplicata che non includa una condizione. Ad esempio, considera il seguente scenario:

  1. Concedi il ruolo Crea account di servizio (roles/iam.serviceAccountCreator) all'utente vikram@example.com nella cartella my-folder. Il criterio di autorizzazione per la cartella è simile a questo esempio:

    {
      "bindings": [
        {
          "members": [
            "user:vikram@example.com"
          ],
          "role": "roles/iam.serviceAccountCreator"
        }
      ],
      "etag": "BuFmmMhCsNY=",
      "version": 1
    }
  2. Puoi utilizzare uno strumento per recuperare il criterio di autorizzazione e archiviarlo in un sistema di controllo della versione.

  3. Aggiungi una condizione in modo che vikram@example.com possa creare account di servizio solo durante la normale settimana lavorativa, in base alla data e all'ora di Berlino, Germania. Il criterio di autorizzazione aggiornato è simile a questo esempio:

    {
      "bindings": [
        {
          "members": [
            "user:vikram@example.com"
          ],
          "role": "roles/iam.serviceAccountCreator",
          "condition": {
            "title": "work_week_only",
            "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
          }
        }
      ],
      "etag": "BwWcR/B3tNk=",
      "version": 3
    }
  4. Puoi utilizzare uno strumento per recuperare il criterio di autorizzazione aggiornato. Lo strumento non specifica una versione del criterio di autorizzazione quando richiede il criterio di autorizzazione, quindi ricevi un criterio di autorizzazione della versione 1 con un nome del ruolo modificato:

    {
      "bindings": [
        {
          "members": [
            "user:vikram@example.com"
          ],
          "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
        }
      ],
      "etag": "BwWcR/B3tNk=",
      "version": 1
    }

A questo punto, lo strumento di gestione potrebbe decidere che l'associazione da vikram@example.com al ruolo roles/iam.serviceAccountCreator è scomparsa e dovrebbe ripristinare l'associazione originale del ruolo al criterio di autorizzazione:

Evita: associazione di ruoli aggiuntivi senza condizione

{
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

La modifica non è corretta. Concede il ruolo roles/iam.serviceAccountCreator a vikram@example.com indipendentemente dal giorno della settimana. Di conseguenza, la condizione nella prima associazione del ruolo non ha alcun effetto.

Se i tuoi strumenti di gestione cercano di apportare questo tipo di modifica, non approvarla. Devi invece aggiornare i tuoi strumenti di gestione per specificare la versione 3 nelle richieste.

Passaggi successivi