Hierarquia de recursos

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Nesta página, descrevemos a hierarquia de recursos do Google Cloud e os recursos que podem ser gerenciados com o Resource Manager.

O objetivo da hierarquia de recursos do Google Cloud é duplo:

  • Fornecer uma hierarquia de propriedade, que vincula o ciclo de vida de um recurso ao próprio pai imediato na hierarquia.
  • Fornecer pontos de conexão e herança para controle de acesso e políticas da organização.

Metaforicamente falando, a hierarquia de recursos do Google Cloud se parece com o sistema de arquivos encontrado em sistemas operacionais tradicionais na forma de organizar e gerenciar entidades hierarquicamente. Geralmente, cada recurso tem exatamente um pai. Essa organização hierárquica de recursos permite definir políticas de controle de acesso e configurações em um recurso pai, e as políticas e configurações de Identity and Access Management (IAM) são herdadas pelos recursos filhos.

Hierarquia de recursos do Google Cloud em detalhes

Os recursos do Google Cloud são organizados hierarquicamente. Todos os recursos, exceto o mais alto em uma hierarquia, têm exatamente um pai. No nível mais baixo, os recursos de serviço são os componentes fundamentais de todos os serviços do Google Cloud. Exemplos de recursos de serviço incluem máquinas virtuais (VMs) do Compute Engine, tópicos do Pub/Sub, buckets do Cloud Storage e instâncias do App Engine. Todos esses recursos de nível inferior têm recursos de projeto como pais, que representam o primeiro mecanismo de agrupamento da hierarquia de recursos do Google Cloud.

Todos os usuários podem criar recursos do projeto, incluindo usuários de avaliação gratuita, usuários do Nível gratuito e clientes do Google Workspace e do Cloud Identity. Os usuários do Programa gratuito do Google Cloud só podem criar recursos de serviço e recursos de serviço dentro dos projetos. Os recursos do projeto podem estar no topo da hierarquia, mas apenas se forem criados por um usuário da avaliação gratuita ou usuário do nível gratuito. Os clientes do Google Workspace e do Cloud Identity têm acesso a recursos adicionais da hierarquia de recursos do Google Cloud, como recursos de organização e pasta. Saiba mais na visão geral do Cloud Identity. Os recursos do projeto na parte superior da hierarquia não têm recursos pais, mas podem ser migrados para um recurso da organização depois de criado para o domínio. Para mais detalhes sobre como migrar recursos de projetos, consulte Como migrar recursos de projetos.

Os clientes do Google Workspace e do Cloud Identity podem criar recursos da organização. Cada conta do Google Workspace ou do Cloud Identity está associada a um recurso da organização. Quando existe um recurso da organização, ele é o topo da hierarquia de recursos do Google Cloud, e todos os recursos que pertencem a uma organização são agrupados no recurso da organização. Isso permite visibilidade e controle centrais sobre todos os recursos que pertencem a uma organização.

Os recursos de pastas são um mecanismo de agrupamento adicional e opcional entre os recursos da organização e do projeto. Um recurso da organização é obrigatório como pré-requisito para usar pastas. Os recursos de pasta e os respectivos recursos de projeto filho são mapeados no recurso Organização.

A hierarquia de recursos do Google Cloud, especialmente na versão mais completa que inclui recursos de pasta e recursos da organização, permite que as empresas mapeem a organização para o Google Cloud e forneça pontos lógicos de anexos para políticas de gerenciamento de acesso (IAM) e políticas da organização. As políticas do IAM e da organização são herdadas pela hierarquia, e a política efetiva de cada recurso é o resultado das políticas aplicadas diretamente ao recurso e daquelas herdadas dos ancestrais.

O diagrama abaixo representa um exemplo de hierarquia de recursos do Google Cloud na forma completa:

O recurso de organização

O recurso organização representa uma organização (por exemplo, uma empresa) e é o nó raiz na hierarquia de recursos do Google Cloud quando presente. O recurso da organização é o ancestral hierárquico dos recursos de pasta e projeto. As políticas de controle de acesso do IAM aplicadas ao recurso da organização se aplicam a toda a hierarquia em todos os recursos da organização.

Os usuários do Google Cloud não precisam ter um recurso da organização, mas alguns recursos do Resource Manager não poderão ser usados sem um. O recurso da organização está intimamente associado a uma conta do Google Workspace ou do Cloud Identity. Quando um usuário com uma conta do Google Workspace ou do Cloud Identity cria um recurso de projeto do Google Cloud, um recurso da organização é provisionado automaticamente para ele.

Uma conta do Google Workspace ou do Cloud Identity pode ter exatamente um recurso da organização provisionado com ela. Depois que um recurso da organização é criado para um domínio, todos os novos recursos do projeto do Google Cloud criados por membros do domínio da conta pertencerão, por padrão, ao recurso da organização. Quando um usuário gerenciado cria um recurso de projeto, o requisito é que ele esteja em algum recurso da organização. Se um usuário especificar um recurso da organização e tiver as permissões corretas, o projeto será atribuído a essa organização. Caso contrário, o padrão será o recurso da organização ao qual o usuário está associado. É impossível que contas associadas a um recurso da organização criem recursos de projetos que não estejam associadas a um recurso da organização.

