Como funcionam as políticas de permissão

É possível conceder acesso a recursos do Google Cloud com políticas de permissão, também conhecidas como políticas do Identity and Access Management (IAM), anexadas aos recursos. É possível anexar apenas uma política a cada recurso. A política de permissão controla o acesso ao próprio recurso e todos os descendentes desse recurso que herdam a política.

Esta página mostra as políticas de permissão no formato JSON. Também é possível usar a Google Cloud CLI para recuperar políticas de permissão em formato YAML.

Estrutura da política

Uma política de permissão é um conjunto de vinculações de papéis e metadados. Uma vinculação de papel especifica qual acesso precisa ser concedido a um recurso. Ela associa (ou vincula) um ou mais principais a um único papel de IAM e qualquer condição específica do contexto que altere como e quando o papel é concedido. Os metadados incluem informações extras sobre a política de permissão, como ETag e versão, para facilitar o gerenciamento de políticas.

Cada vinculação de papel pode incluir os seguintes campos:

  • Um ou mais principais, também conhecidos como membros ou identidades. Há vários tipos de principais, incluindo contas de usuário, contas de serviço, grupos do Google e domínios. Para ver uma lista completa dos tipos de principais compatíveis, consulte Identificadores principais.
  • Um papel, que é um conjunto nomeado de permissões que oferecem a capacidade de executar ações nos recursos do Google Cloud.

  • Uma condição, que é uma expressão lógica opcional que restringe ainda mais a vinculação do papel com base em atributos sobre a solicitação, como a origem ou o recurso de destino. As condições normalmente são usadas para controlar se o acesso é concedido com base no contexto de uma solicitação.

    Se uma vinculação de papel também incluir uma condição, ela será referenciada como vinculação condicional de papel.

    Alguns serviços do Google Cloud não aceitam condições nas políticas de permissão. Para ver uma lista de serviços e tipos de recursos que aceitam condições, consulte Tipos de recursos que aceitam vinculações condicionais de papéis.

As mudanças no acesso de um principal são consistentes posteriores. Isso significa que leva algum tempo para que as mudanças no acesso se propaguem pelo sistema. Para saber quanto tempo leva, em média, para as alterações de acesso propagadas, consulte Acesso à propagação de mudança.

Limites para principais

Cada política de permissão pode conter até 1.500 principais. Para esse limite, o IAM conta todas as aparências de cada principal nas vinculações de papéis da política de permissão, bem como nos principais que a política de permissão isenta da geração de registros de auditoria de acesso a dados. Ele não elimina participantes duplicados que aparecem em mais de uma vinculação de papel. Por exemplo, se uma política de permissão contiver apenas vinculações de papéis para o principal group:my-group@example.com e este principal aparecer em 50 vinculações de papéis, será possível adicionar mais 1.450 principais às vinculações de papéis na política de permissão.

Até 250 dos principais em uma política de permissão podem ser domínios e Grupos do Google. Para os fins desse limite, os domínios e os Grupos do Google são contados da seguinte forma:

  • Para domínios, o IAM conta todas as ocorrências de cada domínio nas vinculações de papel da política de permissão. Ele não elimina domínios duplicados que aparecem em mais de uma vinculação. Por exemplo, se uma política de permissão contiver apenas um domínio, domain:example.com, e o domínio aparecer na política de permissão 10 vezes, será possível adicionar mais 240 domínios antes de atingir o limite.
  • Para os grupos do Google, cada grupo exclusivo é contado apenas uma vez, independentemente de quantas vezes o grupo aparecer na política de permissão. Por exemplo, se uma política de permissão contiver apenas um grupo, group:my-group@example.com, e o grupo aparecer na política de permissão 10 vezes, você poderá adicionar mais 249 grupos exclusivos antes de atingir o limite.

Se você usar as Condições do IAM ou conceder papéis a muitos principais com identificadores longos, pode ser que o IAM permita menos principais na política.

Metadados da política

Os metadados de uma política de permissão incluem os campos a seguir:

  • Um campo etag, usado para controle de simultaneidade e garantir que as políticas de permissão sejam atualizadas de modo consistente. Para mais detalhes, consulte Como usar ETags em uma política nesta página.
  • Um campo version, que especifica a versão do esquema de uma determinada política de permissão. Para mais detalhes, consulte Versões da política nesta página.

