Visão geral do controle de acesso

Por padrão, todos os projetos do Google Cloud vêm com um único usuário: o criador do projeto original. Nenhum outro usuário tem acesso ao projeto e aos os recursos do Compute Engine até que um usuário seja adicionado como membro do projeto ou esteja vinculado a um recurso específico. Nesta página, descrevemos como adicionar novos usuários a um projeto e definir o controle de acesso dos recursos do Compute Engine.

Além disso, se você executar aplicativos em uma instância de máquina virtual (VM, na sigla em inglês) e o aplicativo precisar de acesso ao Compute Engine ou a outras APIs do Google Cloud, use contas de serviço para autenticar seus aplicativos em vez de credenciais do usuário.

Opções de controle de acesso para usuários

Para oferecer aos usuários a capacidade de criar e gerenciar seus recursos do Compute Engine, adicione os usuários como membros da equipe ao projeto ou a recursos específicos e conceda permissões a eles usando os papéis do gerenciamento de identidade e acesso (IAM).

Um membro da equipe pode ser um usuário individual com uma Conta do Google válida, um Grupo do Google, uma conta de serviço ou um domínio do Google Workspace. Quando você adiciona um membro da equipe a um projeto ou a um recurso, é necessário especificar quais papéis serão concedidos. O IAM oferece três tipos de papéis: predefinidos, básicos e personalizados.

Os recursos herdam as políticas de seus recursos pai na hierarquia de recursos do Google Cloud. A política efetiva de um recurso é a união da política definida nesse recurso com a política herdada do pai dele.

Papéis predefinidos do Compute Engine

Os papéis predefinidos concedem um grupo de permissões relacionadas. O Compute Engine oferece os papéis predefinidos a seguir:

Título do papel Recursos Usuário-alvo
Usuário de imagem do Compute Engine

Permissão para listar e usar imagens de outro projeto. Conceda esse papel a um membro com outro papel para que ele possa usar imagens de outro projeto para criar um novo recurso. Por exemplo, conceda esse papel e o papel de administrador de instância para que um membro possa usar imagens de outro projeto para criar instâncias de VM e discos permanentes.

Se você estiver criando grupos de instâncias gerenciadas ou se estiver usando o Deployment Manager para criar instâncias de VMs, talvez seja necessário conceder esse papel à conta de serviço das APIs do Google do projeto antes de usar imagens de outros projetos.

  • Contas de serviço
  • Administradores de sistemas
  • Desenvolvedores
Administrador de instância do Compute Engine (v1)

Controle total de instâncias, grupos de instâncias, discos, instantâneos e imagens do Compute Engine. Acesso somente leitura a todos os recursos de rede do Compute Engine.

Se o membro estiver gerenciando instâncias de VM configuradas para serem executadas como uma conta de serviço, será necessário conceder também o papel roles/iam.serviceAccountUser para que seja possível atribuir contas de serviço a instâncias de VM.

  • Administradores de sistemas
  • Desenvolvedores
Papel de Administrador do Compute Engine

Controle total de todos os recursos do Compute Engine. Se o usuário estiver gerenciando instâncias de VM configuradas para serem executadas como uma conta de serviço, também será necessário conceder o papel roles/iam.serviceAccountUser.

  • Administradores de sistemas
  • Desenvolvedores
Administrador de rede do Compute Engine

Permissões para criar, modificar e excluir recursos de rede, exceto regras de firewall e certificados SSL. O papel de administrador de rede permite acesso somente leitura a regras de firewall, certificados SSL e instâncias para visualizar endereços IP temporários. O papel de administrador de rede não permite que o usuário crie, inicie, pare ou exclua instâncias.

Administradores de rede
Administrador de segurança do Compute Engine

Permissões para criar, modificar e excluir regras de firewall e certificados SSL.

Administradores de segurança
Administrador de balanceamento de carga do Compute Enginebeta

Permissões para criar, modificar e excluir balanceadores de carga e recursos associados.

Administradores de balanceamento de carga
Usuário da conta de serviço do Compute Engine

Permissão para criar instâncias que usam contas de serviço e permissão para anexar um disco e definir metadados em uma instância já configurada para execução como conta de serviço.

Não é recomendável conceder esse papel isoladamente porque ele não fornece permissões para a API Compute Engine. Conceda esse papel a um membro junto com outro papel, como o de administrador de instâncias.

  • Administradores de sistemas
  • Desenvolvedores
