Noções básicas sobre políticas

O controle de acesso aos recursos do Google Cloud é gerenciado pelas políticas do IAM. Uma política do IAM é anexada a um recurso. A política gerencia o acesso ao próprio recurso, bem como a qualquer recurso filho por meio da herança de políticas.

Neste tópico, fornecemos exemplos do JSON de políticas do IAM, embora o YAML também seja compatível.

Estrutura da política

Uma política é um conjunto de vinculações, configurações de auditoria e metadados. Uma vinculação especifica como conceder o acesso aos recursos. Ela associa (ou vincula) um ou mais membros a um único papel e qualquer condição específica do contexto que altera como e quando o papel é concedido. O campo AuditConfig especifica os dados de configuração do modo como deve ser feita a auditoria das tentativas de acesso. Os metadados incluem informações extras sobre a política, como ETag e versão, para facilitar o gerenciamento de políticas. Veja a seguir a descrição de cada parte:

  • Uma lista de vinculações. Cada vinculação inclui os seguintes campos:
    • Um membro, também conhecido como identidade ou principal, pode ser uma conta de usuário, uma conta de serviço, um Grupo do Google ou um domínio.
    • Um papel é um conjunto nomeado de permissões que concedem acesso para executar ações nos recursos do Google Cloud.
    • Uma condição é uma expressão lógica que restringe ainda mais a vinculação do papel com base nos atributos sobre a solicitação, como a origem, o recurso de destino etc. As condições normalmente são usadas para controlar se o acesso é concedido com base no contexto de uma solicitação.
  • Um campo AuditConfig, que é usado para configurar a geração de registros de auditoria da política.
  • Metadados, que incluem os seguintes campos:
    • Um campo etag, que é usado para controle de simultaneidade e garante que as políticas sejam atualizadas de modo consistente.
    • Um campo version, que especifica a versão do esquema de uma determinada política. O uso do campo version é explicado em mais detalhes na seção versões da política.

Uma vinculação de papel em uma política do IAM é a combinação do papel com uma lista de membros. Se uma vinculação de papel também incluir uma condição, ela será especificada como condicional.

Como usar ETags em uma política

Quando vários sistemas tentam gravar na mesma política do IAM ao mesmo tempo, há um risco de que esses sistemas substituam as alterações uns dos outros. Esse risco existe porque a atualização de uma política do IAM envolve várias operações:

  1. Leitura da política existente
  2. Modificação da política
  3. Gravação de toda a política

Se o sistema A ler uma política e o sistema B gravar imediatamente uma versão atualizada dessa política, o sistema A não conhecerá as alterações do sistema B. Quando o sistema A grava as próprias alterações na política, as alterações do sistema B podem ser perdidas.

Para ajudar a evitar esse problema, o gerenciamento de identidade e acesso (IAM, na sigla em inglês) é compatível com o controle de simultaneidade por meio de um campo etag na política. O valor desse campo é alterado sempre que uma política é atualizada.

Sempre que você precisar atualizar uma política, inclua o campo etag ao gravar a política atualizada. Se a política tiver sido modificada desde que você a recuperou, etag não será correspondente, e haverá falha na atualização. Para a API REST, você recebe o código de status HTTP 409 Conflict e o corpo da resposta é semelhante ao seguinte:

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

Se você receber esse erro, repita toda a série de operações: leia a política novamente, modifique-a conforme necessário e grave a política atualizada. Execute novas tentativas automaticamente, com espera exponencial, em qualquer ferramenta usada para gerenciar políticas do IAM.

Para saber como atualizar políticas usando o padrão leitura-modificação-gravação, veja Como conceder, alterar e revogar acesso.

Exemplo: política simples

Considere o seguinte exemplo de política que vincula um membro a um papel:

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

No exemplo acima, jie@example.com recebe o papel básico de Proprietário sem nenhuma condição. Esse papel fornece um acesso quase ilimitado a jie@example.com.

Exemplo: política com várias vinculações

Considere a seguinte política de exemplo que contém mais de uma vinculação. Cada vinculação concede um papel diferente:

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

No exemplo acima, Jie (jie@example.com) recebeu o papel predefinido Administrador da organização (roles/resourcemanager.organizationAdmin) na primeira vinculação de papel. Esse papel contém permissões para organizações, pastas e operações de projetos limitadas. Na segunda vinculação de papéis, Jie e Divya (divya@example.com) receberam a capacidade para criar projetos por meio do papel Criador de projetos (roles/resourcemanager.projectCreator). Juntas, essas vinculações concedem acesso refinado a Jie e Divya, em que o acesso concedido a Divya é o subconjunto do acesso concedido a Jie.