Para organizações, pastas, projetos e contas de faturamento, a política de permissão também pode conter um campo auditConfig, que especifica os tipos de atividade que geram registros de auditoria para cada serviço. Para saber como configurar essa parte de uma política de permissão, consulte Como configurar registros de auditoria de acesso a dados.

Como usar ETags em uma política

Quando vários sistemas tentam gravar na mesma política de permissão ao mesmo tempo, há um risco de que esses sistemas substituam as alterações uns dos outros. Esse risco existe porque as políticas de permissão são atualizadas usando o padrão ler-modificar-gravar, que envolve várias operações:

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

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

Para evitar esse problema, o Identity and Access Management (IAM) é compatível com o controle de simultaneidade com o uso de um campo etag na política de permissão. Cada política de permissão contém um campo de etag, e o valor desse campo muda sempre após uma atualização. Se uma política de permissão contiver um campo etag, mas nenhuma vinculação de papel, a política não concederá papéis do IAM.

O campo etag contém um valor como BwUjMhCsNvY=. Ao atualizar, inclua o campo etag na política de permissão 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 de permissão.

Exemplo: política simples

Considere o seguinte exemplo de política de permissão que vincula um principal 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 de papel

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

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@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 papel, Jie e Raha (raha@example.com) receberam permissão para criar projetos com o papel de Criador do projeto (roles/resourcemanager.projectCreator). Juntas, essas vinculações de papel concedem acesso refinado a Jie e Raha, e Jie recebe mais acesso do que Raha.

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

Considere a seguinte política de permissão, que vincula principais 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_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Neste exemplo, o campo version está definido como 3, porque a política de permissão contém uma expressão de condição. A vinculação de papel na política é 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 2022.

Saiba mais sobre os recursos compatíveis com cada versão da política de permissão 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 de permissão, 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_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-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 para o mesmo papel. A primeira vinculação de papel não tem uma condição. A segunda vinculação tem uma condição que só concede o papel até 1º de julho de 2022.

Efetivamente, essa política de permissão 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 participante estiver vinculado a um papel e a vinculação de papel não tiver uma condição, o participante sempre terá esse papel. Adicionar o participante 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 2022.

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

Considere a seguinte política de permissão. Esta política vincula um papel a um usuário, donald@example.com, cuja conta foi excluída: Como resultado, o identificador do usuário agora tem um prefixo deleted::

