Visão geral

Nesta página, descrevemos os conceitos básicos do Cloud Identity and Access Management (Cloud IAM).

O Cloud IAM permite conceder acesso granular a recursos específicos do Google Cloud e ajuda a impedir o acesso a outros recursos. O Cloud IAM permite a adoção do princípio de segurança de privilégio mínimo, em que você concede apenas as permissões necessárias para acessar recursos específicos.

Como o Cloud IAM funciona

Com o Cloud 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 intervalos 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 Cloud 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 membros autenticados. Uma política do Cloud IAM define e impõe quais papéis são concedidos a quais membros, e essa política está anexada a um recurso. Quando um membro autenticado tenta acessar um recurso, o Cloud IAM verifica a política do recurso para determinar se a ação é permitida.

No diagrama a seguir, veja o gerenciamento de permissões no Cloud IAM.

Arquitetura do Cloud IAM.

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

  • Membro. Um membro pode ser uma Conta do Google (para usuários finais), uma conta de serviço (para apps e máquinas virtuais), um Grupo do Google ou um domínio do G Suite ou Cloud Identity que pode acessar um recurso. A identidade de um membro é um endereço de e-mail associado a um usuário, conta de serviço ou Grupo do Google. Pode ser também um nome de domínio associado aos domínios do G Suite ou do Cloud Identity.
  • 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 do Cloud IAM vincula um ou mais membros a um papel. Quando você quiser definir quem (membro) tem qual tipo de acesso (papel) em um recurso, crie uma política e anexe-a ao recurso.

No diagrama anterior, por exemplo, a política do Cloud IAM vincula o usuário final identificado por userid@gmail.com ao papel Administrador do App Engine (roles/appengine.appAdmin). Se a política estiver anexada a um projeto, o usuário userid@gmail.com terá o papel Administrador do App Engine nesse projeto. Neste caso, o usuário pode ver, criar e atualizar todas as configurações e definições do aplicativo para envolvidos no projeto no App Engine.

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

No Cloud IAM, você concede acesso a membros. Os membros podem ser dos seguintes tipos:

  • Conta do Google
  • Conta de serviço
  • Grupo do Google
  • Domínio do G Suite
  • Domínio do Cloud Identity

Conta do Google

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

Conta de serviço

Uma conta de serviço é uma conta de um aplicativo em vez de um usuário final individual. Quando você executa um código hospedado no Google Cloud, o código é executado como a conta especificada. 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 no aplicativo, consulte Primeiros passos na autenticação.

Grupo 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 uma política de acesso a uma coleção de usuários. Em vez de atribuir ou alterar um controle de acesso por vez para cada usuário ou conta de serviço individual, é possível conceder e alterar controles de acesso para um grupo inteiro de uma só vez. Também é fácil adicionar e remover membros de um Grupo do Google, em vez de atualizar uma política do Cloud IAM 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.

Domínio do G Suite

Um domínio do G Suite representa um grupo virtual de todas as contas do Google criadas na conta do G Suite de uma organização. Os domínios do G Suite representam o nome de domínio da Internet de sua organização (como example.com) e, quando você adicionar um usuário a seu domínio do G Suite, uma nova Conta do Google será criada para o usuário dentro desse grupo virtual (como username@example.com).

De maneira semelhante ao que ocorre nos Grupos do Google, os domínios do G Suite não são usados para estabelecer identidade, mas ativam o gerenciamento conveniente de permissões.

Domínio do Cloud Identity

Um domínio do Cloud Identity é semelhante ao do G Suite, porque 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 G Suite. 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 um domínio do G Suite ou do Cloud Identity, como contas pessoais do Gmail. Os usuários não autenticados, como visitantes anônimos, não estão incluídos.

allUsers

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

Quando um membro autenticado tenta acessar um recurso, o Cloud IAM verifica a própria política no recurso para determinar se a ação é permitida.

Nesta seção, descrevemos as entidades e os conceitos envolvidos no processo de autorização.

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 intervalos do Cloud Storage.

Alguns serviços são compatíveis com a concessão de permissões do Cloud IAM com granularidade melhor do que o nível do projeto. Por exemplo, é possível conceder o papel Administrador do Storage (roles/storage.admin) a um determinado intervalo do Cloud Storage ou conceder o papel 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 Cloud IAM para envolvidos no projeto. As permissões são herdadas por todos os recursos desse projeto. Por exemplo, para conceder acesso a todos os intervalos do Cloud Storage em um projeto, conceda acesso ao projeto e não a cada intervalo individual. Ou então, 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 Noções básicas sobre papéis e confira a coluna Menor recurso para detalhes sobre um determinado papel.

Permissões