Papel de Leitor do Compute Engine

Acesso somente leitura para receber e listar recursos do Compute Engine, sem poder ler os dados armazenados neles. Por exemplo, uma conta com esse papel poderia inventariar todos os discos em um projeto, mas não conseguiria ler nenhum dos dados nesses discos.

Administradores de sistema
Usuário de rede do Compute Engine

Permissões para usar uma rede VPC compartilhada. Especificamente, conceda esse papel a proprietários de serviços que precisam usar recursos no projeto de host. Assim que o acesso é concedido, os proprietários do serviço podem usar as redes e sub-redes que pertencem ao projeto de host. Por exemplo, um usuário da rede pode criar uma instância de máquina virtual que pertence a uma rede VPC compartilhada do projeto de host, mas não pode excluir nem criar novas redes do projeto de host.

  • Administradores de sistemas
  • Desenvolvedores
Leitor de rede do Compute Engine

Acesso somente leitura a todos os recursos de rede. Por exemplo, se você tem um software que inspeciona a configuração de rede, conceda o papel de leitor de rede à conta de serviço do software.

  • Administradores de rede
  • Administradores de sistemas
  • Desenvolvedores
  • Contas de serviço
Administrador de armazenamento do Compute EngineBeta

Permissões para criar, modificar e excluir discos, imagens e instantâneos.

Por exemplo, se na sua empresa existe alguém que gerencia imagens e você não quer que essa pessoa tenha o papel de editor no projeto, atribua este papel à conta dela.

  • Administradores de sistemas
  • Desenvolvedores
Administrador de VPC compartilhada do Compute Engine

Permissões para administrar projetos de host da VPC compartilhada, especificamente habilitando os projetos de host e associando os projetos do serviço à rede do projeto de host. Esse papel só pode ser atribuído no nível da organização.

Criadores de projetos

Para ver uma lista dos métodos de API a que um papel específico concede permissão, leia a documentação dos papéis do IAM do Compute Engine.

Matriz de papéis predefinidos

A tabela a seguir fornece uma comparação completa dos recursos de cada papel do Compute Engine.

Capacidade Administrador de instâncias (v1) Usuário de imagem Usuário de rede Leitor de rede Administrador de rede Administrador de segurança Administrador do Storage Administrador de VPC compartilhada Administrador do Compute Leitor do Compute Administrador do balanceador de carga
Criar ou excluir instâncias de VM *
SSH em instâncias de VM * *
Listar ou acessar instâncias de VM
Criar ou excluir imagens, discos ou snapshots
Listar ou buscar imagens
Criar ou excluir grupos de instâncias *
Listar ou buscar grupos de instâncias
Criar e gerenciar balanceadores de carga
Criar e gerenciar VPNs
Visualizar recursos de rede/sub-rede
Visualizar regras de firewall
Criar e gerenciar firewalls e certificados SSL para firewalls,
para certificados SSL
Criar e gerenciar projetos de host de VPC compartilhada
Usar redes e sub-redes em um projeto de host de VPC compartilhada
Criar e gerenciar redes e sub-redes

*Se a instância de VM puder ser executada como uma conta de serviço, conceda também o papel de usuário da conta de serviço.

Para ver uma lista dos métodos de API a que um papel específico concede permissão, leia a documentação dos papéis do IAM do Compute Engine.

Papéis básicos do IAM

Os papéis básicos do IAM são mapeados diretamente para os papéis legados de proprietário, editor e visualizador do projeto. Geralmente, use papéis predefinidos sempre que possível. No entanto, nos casos em que o IAM ainda não é compatível, talvez seja necessário usar um papel básico para conceder as permissões corretas.

Título do papel Permissões
Owner Todos os privilégios do leitor e do editor, além da capacidade de alterar as configurações de faturamento, gerenciar o controle de acesso e excluir um projeto.
Editor Todos os privilégios de leitor, além da capacidade de criar, modificar e excluir recursos.
Viewer Permissões somente leitura para todos os recursos. Sem permissão para alterar recursos.

Para saber mais sobre os papéis básicos, leia a documentação sobre eles.

Se os papéis predefinidos ou básicos não atenderem às suas necessidades, crie papéis personalizados.

Políticas do IAM para recursos do Compute Engine

