Visão geral do IAM

Esta página descreve como funciona o sistema de gerenciamento de identidade e acesso (IAM) do Google Cloud e como usá-lo para gerenciar o acesso no Google Cloud.

O IAM permite conceder acesso granular a recursos específicos do Google Cloud e ajuda a impedir o acesso a outros recursos. O IAM permite que você adote o princípio de segurança de privilégio mínimo, o que indica que ninguém precisa ter mais permissões do que o realmente necessário.

Como o IAM funciona

Com o IAM, você gerencia o controle de acesso definindo quem (identidade) tem qual acesso (papel) a que recurso. Por exemplo, as instâncias de máquina virtual do Compute Engine, os clusters do Google Kubernetes Engine (GKE) e os buckets do Cloud Storage são todos recursos do Google Cloud. As organizações, pastas e projetos que você usa para organizar seus recursos também são recursos.

No IAM, a permissão para acessar um recurso não é concedida diretamente ao usuário final. Em vez disso, as permissões são agrupadas em papéis, que são concedidos a principais autenticados. No passado, o IAM muitas vezes se referia aos principais como membros. Algumas APIs ainda usam esse termo.

Uma política de permissão, também conhecida como política do IAM, define e aplica os papéis concedidos aos principais. Cada política de permissão é anexada a um recurso. Quando um principal autenticado tenta acessar um recurso, o IAM verifica a política do recurso para determinar se a ação é permitida.

O diagrama a seguir ilustra o gerenciamento de permissões no IAM.

Uma política de permissão com duas vinculações de papéis. As vinculações de papel associam membros específicos a papéis específicos.

Este modelo de gerenciamento de acesso tem três partes principais:

  • Principal. Um principal representa uma identidade que pode acessar um recurso. Cada principal tem um identificador próprio.
  • Papel. Um papel é um conjunto de permissões. Com as permissões, você determina quais operações são permitidas em um recurso. Ao conceder um papel a um membro, você concede todas as permissões contidas nele.
  • Política. A política de permissão é um conjunto de vinculações de papéis que associa um ou mais principais a papéis individuais. Quando você quiser definir quem (principal) tem qual tipo de acesso (papel) em um recurso, crie uma política e anexe ela ao recurso.

No diagrama anterior, por exemplo, a política de permissão vincula principais, como user@example.com, a papéis, como o Administrador do App Engine (roles/appengine.appAdmin). Se a política de permissão estiver anexada a um projeto, os membros receberão os papéis especificados no projeto.

No restante desta página, descrevemos esses conceitos em mais detalhes.

No IAM, você concede acesso a principais, que representam uma identidade que pode acessar um recurso. No contexto do gerenciamento de acesso, os principais podem ser de um dos seguintes tipos:

Para detalhes sobre os formatos de identificador de cada tipo de participante, consulte Identificadores de participantes.

Contas do Google

Uma Conta do Google representa um desenvolvedor, um administrador ou qualquer outra pessoa que interaja com o Google Cloud usando umaa conta criada com o Google. Qualquer endereço de e-mail associado a uma Conta do Google pode ser usado como principal, incluindo endereços de e-mail gmail.com ou endereços de e-mail com outros domínios. A inscrição de novos usuários é feita na página de inscrição da Conta do Google.

Contas de serviço

Uma conta de serviço é uma conta para uma carga de trabalho de aplicativo ou computação em vez de um usuário final individual. Ao executar um código hospedado no Google Cloud, especifique uma conta de serviço para usar como a identidade do aplicativo. Para representar os diferentes componentes lógicos do aplicativo, crie quantas contas de serviço forem necessárias. Para mais informações sobre como usar uma conta de serviço para autenticar o aplicativo, consulte Contas de serviço.

Grupos do Google

Um Grupo do Google é uma coleção nomeada de Contas do Google e contas de serviço. Cada Grupo do Google tem um endereço de e-mail exclusivo associado ao Grupo. Para encontrar o endereço de e-mail associado a um Grupo do Google, clique em Sobre na página inicial de qualquer Grupo. Consulte a página inicial dos Grupos do Google para mais informações.