Com as permissões, você determina quais operações são permitidas em um recurso. No contexto do Cloud 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 expõe. O autor da chamada precisa dessas permissões para chamar o método. Por exemplo, se você usa o Pub/Sub e precisa chamar o método topics.publish(), precisa ter a permissão pubsub.topics.publish para isso.

Você não concede permissões diretamente aos usuários. Em vez disso, identifica papéis que contenham as permissões apropriadas e os concede ao usuário.

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ões para papéis

Há três tipos de papel no Cloud IAM:

  • Papéis primários: papéis historicamente disponíveis no Console do Google Cloud. Esses papéis são Proprietário, Editor e Visualizador. Evite usar esses papéis, se possível, porque eles incluem uma ampla gama de permissões em todos os serviços do Google Cloud.

  • Papéis predefinidos: papéis que oferecem um controle de acesso mais preciso que os primários. Por exemplo, o papel predefinido 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 saber como conceder um papel ao usuário, consulte Como conceder, alterar e revogar o acesso. Para informações sobre os papéis predefinidos do Cloud IAM disponíveis, consulte Noções básicas sobre papéis. Para informações sobre papéis personalizados, consulte Noções básicas sobre papéis personalizados e Como criar e gerenciar papéis personalizados.

Política do Cloud IAM

Para conceder papéis a usuários, crie uma política do Cloud IAM, uma coleção de instruções que definem quem tem qual tipo de acesso. A política é anexada a um recurso e, sempre que ele é acessado, o controle de acesso é aplicado.

Política do Cloud IAM.

Uma política do Cloud IAM é representada pelo objeto Policy do Cloud IAM. Um objeto Policy do Cloud IAM consiste em uma lista de vinculações. Um Binding vincula uma lista de members a um role.

  • role: o papel que você quer conceder ao membro. role é especificado no formato 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 uma ou mais identidades, conforme descrito na seção Conceitos relacionados à identidade, neste documento. Cada tipo de membro é identificado com um prefixo, como uma Conta do Google (user:), uma conta de serviço (serviceAccount:), um Grupo do Google (group:) ou um domínio do G Suite ou do Cloud Identity (domain:). No exemplo de snippet de código a seguir, o papel storage.objectAdmin é concedido aos membros a seguir usando o prefixo apropriado: user:alice@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. O papel objectViewer é concedido a user:bob@example.com.

O snippet de código a seguir mostra a estrutura de uma política do Cloud IAM.

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

Cloud IAM e APIs de política

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

Os métodos do Cloud IAM são:

  • setIamPolicy(): define políticas nos seus recursos.
  • getIamPolicy(): recebe uma política 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 de API desses métodos na documentação de cada serviço compatível com o Cloud IAM.

Hierarquia de políticas

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.
  • 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 de recursos do Cloud IAM.

É possível configurar uma política do Cloud IAM 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 do pai. Quando uma política é definida no nível da organização, ela é herdada automaticamente por todos os projetos filhos e, quando configurada para envolvidos no projeto, é herdada por todos os recursos filhos. A política efetiva de um recurso é a união do conjunto de políticas nesse recurso e a política herdada do recurso mais alto na hierarquia.

Essa herança da política é transitória, ou seja, os recursos herdam as políticas do projeto, que herdam as políticas das pastas, que herdam as políticas da organização. Portanto, as políticas no nível da organização também se aplicam ao nível do recurso.

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

A hierarquia de políticas do Cloud IAM segue o mesmo caminho que a hierarquia de recursos do Google Cloud. Se você alterar a hierarquia de recursos, a de políticas também será modificada. Por exemplo, mover um projeto para uma organização atualiza a política do Cloud IAM do projeto para herdar da política do Cloud IAM da organização.

As políticas filho não restringem o acesso concedido em um nível superior. Por exemplo, mesmo que seja concedido a um usuário o papel Editor de um projeto e o de Visualizador a um recurso filho, esse usuário ainda terá o papel Editor para o recurso filho.

Compatibilidade do Cloud IAM com serviços do Google Cloud

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

Antes do Cloud IAM, você só conseguia conceder os papéis Proprietário, Editor ou Visualizador. Esses papéis dão amplo acesso a um projeto e não permitem a separação minuciosa de tarefas. Os serviços do Google Cloud agora oferecem outros papéis predefinidos com controle de acesso mais preciso do que os papéis Proprietário, Editor e Visualizador. Por exemplo, no Compute Engine são oferecidos papéis como Administrador de instâncias e Administrador de redes. No App Engine, há papéis como Administrador de aplicativos e Administrador de serviços. Esses papéis predefinidos estão disponíveis além dos papéis primários Proprietário, Editor e Visualizador.

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 melhor que a do nível do projeto. Por exemplo, é possível criar uma política de controle de acesso do Cloud IAM que concede a um usuário o papel Assinante de um determinado tópico de 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.

A seguir