Resolução de problemas de "withcond" em políticas e associações de funções

Quando vê uma política de permissão, pode ver nomes de funções que incluem a string withcond, seguida de um valor hash. Por exemplo, pode ver um nome de função como roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

Esta página explica quando e por que motivo pode ver a string withcond numa política de permissão. Também recomenda as ações que deve realizar se vir esta string.

Versões de políticas e associações de funções condicionais

Uma política de permissão pode ser representada de várias formas diferentes. Cada formulário é conhecido como uma versão da política de permissão.

Numa política de autorização que usa a versão 1, algumas associações de funções podem conter a string withcond num nome de função, seguida de um valor hash:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/dana@example.com"
      ],
      "role": "roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Este formato indica que a associação de funções é condicional. Por outras palavras, a função só é concedida se forem cumpridas condições específicas.

As políticas de permissão da versão 1 não mostram estas condições. Se vir a string withcond e um valor hash, significa que a associação de funções inclui uma condição que não pode ver.

Solução: especifique a versão 3 da política

Para garantir que pode ver e atualizar toda a política de autorização, incluindo as respetivas condições, tem sempre de especificar a versão 3 quando obtém ou define uma política de autorização. Para especificar a versão 3, conclua as tarefas nas secções seguintes.

Atualize a ferramenta gcloud

Se usar a Google Cloud CLI, execute gcloud version para verificar o número da versão. O resultado inclui uma string semelhante a Google Cloud CLI 279.0.0.

Se o número da versão for inferior a 263.0.0, execute gcloud components update para atualizar a CLI gcloud. Na versão 263.0.0 e posteriores, a CLI gcloud especifica automaticamente uma versão da política de permissão que suporta condições.

Atualize as bibliotecas cliente

Se a sua aplicação usar uma biblioteca de cliente, siga estes passos:

  1. Encontre o nome e o número da versão da biblioteca cliente e, em seguida, verifique a lista de bibliotecas cliente que suportam versões da política de autorização.

    • Se já usar uma versão recente da biblioteca cliente e esta suportar as versões da política de autorização, não precisa de atualizar a biblioteca cliente. Continue para o passo seguinte.

    • Se usar uma versão mais antiga da biblioteca cliente e uma versão posterior suportar versões da política de autorização, atualize a biblioteca cliente para a versão mais recente.

    • Se usar uma biblioteca cliente que não suporte versões da política de permissão, pode adicionar outra biblioteca cliente que suporte versões da política de permissão à sua aplicação. Use essa biblioteca cliente para trabalhar com políticas de autorização. Em alternativa, pode usar a API REST IAM diretamente.

  2. Atualize qualquer código na sua aplicação que obtenha e defina políticas de autorização:

Atualize as chamadas da API REST

Se a sua aplicação usar a API REST IAM diretamente, atualize qualquer código que obtenha e defina políticas de autorização:

Atualize as ferramentas de gestão de políticas

Se mantiver cópias locais das suas políticas de permissão, por exemplo, se as armazenar num sistema de controlo de versões e as tratar como código, certifique-se de que todas as ferramentas que usa cumprem estes critérios:

  • Todos os pedidos para obter ou definir uma política de permissão especificam a versão 3
  • Todos os pedidos para definir uma política de permissão incluem o campo etag no pedido

Se uma ferramenta não cumprir estes critérios, verifique se existe uma versão atualizada da ferramenta.

Além disso, certifique-se de que as suas ferramentas de gestão preservam as concessões de funções condicionais, em vez de adicionar uma concessão de função duplicada que não inclua uma condição. Por exemplo, considere o seguinte cenário:

  1. Concede a função Criar contas de serviço (roles/iam.serviceAccountCreator) ao utilizador Mahan na pasta my-folder. A política de autorização para a pasta tem um aspeto semelhante ao do seguinte exemplo:

    {
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BuFmmMhCsNY=",
  "version": 1
}

  2. Usa uma ferramenta para obter a política de permissão e armazená-la num sistema de controlo de versões.

  3. Adiciona uma condição para que o Mahan possa criar contas de serviço apenas durante a semana de trabalho normal, com base na data e hora em Berlim, Alemanha. A política de permissão atualizada é semelhante a este exemplo:

    {
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/mahan@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. Usa uma ferramenta para obter a política de permissão atualizada. A ferramenta não especifica uma versão da política de autorização quando pede a política de autorização, pelo que recebe uma política de autorização da versão 1 com um nome de função modificado:

    {
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

Neste ponto, a ferramenta de gestão pode decidir que a associação de Mahan à função roles/iam.serviceAccountCreator desapareceu e que deve restaurar a associação de funções original à política de autorização:

Evite: associação de funções adicional sem condição

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

Esta alteração não está correta. Concede a função roles/iam.serviceAccountCreator a Mahan, independentemente do dia da semana. Como resultado, a condição na primeira associação de funções não tem efeito.

Se as suas ferramentas de gestão tentarem fazer este tipo de alteração, não aprove a alteração. Em alternativa, tem de atualizar as suas ferramentas de gestão para especificar a versão 3 nos pedidos.

O que se segue?