Exemplo: política com vinculação de papel condicional

Considere a seguinte política do IAM, que vincula membros a um papel predefinido e usa uma expressão de condição para restringir a vinculação de papel:

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

Neste exemplo, o campo version está definido como 3, porque a política contém uma expressão de condição. A vinculação na política é uma vinculação de papel condicional. Ela concede o papel ao grupo do Google prod-dev@example.com e à conta de serviço prod-dev-example@appspot.gserviceaccount.com, mas somente até 1º de julho de 2020.

Saiba mais sobre os recursos compatíveis com cada versão da política em Versões da política nesta página.

Exemplo: política com vinculações de papéis condicionais e não condicionais

Considere a seguinte política do IAM, que contém vinculações de papel condicionais e não condicionais para o mesmo papel:

{
  "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_2020",
        "description": "Expires on July 1, 2020",
        "expression":
          "request.time < timestamp('2020-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Neste exemplo, a conta de serviço serviceAccount:prod-dev-example@appspot.gserviceaccount.com está incluída em duas vinculações de papel para o mesmo papel. A primeira vinculação não tem uma condição. A segunda vinculação tem uma condição que só concede o papel até 1º de julho de 2020.

Efetivamente, essa política sempre concede o papel à conta de serviço. No IAM, as vinculações de papel condicionais não modificam as vinculações de papel sem condições. Se um membro estiver vinculado a um papel e a vinculação de papel não tiver uma condição, o membro sempre terá esse papel. Adicionar o membro a uma vinculação condicional para o mesmo papel não tem efeito.

Por outro lado, o grupo do Google group:prod-dev@example.com é incluído apenas na vinculação de papel condicional. Portanto, ele tem o papel somente antes de 1º de julho de 2020.

Exemplo: política que vincula um papel a um membro excluído

Considere o exemplo de política a seguir. Esta política vincula um papel a um usuário, donald@example.com, cuja conta foi excluída:

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

Se você criar um novo usuário chamado donald@example.com, as vinculações da política ao usuário excluído não serão aplicadas ao novo usuário. Esse comportamento impede que novos usuários herdem papéis concedidos a usuários excluídos. Se quiser conceder papéis ao novo usuário, adicione-o às vinculações da política, conforme mostrado em Políticas com membros excluídos nesta página.

Além disso, o nome do usuário agora inclui o prefixo deleted: e o sufixo ?uid=numeric-id, em que numeric-id é o ID numérico exclusivo do usuário excluído. Neste exemplo, em vez de user:donald@example.com, a política mostra o identificador deleted:user:donald@example.com?uid=123456789012345678901.

As contas de serviço e os grupos têm o mesmo comportamento dos usuários. Se você excluir uma conta de serviço ou um grupo e visualizar uma política que inclua esse membro, o nome do membro excluído terá o prefixo deleted: e o sufixo ?uid=numeric-id.

Limitações da política

As seguintes limitações aplicam-se às políticas do IAM:

  • Cada recurso do Google Cloud compatível com uma política do IAM no respectivo nível da hierarquia de recursos pode ter no máximo uma política. Por exemplo, organizações, pastas, projetos ou recursos individuais, como discos, imagens e outros elementos do Compute Engine.
  • Cada política do IAM pode conter até 1.500 members. Até 250 desses membros podem ser grupos do Google.

    O IAM conta todas as ocorrências de cada membro nas vinculações da política. Ele não elimina membros duplicados que aparecem em mais de uma vinculação. Por exemplo, se o membro user:alice@example.com aparece em 50 vinculações, é possível adicionar outros 1.450 membros a todas as vinculações da política.

  • Em geral, qualquer alteração na política entrará em vigor dentro de 60 segundos após a chamada de setIamPolicy() ou por meio da atualização de uma vinculação de papel no Console do Cloud. No entanto, em determinadas circunstâncias, pode levar até sete minutos para que as alterações nas políticas sejam totalmente propagadas por todo o sistema.

  • No momento, alguns serviços do Google Cloud não são compatíveis com vinculações de papéis condicionais em políticas no nível do recurso, mesmo que o nome, o tipo ou o Google Cloud do recurso possa ser usado em uma vinculação de papel condicional. Por exemplo, em alguns casos, uma política com uma vinculação de papel condicional que restringe o acesso ao recurso de um serviço pode ser definida no projeto, mas não no próprio recurso. Para detalhes, consulte a referência do atributo "Condições do IAM".

Herança de política e hierarquia de recursos

Os recursos do Google Cloud são organizados de modo hierárquico. O nó da organização é a raiz da hierarquia, seguido, opcionalmente, das pastas e depois dos projetos. A maioria dos outros recursos é criada e gerenciada em um projeto. Cada recurso tem exatamente um pai, exceto o nó raiz da hierarquia. Consulte o tópico Hierarquia de recursos para mais informações.

É importante considerar a hierarquia de recursos ao definir uma política do IAM. Ao definir uma política em um nível superior na hierarquia, como no nível da organização, da pasta ou para envolvidos no projeto, o escopo de acesso concedido inclui o nível do recurso a que essa política está anexada e todos os recursos abaixo desse nível. Por exemplo, uma política definida no nível da organização aplica-se à organização e a todos os recursos dela. Do mesmo modo, uma política definida para envolvidos no projeto aplica-se ao projeto e a todos os recursos dele.

Herança de política é o termo que descreve como as políticas são aplicadas aos recursos abaixo do nível deles na hierarquia de recursos. Política efetiva é o termo que descreve como todas as políticas pai na hierarquia de recursos são herdadas em um recurso. É a união dos seguintes itens:

  • A política definida no recurso
  • As políticas definidas em todos os níveis ancestrais do recurso na hierarquia

Cada nova vinculação de papel (herdada dos recursos pai) que afeta a política efetiva do recurso é avaliada de modo independente. Uma solicitação de acesso específica ao recurso será concedida se qualquer uma das vinculações de papel de nível superior conceder acesso à solicitação.

Se uma nova vinculação de papel for incluída em qualquer nível da política herdada do recurso, o escopo de concessão de acesso aumentará.

Exemplo: herança de política

Para entender a herança de política, considere o seguinte exemplo de política definido no nível da organização:

Política no nível da organização

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

O papel de Leitor de objetos do Storage (roles/storage.objectViewer) contém as permissões get e list para projetos e objetos do Cloud Storage. Quando definida no nível da organização, essa vinculação de papel é aplicada aos níveis abaixo da organização, incluindo todos os projetos e todos os objetos do Cloud Storage nesses projetos.

Para demonstrar melhor a herança de política, considere o que acontece quando uma política é posteriormente definida em myproject-123:

Política para envolvidos no projeto

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

No exemplo acima, o papel Criador de objetos do Storage (roles/storage.objectCreator) concede a Divya a capacidade de criar objetos do Cloud Storage em myproject-123. Agora que há duas vinculações de papel que concedem ao Divya acesso aos objetos de destino do Cloud Storage em myproject-123, as seguintes políticas se aplicam:

  • Uma política no nível da organização concede a capacidade de listar e acessar todos os objetos do Cloud Storage nessa organização
  • Uma política para envolvidos no projeto, para o projeto myproject-123, concede a capacidade de criar objetos nesse projeto.

A tabela abaixo resume a política efetiva de Divya:

Permissões concedidas por meio do papel "storage.objectViewer" no nível da organização Permissões concedidas por meio do papel "storage.objectCreator" em "myproject-123" Escopo de concessão efetivo para Divya em "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

Versões da política

Ao longo do tempo, o IAM pode adicionar novos recursos que adicionam ou alteram significativamente os campos no esquema da política. Para evitar a interrupção das integrações atuais que dependem da consistência na estrutura da política, essas alterações são incluídas em novas versões do esquema da política.

Se você estiver fazendo a integração com o IAM pela primeira vez, recomendamos usar a versão mais recente do esquema de políticas disponível no momento. A seguir, explicaremos as diferentes versões disponíveis e como usar cada uma delas. Descreveremos também como especificar a versão pretendida e orientaremos você por alguns cenários de solução de problemas.

Cada política atual do IAM especifica um campo version como parte dos metadados dela. Considere a parte destacada abaixo:

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

Nesse campo, especificamos a versão do esquema de sintaxe da política. Cada versão da política contém um esquema de sintaxe específico que pode ser usado pelas vinculações. A versão mais recente pode conter vinculações de papel com o esquema de sintaxe mais recente que não é compatível com as versões anteriores. Esse campo não deve ser usado para outras finalidades além do controle do esquema de sintaxe da política.

Versões válidas de política

As políticas do IAM podem usar as seguintes versões de política:

Versão Descrição
1 A primeira versão do esquema de sintaxe do IAM para políticas. Permite vincular um papel a um ou mais membros. Não é compatível com vinculações de papéis condicionais.
2 Reservado para uso interno.
3 Insere o campo condition na vinculação de papel, o que a restringe por meio das regras baseadas em contexto e em atributos. Para mais informações, consulte a visão geral das condições do IAM.

Como especificar a versão ao receber uma política

Para a API REST e as bibliotecas de cliente, quando você receber uma política do IAM, recomendamos que especifique uma versão da política na solicitação. Quando uma solicitação especifica a versão de uma política, o IAM supõe que o autor da chamada conhece os recursos dessa versão da política e que pode processá-los corretamente.

Se a solicitação não especifica a versão da política, o IAM pressupõe que o autor da chamada quer a versão 1 da política.

Quando você recebe uma política, o IAM verifica a versão da política na solicitação ou a versão padrão se a solicitação não tiver especificado a versão. O IAM também verifica a política em busca de campos que não sejam compatíveis com a versão 1 da política. Ele usa essas informações para decidir que tipo de resposta enviar:

  • Se a política não contiver condições, o IAM sempre retornará a versão 1 da política, independentemente do número da versão na solicitação.
  • Se a política contiver condições e o autor da chamada tiver solicitado a versão 3 da política, o IAM retornará uma versão 3 da política que inclua as condições. Veja um exemplo no cenário 1 nesta página.
  • Se a política contiver condições e o autor da chamada tiver solicitado uma versão 1 da política ou não tiver especificado uma versão, o IAM retornará a versão 1 da política.

    Para vinculações de papel que incluam uma condição, o IAM anexa a string _withcond_ ao nome do papel, seguido de um valor de hash. Por exemplo, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. A condição em si não está presente. Veja um exemplo no cenário 2 nesta página.

Esse comportamento evita problemas com bibliotecas de cliente anteriores que desconhecem vinculações de papéis condicionais. Saiba mais em Suporte à biblioteca de cliente para versões de política nesta página.

Cenário 1: versão da política totalmente compatível com as Condições do IAM

Suponha que você chame o seguinte método da API REST para receber a política do IAM de um projeto:

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

O corpo da solicitação contém o seguinte texto:

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

A resposta contém a política do IAM do projeto. Se a política contiver pelo menos uma vinculação de papel condicional, o campo version será definido como 3:

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

Se a política não contiver vinculações de papéis condicionais, o campo version será definido como 1, mesmo que a solicitação tenha especificado a versão 3:

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

Cenário 2: versão da política com suporte limitado para as Condições do IAM

Suponha que você chame o seguinte método da API REST para receber a política do IAM de um projeto:

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

O corpo da solicitação está vazio, não especifica o número da versão. Como resultado, o IAM usa a versão padrão da política, 1.

A política contém uma vinculação de papel condicional. Como a versão da política é 1, a condição não aparece na resposta. Para indicar que a vinculação de papel usa uma condição, o IAM anexa a string _withcond_ ao nome do papel, seguido de um valor de hash:

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

Como especificar a versão ao definir uma política

Ao definir uma política do IAM, recomendamos que você especifique uma versão da política na solicitação. Quando uma solicitação especifica a versão de uma política, o IAM supõe que o autor da chamada conhece os recursos dessa versão da política e que pode processá-los corretamente.

Se a solicitação não especificar uma versão de política, o IAM permitirá apenas os campos que podem aparecer em uma política de versão 1. Como prática recomendada, não altere as vinculações de papéis condicionais na versão 1 da política. Como a política não mostra a condição de cada vinculação, não é possível saber quando ou onde a vinculação é realmente concedida. Em vez disso, consiga a versão 3 da representação da política, que mostra a condição de cada vinculação e use essa representação para atualizar as vinculações.

Cenário: versões da política em solicitações e respostas

Suponha que você use a API REST para receber uma política do IAM e especifique a versão 3 na solicitação. A resposta contém a seguinte política, que usa a versão 3:

{
  "bindings": [
    {
      "members": [
        "user:divya@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
}

Você decide que divya@example.com precisa ter o papel de Administrador do Storage (roles/storage.admin) a semana inteira, e não apenas em dias úteis. Você remove a condição da vinculação de papel e envia uma solicitação da API REST para definir a política. Mais uma vez, você especifica a versão 3 na solicitação:

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

A resposta contém a política atualizada:

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

A política na resposta usa a versão 1, mesmo que a solicitação tenha especificado a versão 3, porque a política só usa campos compatíveis na versão 1 da política.

Compatibilidade de bibliotecas de cliente com versões de política

Algumas bibliotecas de cliente do Google Cloud só são compatíveis com a versão 1 das políticas. Se sua biblioteca de cliente não for compatível com versões posteriores de políticas, você não poderá usar recursos disponíveis apenas em versões posteriores. Por exemplo, as condições do IAM exigem compatibilidade com a versão da política 3.

Se você usar recursos do IAM que não estão disponíveis nas políticas da versão 1, como as condições do IAM, use uma biblioteca de cliente que seja compatível com essa versão da política e a defina corretamente na solicitação.

Estas bibliotecas de cliente das APIs do Google para o IAM são compatíveis com a versão 3 da política:

Idioma Versões compatíveis com a versão 3 da política
C# Google.Apis >=v1.41.1
Go google-api-go-client >=v0.10.0
Java
Node.js googleapis >=v43.0.0
PHP google/apiclient >=v2.4.0
Python google-api-python-client >=v1.7.11
Ruby google-api-client >=v0.31.0

É possível usar essas bibliotecas de cliente para gerenciar as políticas do IAM da versão 3 nos recursos dos serviços a seguir:

  • IAM
  • Cloud KMS
  • Cloud Storage
  • Compute Engine
  • Resource Manager

Outras bibliotecas de cliente, incluindo as bibliotecas de cliente do Google Cloud, só são compatíveis com a versão 1 das políticas.

Compatibilidade do gcloud com versões de política

Se você usa a ferramenta gcloud para gerenciar políticas do IAM, verifique se está usando a versão 263.0.0 ou posterior. As versões anteriores só são compatíveis com a versão 1 das políticas.

Para verificar o número da versão da ferramenta gcloud, execute gcloud version. Para atualizar para a versão mais recente, execute gcloud components update.

Políticas com membros excluídos

Se uma vinculação de uma política incluir um membro excluído e você adicionar uma vinculação a um novo membro com o mesmo nome, a vinculação será sempre aplicada ao novo membro.

Por exemplo, considere esta política que inclui uma vinculação a um usuário excluído, donald@example.com, e a uma conta de serviço excluída, my-service-account@project-id.iam.gserviceaccount.com:

{
  "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
}

Suponha que você crie um novo usuário chamado donald@example.com e queira vincular o novo usuário ao papel Criador de projetos (roles/resourcemanager.projectCreator), o que permite que os usuários criem projetos do Google Cloud. Para vincular o novo usuário, atualize a política conforme mostrado neste exemplo:

{
  "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
}

Para facilitar a auditoria das políticas de IAM, também é possível remover o usuário excluído da vinculação ao papel de proprietário:

{
  "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
}

Práticas recomendadas de política

As seguintes práticas recomendadas se aplicam a organizações com muitos usuários do Google Cloud:

  • Ao gerenciar várias contas de usuário com as mesmas configurações de acesso, use os Grupos do Google. Coloque cada conta de usuário individual no grupo e conceda os papéis pretendidos ao grupo, em vez das contas de usuário individuais.

  • Permissões concedidas no nível da organização: considere cuidadosamente quais membros recebem permissões de acesso no nível da organização. Para a maioria das organizações, apenas algumas equipes específicas, como as de segurança e de rede, devem receber acesso a esse nível da hierarquia de recursos.

  • Permissões concedidas nos níveis de pasta: represente a estrutura da operação da sua organização usando camadas de pastas. Cada pasta pai/filho pode ser configurada com diferentes conjuntos de concessões de acesso, alinhados às necessidades dos negócios e das operações. Por exemplo, uma pasta pai pode representar um departamento, uma de suas pastas filho pode representar o acesso e a operação de recursos por um grupo e outra pasta filho pode representar uma equipe pequena. Essas duas pastas podem incluir projetos de acordo com as necessidades operacionais da equipe. Ao usar as pastas dessa maneira, é possível garantir a separação adequada do acesso, respeitando as políticas herdadas da(s) pasta(s) pai e da organização. Essa prática requer menos manutenção de política ao criar e gerenciar os recursos do Google Cloud.

  • Permissões concedidas para envolvidos no projeto: atribua vinculações de papel para envolvidos no projeto somente conforme exigido a grupos específicos ou permissões granulares individuais. Para facilitar o gerenciamento, especialmente com muitos projetos, é altamente recomendável definir políticas no nível da pasta, quando possível.

A seguir