Para simplificar, vamos nos referir ao Google Workspace para usuários do Google Workspace e do Cloud Identity.

A conta do Google Workspace ou do Cloud Identity representa uma empresa e é um pré-requisito para ter acesso ao recurso da organização. No contexto do Google Cloud, ele fornece gerenciamento de identidade, mecanismo de recuperação, propriedade e gerenciamento do ciclo de vida. A imagem abaixo mostra o vínculo entre a conta do Google Workspace, o Cloud Identity e a hierarquia de recursos do Google Cloud.


O superadministrador do Google Workspace é o responsável pela verificação da propriedade de domínio e o contato em casos de recuperação. Por isso, o superadministrador do Google Workspace pode atribuir papéis do IAM por padrão. A principal função do superadministrador do Google Workspace em relação ao Google Cloud é atribuir o papel de IAM de administrador da organização aos usuários apropriados no domínio. Isso criará a separação entre o Google Workspace e as responsabilidades de administração do Google Cloud que os usuários normalmente procuram.

Benefícios do recurso da organização

Com um recurso de organização, os recursos de projeto pertencem à sua organização, e não ao funcionário que o criou. Isso significa que os recursos do projeto não são mais excluídos quando um funcionário sai da empresa. Em vez disso, ele segue o ciclo de vida do recurso da organização no Google Cloud.

Além disso, os Administradores da Organização têm controle central de todos os recursos. Eles podem ver e gerenciar todos os recursos do projeto da sua empresa. Essa restrição significa que não pode mais haver projetos sombra ou administradores não autorizados.

Além disso, é possível conceder papéis no nível da organização, que são herdados por todos os recursos de pastas e projetos no recurso da organização. Por exemplo, é possível conceder o papel de administrador de rede à equipe de rede no nível da organização. Isso permite que ele gerencie todas as redes em todos os recursos do projeto na empresa, em vez de conceder a ele o papel para todos os recursos de projetos individuais.

Um recurso da organização exposto pela API Resource Manager é composto pelo seguinte:

  • Um ID de recurso da organização, que é um identificador exclusivo.
  • Um nome de exibição, gerado a partir do nome do domínio principal no Google Workspace ou no Cloud Identity.
  • O horário de criação do recurso da organização.
  • O horário da última modificação do recurso da organização.
  • O proprietário do recurso da organização. O proprietário é especificado ao criar o recurso da organização. Depois de definido, ele não pode ser alterado. É o ID de cliente do Google Workspace especificado na API Directory.

O snippet de código a seguir mostra a estrutura de um recurso da organização:

{
  "creationTime": "2020-01-07T21:59:43.314Z",
  "displayName": "my-organization",
  "lifecycleState": "ACTIVE",
  "name": "organizations/34739118321",
  "owner": {
    "directoryCustomerId": "C012ba234"
  }
}

A política inicial do IAM para um recurso da organização recém-criado concede os papéis de criador do projeto e criador da conta de faturamento a todo o domínio do Google Workspace. Isso significa que os usuários poderão continuar criando recursos de projetos e contas de faturamento como faziam antes da existência do recurso da organização. Nenhum outro recurso é criado durante a criação de um recurso da organização.

O recurso de pasta

Os recursos de pastas oferecem um mecanismo de agrupamento adicional e limites para isolamento entre projetos. Eles podem ser considerados como suborganizações no recurso. Os recursos de pasta podem ser usados para modelar diferentes pessoas jurídicas, departamentos e equipes em uma empresa. Por exemplo, um primeiro nível de recursos de pasta pode ser usado para representar os principais departamentos da organização. Como os recursos de pasta podem conter recursos de projeto e outras, cada recurso de pasta pode incluir outras subpastas para representar equipes diferentes. Além disso, cada pasta de equipe pode conter subpastas adicionais para representar diferentes aplicativos. Para mais detalhes sobre o uso de recursos de pasta, consulte Como criar e gerenciar recursos de pasta.

Se os recursos da pasta existirem no recurso da organização e você tiver as permissões de visualização apropriadas, poderá visualizá-los no Console do Google Cloud. Para instruções mais detalhadas, consulte Como ver ou listar recursos de pastas e projetos.

Com os recursos de pasta, é possível delegar direitos de administração. Por exemplo, cada chefe de departamento pode receber a propriedade total de todos os recursos do Google Cloud que pertençam aos próprios departamentos. Da mesma forma, o acesso a recursos pode ser limitado pelo recurso de pasta. Portanto, os usuários de um departamento só podem acessar e criar recursos do Google Cloud nesse recurso de pasta.

O snippet de código a seguir mostra a estrutura de um recurso de pasta:

{
  "createTime": "2030-01-07T21:59:43.314Z",
  "displayName": "Engineering",
  "lifecycleState": "ACTIVE",
  "name": "folders/634792535758",
  "parent": "organizations/34739118321"
}

