Hierarquia de recursos

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

Podemos comparar a hierarquia de recursos do Google Cloud ao sistema de arquivos encontrado nos sistemas operacionais comuns. Isso porque ambos organizam e gerenciam entidades em hierarquias. Em geral, 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. Além disso, as políticas e configurações do Identity and Access Management (IAM) são herdadas pelos recursos filhos.

Google Cloud hierarquia de recursos em detalhes

Os recursos doGoogle 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 que compõem 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, incluindo os de teste gratuito, nível gratuito e clientes do Google Workspace e do Cloud Identity, podem criar recursos de projeto. Os usuários do Google Cloud Programa gratuito só podem criar recursos de projeto e de serviço dentro dos projetos. Os recursos do projeto podem ser o topo da hierarquia, mas apenas se forem criados por um usuário do teste sem custo financeiro ou do nível sem custos financeiros. Os clientes do Google Workspace e do Cloud Identity têm acesso a outros recursos da hierarquia de recursos Google Cloud , como recursos de organização e pasta. Saiba mais na visão geral do Cloud Identity. Os recursos de projeto na parte superior da hierarquia não têm recursos principais, mas podem ser migrados para um recurso de organização depois que ele for criado para o domínio. Para mais detalhes sobre como migrar recursos do projeto, consulte Migrar recursos do projeto.

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

Os recursos de pasta são um mecanismo de agrupamento adicional e opcional entre os recursos de organização e de projeto. Um recurso de organização é necessário como pré-requisito para usar pastas. Os recursos de pasta e os recursos de projeto filhos são mapeados no recurso de organização.

A hierarquia de recursos do Google Cloud , especialmente em sua forma mais completa que inclui um recurso de organização e recursos de pasta, permite que as empresas mapeiem o recurso de organização para o Google Cloud e fornece pontos lógicos de anexação para políticas de gerenciamento de acesso (IAM) e políticas da organização. As políticas de permissão, negação e da organização são herdadas pela hierarquia, e a política vigente para cada recurso é o resultado das políticas aplicadas diretamente a ele e das políticas herdadas dos ancestrais.

O diagrama a seguir representa um exemplo completo de hierarquia de recursos Google Cloud :

O recurso da organização

O recurso organização representa uma organização (por exemplo, uma empresa) e é o nó raiz na hierarquia de recursos doGoogle Cloud , quando presente. Ele é o ancestral hierárquico dos recursos de pasta e projeto. As políticas de permissão e negação aplicadas ao recurso organização são válidas para toda a hierarquia, em todos os recursos da organização.

Os usuários doGoogle Cloud não precisam ter um recurso de organização, mas alguns recursos do Resource Manager não poderão ser usados sem um. O recurso de organização está 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 Google Cloud projeto, um recurso de organização é provisionado automaticamente para ele.

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

Vincular as contas do Google Workspace ou do Cloud Identity

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 de 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 doGoogle 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 função principal do superadministrador do Google Workspace com relação ao Google Cloud é atribuir o papel de administrador da organização do IAM aos usuários apropriados no domínio. Isso criará a separação entre o Google Workspace e as responsabilidades de administração do Google Cloudque os usuários normalmente procuram.

Benefícios do recurso "Organização"

Com um recurso de organização, os recursos do projeto pertencem à sua organização e não ao funcionário que criou o projeto. Isso significa que os recursos do projeto não são mais excluídos quando um funcionário deixa a empresa. Em vez disso, eles seguem 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 visualizar e gerenciar todos os recursos de projeto 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 recursos de projeto e pasta abaixo do recurso de 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 recurso de projeto individual. Assim, a equipe poderá gerenciar todas as redes em todos os recursos de projeto na empresa.

Um recurso de organização exposto pela API Cloud Resource Manager tem as características a seguir:

• Um ID de recurso da organização, que é um identificador exclusivo para uma organização.
• Um nome de exibição, gerado a partir do nome do domínio principal no Google Workspace ou no Cloud Identity.
• A hora de criação do recurso da organização.
• A hora da última modificação do recurso da organização.
• O proprietário do recurso da organização. O proprietário é especificado durante a criação do recurso de 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 de organização:

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

A política de permissão inicial para um recurso de organização recém-criado concede os papéis de Criador de projetos 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 projeto e contas de faturamento como faziam antes de o recurso da organização existir. Quando um recurso de organização é criado, nenhum outro recurso é gerado.

