Hierarquia de recursos

Esta página descreve a hierarquia de recursos do Google Cloud e os recursos que podem ser gerenciados com o Gerenciador de Recursos

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. Cada recurso tem um pai. Com essa organização hierárquica, é possível definir políticas de controle de acesso e configurações em um recurso pai. Além disso, os filhos herdam as políticas e configurações do Cloud Identity and Access Management (Cloud IAM).

Hierarquia de recursos do Google Cloud em detalhes

No nível mais baixo, os recursos são os componentes fundamentais que compõem todos os serviços do Google Cloud. Exemplos de recursos incluem Máquinas virtuais do Compute Engine (VMs), tópicos Pub/Sub, buckets do Cloud Storage, instâncias do App Engine. Todos esses recursos de nível inferior só podem ter projetos como pai, que representam o primeiro mecanismo de agrupamento da hierarquia de recursos do Google Cloud.

Os clientes do G Suite e do Cloud Identity têm acesso a recursos adicionais da hierarquia de recursos do Google Cloud que oferecem benefícios como visibilidade e controle centralizados e outros mecanismos de agrupamento, como pastas. Lançamos a ferramenta de gerenciamento Cloud Identity. Para ver detalhes sobre como usá-la, consulte Como migrar para o Cloud Identity.

Os recursos do Google Cloud são organizados hierarquicamente. A base dela são os projetos, que compõem o primeiro nível e contêm outros recursos. Todos os recursos têm exatamente um pai, exceto as organizações. Organizações ficam no topo da hierarquia e não têm pai.

O recurso Organização é o nó raiz da hierarquia de recursos do Google Cloud e todos os recursos pertencentes a uma organização são agrupados no nó da organização. Isso proporciona visibilidade e controle centralizados sobre todos os recursos dessa organização.

Um mecanismo de agrupamento adicional, além dos projetos, são as pastas. Ter um recurso Organização é um pré-requisito para usá-las. Todos os projetos e pastas são mapeados nesse recurso.

A hierarquia de recursos do Google Cloud, especialmente em sua forma mais completa que inclui pastas e recursos da Organização, permite às empresas mapear sua organização no Google Cloud e fornece pontos lógicos de anexação para políticas de gerenciamento de acesso (Cloud IAM, em inglês) e Políticas da organização. As políticas do Cloud IAM e da organização são herdadas pela hierarquia: a política vigente em cada nó é o resultado daquelas aplicadas diretamente nele mais as herdadas dos ancestrais.

O diagrama abaixo representa um exemplo completo de hierarquia de recursos do Google Cloud:

Hierarquia de recursos

O recurso 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. Ele é o ancestral hierárquico dos recursos de projeto e de pastas. As políticas de controle de acesso do Cloud IAM aplicadas à organização são válidas para toda a hierarquia, em todos os recursos na organização.

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

Cada conta do G Suite ou do Cloud Identity pode ter uma organização provisionada. Assim que um recurso Organização é criado para um domínio, todos os projetos do Google Cloud criados por membros do domínio da conta pertencerão, por padrão, ao recurso Organização.

Para simplificar, vamos nos referir ao G Suite tanto para usuários do G Suite quanto do Cloud Identity.

A conta do G Suite ou Cloud Identity representa uma empresa e é um pré-requisito para ter acesso ao recurso 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 G Suite, o Cloud Identity e a hierarquia de recursos do Google Cloud.

Organização do G Suite


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

Benefícios do recurso Organização

Com o recurso Organização, os projetos não pertencem aos funcionários, e sim à organização. Isso significa que os projetos não são mais excluídos quando um funcionário deixa a empresa. Em vez disso, eles seguirão o ciclo de vida da organização no Google Cloud.

Além disso, os administradores da organização têm controle central de todos os recursos. Eles podem visualizar e gerenciar todos os projetos da empresa. Com essa imposição, não haverá mais projetos 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 projetos e pastas abaixo do recurso Organização. Por exemplo, é possível atribuir o papel de Administrador de rede à equipe de rede no nível da organização, em vez de concedê-lo para cada projeto individual. Assim, a equipe poderá gerenciar todas as redes em todos os projetos na empresa.