Assim como os recursos da organização e do projeto, os recursos da pasta atuam como ponto de herança de políticas da IAM e da organização. Os papéis do IAM concedidos em um recurso de pasta são herdados automaticamente por todos os recursos do projeto e da pasta incluídos nessa pasta.

O recurso do projeto

O recurso Projeto é a entidade organizadora do nível base. Os recursos de organização e pasta podem conter vários projetos. Um recurso de projeto é necessário para usar o Google Cloud e forma a base para criar, ativar e usar todos os serviços do Google Cloud, gerenciar APIs, ativar o faturamento, adicionar e remover colaboradores e gerenciar permissões.

Todos os recursos do projeto são os seguintes:

  • Dois identificadores:
    1. ID do recurso do projeto, que é um identificador exclusivo do recurso do projeto.
    2. O número do recurso do projeto, que é atribuído automaticamente na criação dele. Ele é somente leitura.
  • um nome de exibição mutável;
  • O estado do ciclo de vida do recurso do projeto. Por exemplo, ACTIVE ou DELETE_REQUESTED.
  • uma coleção de rótulos que podem ser usados na filtragem de projetos;
  • A hora em que o recurso do projeto foi criado.

O snippet de código a seguir mostra a estrutura de um recurso do projeto:

{
  "createTime": "2020-01-07T21:59:43.314Z",
  "lifecycleState": "ACTIVE",
  "name": "my-project",
  "parent": {
    "id": "634792535758",
    "type": "folder"
  },
  "projectId": "my-project",
  "labels": {
     "my-label": "prod"
  },
  "projectNumber": "464036093014"
}

Para interagir com a maioria dos recursos do Google Cloud, você precisa fornecer as informações de recursos do projeto de identificação para cada solicitação. É possível identificar um recurso de projeto de duas maneiras: pelo código ou pelo número do recurso (projectId e projectNumber no snippet de código).

O ID do recurso do projeto é o nome personalizado que você escolheu quando criou o recurso do projeto. Se você ativar uma API que requer um recurso de projeto, você será direcionado para criar um recurso do projeto ou selecionar um recurso usando o ID do recurso do projeto. A string name, que é exibida na IU, não é igual ao ID do recurso do projeto.

Um número de recurso do projeto é gerado automaticamente pelo Google Cloud. O ID e o número do recurso podem ser encontrados no painel do recurso do projeto no Console do Google Cloud. Para informações sobre como receber identificadores de projeto e outras tarefas de gerenciamento para recursos de projetos, consulte Como criar e gerenciar recursos do projeto.

A política inicial do IAM para o recurso do projeto recém-criado concede o papel de proprietário ao criador do projeto.

Herança de políticas do IAM

O Google Cloud oferece o IAM, que permite atribuir acesso granular a recursos específicos do Google Cloud e impede o acesso indesejado a outros recursos. Por meio da definição de políticas do IAM, é possível controlar quem (usuários) tem que tipo de acesso (papéis) a quais recursos.

É possível definir uma política do IAM no nível da organização, no nível da pasta, no nível do projeto ou, em alguns casos, no nível do recurso. Os recursos herdam as políticas do pai. Se você definir uma política no nível da organização, ela será herdada por todos os recursos filhos da pasta e do projeto. Se for definida no nível do projeto, ela será herdada por todos os recursos filhos.

A política vigente em um recurso é a união da política definida para o recurso com a herdada dos ancestrais. Essa herança é transitiva. Em outras palavras, os recursos herdam as políticas do projeto, que herda as políticas do recurso Organização. Portanto, as políticas no nível da organização também são aplicadas no nível do recurso.

Por exemplo, no diagrama de hierarquia de recursos acima, se você definir uma política na pasta "Departamento Y" que concede o papel "Editor de projeto" a bob@example.com, Bob terá o papel de editor nos projetos "Projeto de desenvolvimento", "Projeto de teste" e "Projeto de produção". Por outro lado, se você atribuir a alice@example.com o papel "Administrador da instância" no projeto "Projeto de teste", ela só poderá gerenciar instâncias do Compute Engine nesse projeto.

Os papéis são sempre herdados e não é possível remover explicitamente uma permissão para um recurso de nível inferior que foi concedido em um nível superior na hierarquia de recursos. Considerando o exemplo acima, mesmo que você removesse o papel "Editor do projeto" atribuído a Bob em "Projeto de teste", ele ainda herdaria esse papel da pasta "Departamento Y". Sendo assim, ele ainda teria as permissões desse papel em "Projeto de teste".

A hierarquia de políticas do IAM segue o mesmo caminho que a hierarquia de recursos do Google Cloud. Se você alterar a hierarquia do recurso, a da política também será modificada. Por exemplo, mover um projeto para um recurso da organização atualizará a política do IAM do projeto para herdar a política do IAM do recurso da organização. Da mesma forma, a transferência de um recurso de projeto de um recurso de pasta para outro altera as permissões herdadas. As permissões herdadas pelo recurso do projeto do recurso pai original serão perdidas quando o recurso do projeto for movido para um novo recurso de pasta. As permissões definidas no recurso da pasta de destino serão herdadas pelo recurso do projeto conforme ele for movido.

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