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

Quando visualizzi un criterio di autorizzazione, potresti vedere nomi dei ruoli 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 prompt . 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 varie forme. Ogni modulo nota come versione dei criteri di autorizzazione.

In un criterio di autorizzazione che utilizza la versione 1, alcune associazioni di ruoli potrebbero contenere il parametro 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, l'associazione del ruolo include una condizione che tu non possono vedere.

Soluzione: specifica la versione 3 del criterio

Per assicurarti di poter visualizzare e aggiornare l'intera norma di autorizzazione, incluse le relative condizioni, devi sempre specificare la versione 3 quando come ottenere o impostare 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 verificarne la versione numero. 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 versioni 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 che supporta consentire 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 all'ultima versione completamente gestita.

    • Se utilizzi una libreria client che non supporta le versioni delle norme consentite, puoi aggiungere un'altra libreria client che supporta le versioni delle norme consentite alla tua applicazione. Utilizza la libreria client per lavorare con i criteri di autorizzazione. In alternativa, puoi utilizzare API REST IAM direttamente.

  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 per impostare un criterio di autorizzazione includono il campo etag nella richiesta

Se uno strumento non soddisfa questi criteri, verifica la presenza di una versione aggiornata del lo strumento a riga di comando gcloud.

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. Per 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. 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, 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. Concede il ruolo Da roles/iam.serviceAccountCreator a vikram@example.com a prescindere dal giorno della settimana. Di conseguenza, la condizione nella prima associazione del ruolo non ha effetto.

Se i tuoi strumenti di gestione tentano di apportare questo tipo di modifica, non approvare il modifica. Devi invece aggiornare gli strumenti di gestione per specificare la versione 3 nelle richieste.

Passaggi successivi