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

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

Questa pagina spiega quando e perché potresti visualizzare la stringa withcond in un criterio di autorizzazione. Inoltre, consiglia le 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 forma è nota 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 dei ruoli è condizionale. In altre parole, il ruolo viene concesso solo se sono soddisfatte determinate condizioni.

I criteri di autorizzazione della versione 1 non mostrano queste condizioni. Se vedi la stringa withcond e un valore hash, la associazione del ruolo 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, compila le attività nelle sezioni seguenti.

Aggiornare 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.

Aggiornare le librerie client

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

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

    • Se utilizzi già una versione recente della libreria client e supporta le versioni delle norme consentite, non devi aggiornarla. 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 aggiungere un'altra libreria client che supporta le versioni dei criteri di autorizzazione alla tua applicazione. Utilizza questa libreria client per lavorare con i criteri di autorizzazione. In alternativa, puoi utilizzare direttamente l'API REST IAM.

  2. Aggiorna qualsiasi codice nell'applicazione che recupera e imposta i criteri di autorizzazione:

Aggiorna le chiamate all'API REST

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

Strumenti di gestione degli aggiornamenti per i criteri

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

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

Se uno strumento non soddisfa questi criteri, controlla 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 ruolo duplicata che non include 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. Utilizzi uno strumento per recuperare il criterio di autorizzazione e memorizzarlo 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, in 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. Utilizzi 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, pertanto ricevi un criterio di autorizzazione 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 il collegamento da vikram@example.com al ruolo roles/iam.serviceAccountCreator è scomparso e che deve ripristinare il collegamento del ruolo originale al criterio di autorizzazione:

Da evitare: associazione di un ruolo aggiuntivo 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
}

Questa modifica non è corretta. Conferisce 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 tentano di apportare questo tipo di modifica, non approvarla. Devi invece aggiornare gli strumenti di gestione per specificare la versione3 nelle richieste.

Passaggi successivi