É possível conceder acesso a recursos do Compute Engine, como instâncias de VM, imagens e discos. Para fazer isso, anexe políticas do IAM diretamente a esses recursos. Uma política do IAM permite gerenciar os papéis do IAM nesses recursos, em vez de ou além de gerenciar papéis no nível do projeto. Isso dá a você flexibilidade para aplicar o princípio de privilégio mínimo, que é conceder acesso somente aos recursos específicos que os colaboradores precisam para realizar o trabalho.

Com as políticas do IAM para recursos do Compute Engine, as organizações podem realizar as ações a seguir:

  • Conceder aos usuários acesso a um subconjunto específico de recursos. Suponha que Alice gerencie um subconjunto de instâncias em um projeto. Com as políticas do IAM no nível da instância, você concede à Alice o papel compute.instanceAdmin.v1 apenas nessas instâncias. Se você concedesse a Alice o mesmo papel no projeto, ela teria permissão para modificar todas as instâncias dele.
  • Permitir que os administradores concedam acesso. Administradores de instâncias, discos e imagens podem conceder a outras pessoas acesso a esses recursos, sem precisarem ser proprietários de projetos. Suponha que Bob seja um desenvolvedor que recebeu o papel compute.storageAdmin em uma imagem específica. Ele pode compartilhar essa imagem com os colegas de equipe concedendo a eles o papel compute.imageUser na imagem. Sem as políticas do IAM para recursos do Compute Engine, Bob não pode compartilhar essa imagem com os colegas de equipe dele, a menos que ele se torne o proprietário do projeto, porque ele precisaria modificar a política do IAM do projeto.

Os recursos também herdam as políticas do pai. Se você definir uma política no nível do projeto, ela será herdada por todos os recursos filhos. A política efetiva para um recurso é a união do conjunto de políticas nesse recurso e a política herdada do recurso mais alto na hierarquia. Para mais informações, leia sobre a hierarquia de políticas do IAM.

Políticas da organização

Se você for membro do Google Workspace, saiba que talvez seu projeto faça parte de um recurso Organização. Um recurso Organização é o supernó na hierarquia de recursos do Google Cloud que está intimamente associada a uma conta do Google Workspace. Depois que um recurso Organização for criado para um domínio do Google Workspace, todos os projetos do Google Cloud criados por membros do domínio pertencerão ao recurso Organização.

Uma organização pode implementar as políticas da organização, que são políticas que restringem as configurações permitidas em toda a hierarquia de recursos do Google Cloud. No Compute Engine, é possível implementar as políticas a seguir:

Para definir as políticas da organização, você precisa ter recebido o papel orgpolicy.policyAdmin na organização. Também é possível definir substituições específicas do projeto caso você tenha exceções à política.

Para saber mais sobre Organizações, leia a documentação Organizações.

Para saber mais sobre as políticas da organização, leia a documentação Política da organização.

Como conceder a usuários acesso SSH para instâncias de VM

Para permitir que um usuário se conecte a uma instância de VM usando SSH sem permitir que ele gerencie recursos do Compute Engine, adicione a chave pública do usuário ao projeto ou adicione a chave pública de um usuário a uma instância específica. Com esse método, é possível evitar a adição de um usuário como membro do projeto, concedendo a ele acesso a instâncias específicas.

Para saber mais sobre SSH e gerenciamento de chaves SSH, leia a Visão geral das chaves SSH.

Se você conceder o papel roles/compute.instanceAdmin.v1 a um membro do projeto, ele poderá se conectar automaticamente a instâncias usando SSH, contanto que a instância não esteja configurada para ser executada como conta de serviço. Se a instância estiver configurada para ser executada como uma conta de serviço, você também precisará conceder o papel roles/iam.serviceAccountUser antes que o membro possa se conectar à instância.

Se você adicionar um membro como proprietário ou editor de projeto, ele automaticamente também terá acesso SSH às instâncias de VM do projeto.

Controle de acesso para aplicativos executados em instâncias de VM

Se você executar o código do aplicativo em instâncias e o aplicativo precisar ser autenticado em outras APIs do Google Cloud, crie contas de serviço e conceda a essas contas papéis do IAM específicos para fazer a autenticação em outras APIs do Google Cloud em seu nome. Uma conta de serviço é uma conta especial que não tem credenciais de usuário e é ideal para interações de servidor para servidor.

Para saber mais sobre contas de serviço, leia a documentação Contas de serviço.

A seguir