Os grupos do Google são um modo prático de aplicar controles de acesso a uma coleção de usuários. É possível conceder e alterar controles de acesso para um Grupo inteiro de uma só vez, em vez de conceder ou alterar controles de acesso a cada usuário ou conta de serviço individualmente. Também é possível adicionar e remover principais de um grupo do Google com facilidade, em vez de atualizar uma política de permissão para adicionar ou remover usuários.

Os grupos do Google não têm credenciais de login, e não é possível usá-los a fim de estabelecer uma identidade para fazer uma solicitação de acesso a um recurso.

Contas do Google Workspace

Uma conta do Google Workspace representa um grupo virtual de todas as Contas do Google que ela contém. As contas do Google Workspace são associadas ao nome de domínio da Internet de sua organização, como example.com. Quando você cria uma Conta do Google para um novo usuário, como username@example.com, ela é adicionada ao grupo virtual da sua conta do Google Workspace.

De maneira semelhante ao que ocorre nos grupos do Google, as contas do Google Workspace não são usados para estabelecer identidade, mas ativam o gerenciamento conveniente de permissões.

Domínios do Cloud Identity

Um domínio do Cloud Identity é semelhante à conta do Google Workspace, porque ele representa um grupo virtual de todas as Contas do Google em uma organização. Entretanto, os usuários de domínio do Cloud Identity não têm acesso aos aplicativos e recursos do Google Workspace. Para mais informações, consulte Sobre o Cloud Identity.

allAuthenticatedUsers

O valor allAuthenticatedUsers é um identificador especial que representa todas as contas de serviço e todos os usuários na Internet que se autenticaram com uma Conta do Google. Esse identificador inclui contas que não estão conectadas a uma conta do Google Workspace ou do Cloud Identity, como contas pessoais do Gmail. Os usuários que não forem autenticados, como os visitantes anônimos, não serão incluídos.

Esse tipo principal não inclui identidades federadas, que são gerenciadas por provedores de identidade externos (IdPs). Se você usar a federação de identidade de colaboradores ou a federação de identidade da carga de trabalho, não use allAuthenticatedUsers. Use uma das seguintes opções:

Alguns tipos de recursos não são compatíveis com esse tipo principal.

allUsers

O valor allUsers é um identificador especial que representa qualquer pessoa que esteja na Internet, incluindo usuários autenticados e não autenticados.

Alguns tipos de recursos não são compatíveis com esse tipo principal.

As identidades federadas em um pool de Identidades de colaboradores

Uma identidade federada em um pool de identidade de colaboradores é uma identidade de usuário gerenciada por um IdP externo e federada usando a Federação de identidade de colaboradores. É possível usar uma identidade específica em um pool de identidades de colaboradores ou usar determinados atributos para especificar um grupo de identidades de usuário em um pool de identidades de colaboradores. Para informações sobre identificadores principais para identidades federadas, consulte Identificadores principais.

Identidades federadas em um pool de Identidade da carga de trabalho.

Uma identidade federada em um pool de identidade da carga de trabalho é uma identidade da carga de trabalho gerenciada por um IdP externo e federada usando a federação de identidade da carga de trabalho. É possível usar uma identidade da carga de trabalho específica em um pool de identidades da carga de trabalho ou usar determinados atributos para especificar um grupo de identidades da carga de trabalho em um pool de identidades da carga de trabalho. Para informações sobre identificadores principais para identidades federadas, consulte Identificadores principais.

Pods do GKE

As cargas de trabalho executadas no GKE usam a Federação de Identidade da Carga de Trabalho para GKE para acessar os serviços do Google Cloud. Para mais informações sobre identificadores principais para pods do GKE, consulte Referenciar recursos do Kubernetes em políticas do IAM.

Recurso

Se um usuário precisar acessar um recurso específico do Google Cloud, será possível atribuir um papel a ele. Como exemplos de recursos, citamos projetos, instâncias do Compute Engine e buckets do Cloud Storage.

Alguns serviços oferecem suporte à concessão de permissões do IAM com granularidade melhor do que o nível do projeto. Por exemplo, é possível conceder o papel de Administrador do Storage (roles/storage.admin) a um determinado bucket do Cloud Storage ou conceder o papel de Administrador de instâncias do Compute (roles/compute.instanceAdmin) a um usuário de uma instância específica do Compute Engine.