O recurso Organização criado com a Resource Manager API consiste nos seguintes itens:

  • Um código de organização, que é um identificador exclusivo para uma organização
  • Um nome de exibição, gerado a partir do nome do domínio principal do G Suite ou do Cloud Identity.
  • A hora de criação da organização.
  • A hora da última modificação da organização.
  • O proprietário da organização. O proprietário é especificado durante a criação do recurso Organização. Depois de definido, ele não pode ser alterado. É o ID do cliente do G Suite que foi especificado na API Directory.

O snippet de código a seguir mostra a estrutura do recurso Organização:

{
  "displayName": "myorganization",
  "organizationId":"34739118321",
  "createTime": "2016-01-07T21:59:43.314Z"
  "owner": {
    "directoryCustomerId": "C012BA234"
   }
}

A política inicial do Cloud IAM para um recurso de 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 G Suite. O significado disso é que os usuários poderão criar projetos e contas de faturamento como faziam antes de a organização existir. Quando um recurso Organização é criado, nenhum outro recurso é gerado.

O recurso Pasta

Os recursos de Pasta fornecem um mecanismo de agrupamento adicional e limites para isolamento entre projetos. Eles podem ser vistos como suborganizações dentro da Organização. As Pastas podem ser usadas para modelar diferentes pessoas jurídicas, departamentos e equipes em uma empresa. Por exemplo, o primeiro nível de pastas poderia ser usado para representar os departamentos principais na organização. Como elas podem conter projetos e outras pastas, cada uma pode incluir outras subpastas para representar equipes diferentes. Além disso, cada pasta de equipe pode conter subpastas adicionais para representar diferentes aplicativos. Para ver mais detalhes sobre o uso de pastas, consulte Como criar e gerenciar pastas.

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

As pastas permitem que direitos de administração sejam designados. Por exemplo, cada chefe de departamento pode ter a propriedade total de todos os recursos do Google Cloud que pertençam a seus departamentos. Da mesma forma, o acesso a recursos pode ser limitado por pasta, de modo que os usuários de um departamento só possam acessar e criar recursos do Cloud dentro dessa pasta.

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

{
 "name" : "folders/my-folder",
 "parent" : "organizations/my-organization",
 "displayName" : "Engineering",
 "lifecycleState" : "ACTIVE",
 "createTime": "2016-01-07T21:59:43.314Z"
}

Assim como as organizações e os projetos, as pastas atuam como um ponto de herança das políticas da organização e do Cloud IAM. Os papéis do Cloud IAM concedidos em uma pasta são herdados automaticamente por todos os projetos e pastas incluídos nela.

Recurso de projeto

O recurso Projeto é a entidade organizadora do nível base. Organizações e pastas podem conter vários projetos. Um 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 projetos consistem em:

  • Dois identificadores:
    1. O código do projeto, que é um identificador exclusivo do projeto.
    2. O número do projeto, que é atribuído automaticamente na criação de um projeto. Ele é somente leitura.
  • um nome de exibição mutável
  • o estado do ciclo de vida 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 projeto foi criado

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

{
  "name": "myproject",
  "projectId": "my-project-123",
  "labels":
   {
     "my-label": "prod"
   },
   "projectNumber": "464036093014",
   "lifecycleState": "ACTIVE",
   "createTime": "2016-01-07T21:59:43.314Z"
}

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

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

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

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

Herança de políticas do Cloud IAM

O Google Cloud oferece o Cloud 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 Cloud IAM, você atribui papéis aos usuários para que eles acessem recursos específicos.

É possível definir uma política do Cloud IAM no nível da organização, da pasta, do projeto ou, em alguns casos, do recurso. Os recursos herdam as políticas do nó pai. Se você definir uma política no nível da Organização, ela será herdada por todas as pastas e projetos filho. Se for defini-la no nível do projeto, ela será herdada por todos os recursos filho.

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. Ou seja, os recursos herdam políticas do projeto, que herda da organização. Portanto, as políticas no nível da organização também se aplicam no nível do recurso.

Hierarquia de recursos


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

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 do recurso, a da política também será modificada. Por exemplo, quando um projeto é movido para uma organização, a política do Cloud IAM desse projeto herda a política da organização. Da mesma forma, se um projeto for movido de uma pasta para outra, as permissões herdadas serão alteradas. As permissões herdadas do pai original serão perdidas quando o projeto for movido para uma nova pasta. As permissões definidas na pasta de destino serão herdadas pelo projeto quando ele for movido.