{
  "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 do papel da política de permissão do usuário excluído não se aplicarão 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 de permissão, 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 de permissão 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 de permissão que inclua esse principal, o nome do principal excluído terá o prefixo deleted: e o sufixo ?uid=numeric-id.

Políticas padrão

Todos os recursos que aceitam políticas de permissão são criados com políticas de permissão padrão. As políticas de permissão padrão da maioria dos recursos estão vazias. No entanto, as políticas de permissão padrão de alguns deles contêm, automaticamente, determinadas vinculações de papéis. Por exemplo, quando você cria um novo projeto, a política de permissão dele tem automaticamente uma vinculação que concede a você o papel Proprietário (roles/owner) no projeto.

Essas vinculações de papel são criadas pelo sistema. Portanto, o usuário não precisa das permissões getIamPolicy ou setIamPolicy no recurso para que as vinculações de papel sejam criadas.

Para saber se um recurso foi criado com uma política de permissão, consulte a documentação correspondente.

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 a organização. A organização, como nó raiz na hierarquia, não tem pai. Consulte o tópico Hierarquia de recursos para mais informações.

É importante considerar a hierarquia de recursos ao definir uma política de permissão em um nível superior na hierarquia, como no nível da organização, da pasta ou para envolvidos no projeto, porque 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 de permissão definida no nível da organização aplica-se à organização e a todos os recursos dela. Da mesma forma, uma política de permissão definida no nível do projeto se aplica ao projeto e a todos os recursos dele.

Herança de política é o termo que descreve como as políticas de permissão 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 de permissão pai na hierarquia de recursos são herdadas em um recurso. É a união dos seguintes itens:

  • A política de permissão definida no recurso
  • As políticas de permissão 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 de permissão 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 de permissão, considere um cenário em que você concede a um usuário, Raha, dois papéis do IAM diferentes em dois níveis distintos na hierarquia de recursos.

Para conceder a Raha um papel no nível da organização, defina a seguinte política de permissão na organização:

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

Esta política concede a Raha o papel de Leitor de objetos do Storage (roles/storage.objectViewer), que contém permissões get e list para projetos e objetos do Cloud Storage. Como você definiu a política na organização, Raha poderá usar essas permissões para todos os projetos e todos os objetos do Cloud Storage na organização.

Para conceder um papel a Raha no nível do projeto, defina a seguinte política de permissão no projeto myproject-123:

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

Esta política concede a Raha o papel Criador de objetos do Storage (roles/storage.objectCreator), que permite criar objetos do Cloud Storage. Como você definiu a política em myproject-123, Raha poderá criar objetos do Cloud Storage apenas 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 de permissão se aplicam:

  • Uma política de permissão 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 de permissão no nível do projeto myproject-123 concede a capacidade de criar objetos nesse projeto.

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

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 Raha 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 de permissão. Para evitar a interrupção das integrações atuais que dependem da consistência na estrutura da política de permissão, 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, é recomendável usar a versão mais recente do esquema de políticas de permissão 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ê em alguns cenários de solução de problemas.

Cada política de permissão atual especifica um campo version como parte dos metadados. 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 de permissão. Cada versão da política contém um esquema de sintaxe específico que pode ser usado pelas vinculações de papel. 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. Este campo não pode ser usado para nenhuma outra finalidade que não seja controlar o esquema de sintaxe da política de permissão.

Versões válidas de política

As políticas de permissão podem usar as seguintes versões:

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 participantes. 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 de permissão, é recomendável especificar uma versão na solicitação. Quando uma solicitação especifica uma versão da política de permissão, o IAM supõe que o autor da chamada conhece os recursos dessa dela e pode processá-los corretamente.

Se a solicitação não especificar uma versão de política de permissão, o IAM assumirá que o autor da chamada quer 1.

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

  • Se a política de permissão 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 de permissão contiver condições e o autor da chamada tiver solicitado a versão 3, o IAM retornará uma versão da política de permissão 3 que inclua as condições. Veja um exemplo no cenário 1 nesta página.

  • Se a política de permissão contiver condições e o autor da chamada tiver solicitado uma versão 1 ou não tiver especificado uma versão, o IAM retornará uma versão da política de permissão 1.

    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.

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 de permissão 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 de permissão do projeto. Se a política de permissão 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_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Se a política de permissão 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 de permissão 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 de permissão, 1.

A política de permissão contém uma vinculação de papel condicional. Como a versão da política de permissão é 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 de permissão, é recomendável especificar uma versão na solicitação. Quando uma solicitação especifica uma versão da política de permissão, o IAM supõe que o autor da chamada conhece os recursos dela e que pode processá-las corretamente.

Se a solicitação não especificar uma versão de política de permissão, o IAM aceitará apenas os campos que podem aparecer em uma política de permissão 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 de permissão. 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 de permissão, que mostra a condição de cada vinculação de papel 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 de permissão 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:raha@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 raha@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 de permissão. Mais uma vez, você especifica a versão 3 na solicitação:

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

A resposta contém a política de permissão atualizada:

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

A política de permissão na resposta usa a versão 1, mesmo que a solicitação tenha especificado a versão 3, porque a política de permissão usa apenas campos compatíveis em uma versão 1.

Políticas com os principais excluídos

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

Por exemplo, considere esta política de permissão que inclui uma vinculação do papel 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: Como resultado, o identificador de cada principal tem um prefixo deleted::

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

Imagine que você tenha criado um novo usuário com o nome donald@example.com e queira conceder o papel de Criador do projeto (roles/resourcemanager.projectCreator), permitindo que os principais criem projetos do Google Cloud para o novo usuário de dados. Para conceder o papel ao novo usuário, atualize a política de permissão, como mostra este 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 permissão do 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 na 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 conforme 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íticas de permissão ao criar e gerenciar recursos do Google Cloud.

  • Permissões concedidas para envolvidos no projeto: atribua vinculações no nível do projeto quando necessário para seguir o princípio do menor privilégio. Por exemplo, se um principal precisar acessar 3 dos 10 projetos em uma pasta, conceda acesso a cada um dos 3 projetos individualmente. Em contrapartida, se você tiver concedido um papel na pasta, o principal terá acesso que não precisa em outros sete projetos.

    Também é possível usar as Condições do IAM para conceder papéis no nível da organização ou da pasta, mas apenas para um subconjunto de pastas ou projetos.

A seguir