Em outros casos, é possível conceder permissões do IAM no nível do projeto. As permissões são herdadas por todos os recursos desse projeto. Por exemplo, para conceder acesso a todos os buckets do Cloud Storage em um projeto, conceda acesso ao projeto e não a cada bucket individual. Da mesma forma, para conceder acesso a todas as instâncias do Compute Engine em um projeto, conceda acesso ao projeto e não a cada instância individual.

Para informações sobre quais papéis podem ser concedidos em qual recurso, consulte Como entender os papéis e confira a coluna Recurso menor para detalhes sobre um determinado papel.

Permissões

Com as permissões, você determina quais operações são permitidas em um recurso. No mundo do IAM, as permissões são representadas na forma de service.resource.verb, por exemplo, pubsub.subscriptions.consume.

As permissões geralmente têm correspondência de um para um em relação aos métodos da API REST. Ou seja, cada serviço do Google Cloud tem um conjunto associado de permissões para cada método da API REST que ele expõe. O autor da chamada precisa dessas permissões para chamar o método. Por exemplo, se você usar Pub/Sub e precisar chamar o método topics.publish(), precisará da permissão pubsub.topics.publish para esse tópico.

Você não concede permissões diretamente aos usuários. Em vez disso, identifica papéis que contenham as permissões apropriadas e concede esses papéis ao usuário. Para uma lista de todas as permissões disponíveis e os papéis que as contêm, consulte a referência de permissões.

Papéis

Um papel é um conjunto de permissões. Não é possível conceder uma permissão ao usuário diretamente. Em vez disso, você concede a eles um papel. Quando você faz isso, concede ao usuário todas as permissões contidas no papel.

Mapeamento de permissão de função

Há vários tipos de papel no IAM:

  • Papéis básicos: papéis historicamente disponíveis no Console do Google Cloud. Esses papéis são de Proprietário, Editor e Visualizador.

  • Papéis predefinidos: oferecem um controle de acesso mais preciso que os papéis básicos. Por exemplo, o papel predefinido de Editor do Pub/Sub (roles/pubsub.publisher) fornece acesso somente à publicação de mensagens em um tópico do Pub/Sub.

  • Papéis personalizados: criados para adaptar as permissões às necessidades da organização, quando não são atendidas pelos papéis predefinidos.

Para mais informações sobre papéis, consulte os seguintes recursos:

Política de permissão

Quando um membro autenticado tenta acessar um recurso, o IAM verifica a política de permissão do recurso para determinar se a ação é permitida.

É possível conceder papéis aos usuários criando uma política de permissão, que é um conjunto de instruções que define quem tem qual tipo de acesso. Essa política de permissão é anexada a um recurso e, sempre que ele é acessado, o controle de acesso é aplicado.

Política do IAM

Uma política de permissão consiste em uma lista de vinculações de papéis. Uma vinculação de papel vincula uma lista de principais a um papel.

  • role: o papel que você quer conceder ao principal. role é especificado na forma de roles/service.roleName. Por exemplo, o Cloud Storage fornece os papéis roles/storage.objectAdmin, roles/storage.objectCreator e roles/storage.objectViewer, entre outros.

  • members: uma lista de um ou mais principais, conforme descrito na seção Conceitos relacionados à identidade neste documento. Cada tipo de principal é identificado com um prefixo, como uma Conta do Google (user:), conta de serviço (serviceAccount:), Grupo do Google (group:) ou uma conta do Google Workspace ou do Cloud Identity (domain:). No exemplo de snippet de código a seguir, o papel storage.objectAdmin é concedido aos principais a seguir usando o prefixo apropriado: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. O papel objectViewer é concedido a user:maria@example.com.

O snippet de código a seguir mostra a estrutura de uma política de permissão.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

APIs do IAM e de política

O IAM fornece um conjunto de métodos que podem ser usados para criar e gerenciar políticas de permissão nos recursos do Google Cloud. Esses métodos são expostos pelos serviços que dão suporte ao IAM. Por exemplo, os métodos do IAM são expostos pelas APIs Resource Manager, Pub/Sub e Cloud Life Sciences, só para citar algumas.