O recurso de pasta

Os recursos de pasta podem fornecer um mecanismo de agrupamento adicional e limites para isolamento entre projetos. Eles podem ser vistos como suborganizações dentro do recurso da organização. 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 no recurso da organização. Como os recursos de pasta podem conter recursos de projeto e outras pastas, 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 pastas, consulte Como criar e gerenciar recursos de pastas.

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

Com os recursos de pastas, é possível delegar direitos de administração. Por exemplo, cada chefe de departamento pode receber a propriedade total de todos os recursos do Google Cloudque pertençam aos próprios departamentos. Da mesma forma, o acesso a recursos pode ser limitado por recurso de pasta, de modo que os usuários de um departamento só possam acessar e criar recursos Google Cloud dentro desse 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 de organização e projeto, os recursos de pasta atuam como um ponto de herança de política para políticas de permissão, negação e da organização. Os papéis do IAM concedidos em um recurso de pasta são herdados automaticamente por todos os recursos de projeto e pasta incluídos nela.

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 Cloude forma a base para criar, ativar e usar todos os serviços doGoogle Cloud , gerenciar APIs, ativar o faturamento, adicionar e remover colaboradores e gerenciar permissões.

Todos os recursos do projeto consistem no seguinte:

• 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 quando você cria o projeto. 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 de 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 identificação do projeto para cada solicitação. É possível identificar um recurso de projeto de duas maneiras: um ID ou um número (projectId e projectNumber no snippet de código).

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

Um número de recurso de projeto é gerado automaticamente pelo Google Cloud. O ID e o número do recurso do projeto podem ser encontrados no painel do recurso do projeto no console Google Cloud . Para informações sobre como conseguir identificadores de projeto e outras tarefas de gerenciamento para recursos de projeto, consulte Como criar e gerenciar recursos de 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.

Permitir e negar herança de políticas

OGoogle Cloud oferece o IAM, que permite atribuir acesso granular a recursos específicos do Google Cloud e impede o acesso indesejado a outros recursos. Com o IAM, é possível controlar quem (usuários) tem que tipo de acesso (papéis) a quais recursos. Basta definir políticas de permissão e negação nos recursos.

É possível definir políticas de permissão e negação em recursos da organização, recursos de pastas e recursos de projetos. Também é possível definir políticas de permissão em alguns recursos de serviço.

Os recursos herdam as políticas do recurso pai. Se você definir uma política de permissão ou negação no nível da organização, ela será herdada por todos os recursos filhos. Se você definir uma política de permissão no nível do projeto, ela será herdada por todos os recursos filhos.

A política de permissão ou negação efetiva de um recurso é a união da política de permissão ou negação definida no recurso com a política de permissão ou negação herdada dos ancestrais. Essa herança é transitiva. Para mais informações, consulte Avaliação de políticas.

Por exemplo, no diagrama de hierarquia de recursos anterior, se você definir uma política de permissão na pasta "Departamento Y" que conceda o papel de Administrador da instância do Compute Engine (roles/compute.instanceAdmin) a bob@example.com, Bob terá esse papel nos projetos "Projeto de desenvolvimento", "Projeto de teste" e "Projeto Production". Se você atribuir a alice@example.com o papel de administrador da instância do Compute Engine no projeto "Projeto de teste", ela só poderá gerenciar instâncias do Compute Engine nesse projeto.

As funções são sempre herdadas. Se você remover o papel de administrador da instância do Compute Engine (roles/compute.instanceAdmin) de Bob no projeto de teste, ele vai herdar esse papel da pasta "Departamento Y". É possível usar uma política de negação para impedir que os principais usem permissões herdadas.

As políticas de permissão e negação são herdadas pela hierarquia de recursos do Google Cloud . Se você alterar a hierarquia de recursos, a hierarquia de políticas de permissão e de negação também será modificada. Por exemplo, mover um projeto para um recurso de organização atualiza as políticas de permissão e de negação do projeto para herdar as políticas de permissão e de negação do recurso de organização. Da mesma forma, mover um recurso de projeto de uma pasta para outra muda as permissões herdadas. As permissões herdadas do recurso pai original serão perdidas quando o recurso de projeto for movido para um novo recurso de pasta. As permissões definidas no recurso de pasta de destino serão herdadas pelo recurso de projeto quando ele for movido.