Hierarquia de recursos

Nesta página, você encontra a descrição da hierarquia de recursos do Google Cloud Platform (GCP) e dos que podem ser gerenciados com o Resource Manager.

A hierarquia de recursos do GCP tem dois propósitos:

  • 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.

Podemos comparar a hierarquia de recursos do GCP ao sistema de arquivos encontrado nos sistemas operacionais comuns. Isso porque ambos organizam e gerenciam entidades em hierarquias. 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).

Detalhes da hierarquia de recursos do GCP

No nível mais baixo, os recursos são os componentes fundamentais que constituem todos os serviços do GCP. Exemplos de recursos incluem máquinas virtuais (VMs, na sigla em inglês) do Compute Engine, tópicos do Cloud Pub/Sub, intervalos do Cloud Storage e instâncias do App Engine. Todos esses recursos de nível mais baixo só podem ter projetos como pai, que representam o primeiro mecanismo de agrupamento da hierarquia de recursos do GCP.

Os clientes do G Suite e do Cloud Identity têm acesso a mais recursos da hierarquia do GCP. Eles fornecem 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 GCP são organizados em hierarquia. 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 nó raiz da hierarquia do GCP é o recurso Organização. Todos os recursos pertencentes à organização estão agrupados nele. 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.

Com a hierarquia de recursos do GCP, principalmente na sua forma mais completa que inclui pastas e um recurso de organização, as empresas podem mapear a organização para o GCP. Além disso, ela fornece pontos lógicos de anexação para políticas de gerenciamento de acesso (Cloud IAM) e 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 da hierarquia de recursos do GCP na versão completa:

Hierarquia de recursos

O recurso Organização

O recurso Organização representa uma organização (por exemplo, uma empresa) e é o node raiz na hierarquia de recursos do GCP. 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 GCP não precisam ter um recurso de organização. No entanto, alguns recursos do Resource Manager não poderão ser usados. A organização está associada a uma conta do G Suite ou do Cloud Identity. Quando um usuário com essa conta cria um projeto do GCP, um recurso de organização é provisionado automaticamente para ele.

Cada conta do G Suite ou do Cloud Identity pode ter uma organização provisionada. Por padrão, depois que o recurso de organização é criado para um domínio, todos os projetos do GCP feitos pelos membros do domínio da conta pertencerão ao recurso.

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 GCP, fornece gerenciamento de identidade, mecanismo de recuperação, propriedade e gerenciamento do ciclo de vida. A figura abaixo mostra o vínculo entre a conta do G Suite, o Cloud Identity e a hierarquia de recursos do GCP.

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. A função principal do superadministrador do G Suite com relação ao GCP é atribuir o papel do Cloud IAM "Administrador da organização" aos usuários apropriados no domínio. As responsabilidades de administração do G Suite e do GCP serão separadas. Isso é o que os usuários costumam buscar.

Benefícios do recurso de 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 empregado sai da empresa. Em vez disso, eles seguem o ciclo de vida da organização no Google Cloud Platform.

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 código de cliente do G Suite que foi especificado na API Directory.

O snippet de código a seguir mostra a estrutura do recurso de 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 você tiver recursos Pasta na organização e permissões de visualização apropriadas, será possível visualizá-los no Console do Google Cloud Platform. Para ver instruções mais detalhadas, consulte Como visualizar e listar pastas e projetos.

Com as pastas, é possível delegar direitos de administração. Por exemplo, cada chefe de departamento pode receber a propriedade total de todos os recursos do GCP que pertençam aos próprios 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 é obrigatório para usar o Google Cloud Platform e ele é a base para criar, habilitar e usar todos os serviços do GCP, 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 maior parte dos recursos do GCP, é necessário fornecer as informações de identificação do projeto para cada solicitação. Um projeto pode ser identificado de duas maneiras: pelo código ou pelo número do projeto (projectId e projectNumber no snippet de código).

Código do projeto é o nome personalizado que você escolheu quando criou o projeto. Se você ativar uma API que requeira um projeto, você será direcionado para criar ou selecionar um projeto usando seu código do projeto (observe que a string name, que é exibida na IU, não é igual ao código do projeto).

Um número de projeto é gerado automaticamente pelo GCP. Tanto o código quanto o número do projeto podem ser encontrados no painel do projeto, no console do Google Cloud Platform. Para informações sobre como conseguir identificadores e outras tarefas de gerenciamento de projetos, consulte 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 Platform oferece o Cloud IAM. Com ele, é possível atribuir acesso granular a recursos específicos do Google Cloud Platform e impedir 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 do recurso em alguns casos. 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 de "Editor de projeto" a bob@example.com, Bob terá o papel de editor nos projetos "Dev GCP", "Test GCP" e "Production". Por outro lado, se você atribuir a alice@example.com o papel de "Administrador da instância" no projeto "Test GCP", ela poderá gerenciar apenas as instâncias do Compute Engine nesse projeto.

A hierarquia da política do Cloud IAM segue o mesmo caminho que a hierarquia do recurso do GCP. 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Resource Manager