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 usuários ao seu projeto e definir o controle de acesso dos recursos do Compute Engine usando o Identity and Access Management (IAM).
Para informações sobre como fornecer acesso a aplicativos em execução nas instâncias do Compute Engine, consulte Como a autorização é determinada.
Opções de controle de acesso para usuários
Para oferecer aos usuários a capacidade de criar e gerenciar recursos do Compute Engine, adicione-os como membros da equipe ao projeto ou a recursos específicos e conceda a eles permissões usando os papéis do 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 para o recurso com a 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. |
|
| 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 |
|
| 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 |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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.v1apenas 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.storageAdminem uma imagem específica. Ele pode compartilhar essa imagem com os colegas de equipe concedendo a eles o papelcompute.imageUserna 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:
- Desativar o acesso interativo ao console serial.
- Desativar endereços IP externos para instâncias de VM.
- Restringir quais projetos de imagem estão disponíveis para os membros do seu projeto
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.
Identidades das cargas de trabalho gerenciadas para cargas de trabalho do Compute Engine
É possível configurar o provisionamento automático e o gerenciamento do ciclo de vida de certificados X.509 pelo Certificate Authority Service (CA Service) usando identidades das cargas de trabalho gerenciadas. Os certificados de identidade da carga de trabalho gerenciada são emitidos pelo CA Service, que é um serviço escalonável e altamente disponível do Google Cloud que ajuda a simplificar e automatizar a implantação, o gerenciamento e a segurança dos serviços de AC, mantendo ainda o controle das chaves privadas.
Com identidades das cargas de trabalho gerenciadas, é possível se beneficiar do mTLS por VM gerenciado pelo Compute Engine. O mTLS por VM usa certificados X.509 emitidos quando você cria uma VM. Esses certificados mTLS são alternados automaticamente, para que você não precise mais se preocupar com o gerenciamento deles.
As identidades das cargas de trabalho gerenciadas oferecem uma base para permitir comunicações mutuamente autenticadas e criptografadas entre duas VMs do Compute Engine. Por exemplo, quando você usa identidades das cargas de trabalho gerenciadas, o serviço A em execução em uma VM se comunica com o serviço B em execução em um canal diferente por um canal criptografado estabelecido usando mTLS.
Para informações sobre como configurar identidades das cargas de trabalho gerenciadas, consulte Autenticar cargas de trabalho em outras cargas de trabalho por mTLS.
A seguir
- Adicione usuários como membros da equipe.
- Saiba mais sobre os papéis do IAM.
- Saiba mais sobre Como adicionar e remover chaves SSH.
- Saiba mais sobre Contas de serviço.