Os métodos do IAM são:

  • setIamPolicy(): define políticas de permissão nos recursos.
  • getIamPolicy(): recebe uma política de permissão que foi definida anteriormente.
  • testIamPermissions(): testa se o autor da chamada tem as permissões especificadas para um recurso.

Encontre os tópicos de referência da API sobre esses métodos na documentação de cada serviço compatível com o IAM.

Hierarquia de recursos

Os recursos do Google Cloud são organizados hierarquicamente:

  • A organização é o nó raiz na hierarquia.
  • As pastas são filhos da organização ou de outra pasta.
  • Os projetos são filhos da organização ou de uma pasta.
  • Os recursos de cada serviço são descendentes de projetos.

Cada recurso tem um pai. Para mais informações, consulte a hierarquia de recursos do Resource Manager.

O diagrama a seguir é um exemplo de uma hierarquia de recursos do Google Cloud.

Hierarquia para recursos do IAM.

É possível definir uma política de permissão em qualquer nível da hierarquia de recursos: no nível da organização, da pasta, do projeto ou do recurso. Os recursos herdam as políticas de permissão de todos os recursos pai. A política de permissão efetiva de um recurso é a união da política de permissão definida nele e das políticas de permissão herdadas de níveis superiores na hierarquia.

Essa herança de política é transitiva; Em outras palavras, os recursos herdam as políticas de permissão do projeto, que herdam as políticas de permissão das pastas, que herdam as políticas de permissão da organização. Portanto, as políticas de permissão no nível da organização também se aplicam no nível do recurso.

Por exemplo: no diagrama anterior, topic_a é um recurso do Pub/Sub que pertence ao projeto example-prod. Se você concede o papel de Editor a micah@example.com para example-prod e concede o papel de Publicador a song@example.com para topic_a, você efetivamente concede o papel de Editor de topic_a a micah@example.com e o papel de Publicador a song@example.com.

As políticas de permissão dos recursos filhos herdam as políticas de permissões dos recursos pais. Por exemplo, mesmo que seja concedido a um usuário o papel de editor de um projeto e o de leitor a um recurso filho, esse usuário ainda terá o papel de editor para o recurso filho. Se você alterar a hierarquia de recursos, a herança de políticas também será modificada. Por exemplo, quando um projeto é movido para uma organização, ele herda a política de permissão dessa organização.

Suporte do IAM para serviços do Google Cloud

Com o IAM, todos os métodos de API em todos os serviços do Google Cloud são verificados para garantir que a conta que faz a solicitação de API tenha a permissão apropriada para usar o recurso.

Os serviços do Google Cloud oferecem papéis predefinidos que concedem controle de acesso refinado. Por exemplo, o Compute Engine oferece papéis como administrador de instâncias do Compute e administrador de rede do Compute. O Cloud Storage oferece papéis como administrador de pastas do Storage e usuário de objetos do Storage.

Os papéis predefinidos estão disponíveis para a maioria dos serviços do Google Cloud. Para detalhes, consulte a lista de todos os papéis predefinidos. Caso seja necessário maior controle sobre as permissões, verifique se é possível criar um papel personalizado.

É possível conceder aos usuários papéis específicos para acessar recursos com granularidade maior do que a do nível do projeto. Por exemplo, é possível criar uma política de permissão que conceda a um usuário o papel de assinante para um tópico específico do Pub/Sub. A lista de todos os papéis predefinidos mostra o tipo de recurso de nível mais baixo ou mais detalhado que aceita cada papel.

Modelo de consistência para a API IAM

A API IAM tem consistência eventual. Em outras palavras, se você gravar dados com a API IAM e ler imediatamente esses dados, a operação de leitura poderá retornar uma versão mais antiga dos dados. Além disso, as alterações feitas podem demorar um pouco para afetar as verificações de acesso.

Esse modelo de consistência afeta o funcionamento da API IAM. Por exemplo, se você criar uma conta de serviço e se referir imediatamente a ela em outra solicitação, a API IAM poderá informar que a conta de serviço não foi encontrada. Esse comportamento ocorre porque as operações têm consistência posterior e pode levar algum tempo para que a nova conta de serviço se torne visível para solicitações de leitura.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar gratuitamente