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 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, especialmente na versão mais completa que inclui um recurso Organização e pastas, as empresas mapeiam a organização no GCP. Além disso, elas recebem pontos de conexão lógica para políticas de gerenciamento de acesso (Cloud Identity and Access Management) e políticas de Organização. As políticas do Cloud IAM e da Organização são herdadas pela hierarquia: a política vigente em cada node é 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 do projeto e das pastas. As políticas de controle de acesso do IAM aplicadas ao recurso Organização são válidas para toda a hierarquia em todos os recursos da organização.

Os usuários do GCP não são obrigados a ter o recurso Organização. Para adquiri-lo, o usuário também precisa ser cliente do G Suite ou do Cloud Identity. O recurso Organização está associado a uma conta do G Suite ou do Cloud Identity. Cada uma dessas contas pode ter exatamente uma Organização provisionada. Por padrão, depois que o recurso 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 de 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 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 Organização:

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

A política inicial de IAM para um recurso 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 IAM. Os papéis de IAM concedidos em uma pasta são herdados automaticamente por todos os projetos e pastas incluídos nela.

O recurso 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, veja Como criar e gerenciar projetos.

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

Herança de políticas do IAM

O Google Cloud Platform oferece o Cloud Identity and Access Management (IAM, na sigla em inglês). Com ele, você concede acesso mais granular a recursos específicos do Google Cloud Platform e impede o acesso não autorizado 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 projeto ou, em alguns casos, no nível do recurso. Os recursos herdam as políticas do node 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 em projetos "Dev GCP", "Test GCP" e "Produção". 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 de políticas do IAM segue o mesmo caminho que a de recursos do GCP. Se você alterar a hierarquia de recursos, a de políticas também será modificada. Por exemplo, quando um projeto é movido para uma organização, a política de 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