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 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 que você defina o acesso as políticas de controle e definições de configuração em um recurso pai e a as políticas e as configurações do Identity and Access Management (IAM) são herdadas pelo filho do Google Cloud.

Hierarquia de recursos do Google Cloud em detalhes

Os recursos do Google Cloud são organizados hierarquicamente. Todos os recursos, exceto para o recurso 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: Máquinas virtuais (VMs) do Compute Engine, tópicos do Pub/Sub, Cloud Storage buckets do Compute Engine, instâncias do App Engine. Todos esses recursos de nível inferior têm projeto recursos como pais, que representam o primeiro agrupamento da hierarquia de recursos do Google Cloud.

Todos os usuários, incluindo os de teste gratuito, os usuários no nível gratuito, os usuários do Google Workspace e Os clientes do Cloud Identity podem criar recursos do projeto. Os usuários do programa gratuito do Google Cloud só podem criar recursos do projeto e recursos de serviço dentro dos projetos. Os recursos do projeto podem o topo de sua hierarquia, mas somente se criado por um usuário de avaliação gratuita usuário de nível mais alto. Clientes do Google Workspace e do Cloud Identity têm acesso a mais funcionalidades da hierarquia de recursos do Google Cloud, como recursos de organização e pasta. Saiba mais em a visão geral do Cloud Identity. Os recursos do projeto no topo da hierarquia não têm pais recursos, mas eles podem ser migrados para um recurso da organização quando foi criado para o domínio. Para mais detalhes sobre a migração de recursos do projeto, consulte Como migrar recursos do projeto.

Os clientes do Google Workspace e do Cloud Identity podem criar organizações do Google Cloud. 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 está no topo da hierarquia de recursos do Google Cloud, e todos os recursos que pertencem a uma organização são agrupados sob o recurso de organização. Isso proporciona visibilidade e controle centralizados sobre todos os recursos um recurso da organização.

Os recursos de pasta são um mecanismo de agrupamento opcional entre da organização e do projeto. Um recurso da organização como pré-requisito para usar as pastas. Recursos da pasta e os filhos deles recursos do projeto são mapeados sob o recurso da organização.

A hierarquia de recursos do Google Cloud, especialmente na forma mais completa que inclui um recurso de organização e recursos de pasta, permite que as empresas para mapear o recurso da organização no Google Cloud e fornecer um anexo lógico para políticas de gerenciamento de acesso (IAM) e Políticas da organização. Ambos IAM e as políticas da organização são herdadas pela hierarquia, e as políticas política para cada recurso na hierarquia é o resultado das políticas diretamente são aplicadas ao recurso e às políticas herdadas dos ancestrais.

O diagrama abaixo representa um exemplo de hierarquia de recursos do Google Cloud seu formulário completo:

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 do Google Cloud, quando presente. O recurso da organização o ancestral hierárquico dos recursos de pasta e projeto. O Políticas de controle de acesso do IAM aplicadas ao recurso da organização se aplicam em toda a hierarquia a todos os recursos da organização.

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

Uma conta do Google Workspace ou do Cloud Identity pode ter exatamente um recurso da organização provisionado com ele. Quando um recurso da organização é criados para um domínio, todos os novos recursos de projetos do Google Cloud criados os membros do domínio da conta pertencerão à organização por padrão recurso. Quando um usuário gerenciado cria um recurso do projeto, o requisito é que ele precisa estar em algum recurso da organização. Se um usuário especificar recurso da organização e tem as permissões corretas, o projeto é atribuídas a essa organização. Caso contrário, o padrão será a organização o recurso a que o usuário está associado. É impossível que contas associadas a um recurso da organização para criar recursos de projeto não associados a um recurso da 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 empresa e é um pré-requisito para ter acesso ao recurso da organização. Em no contexto do Google Cloud, oferece gerenciamento de identidade, propriedade e gerenciamento do ciclo de vida. A imagem abaixo mostra o link entre a conta do Google Workspace, o Cloud Identity 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. O superadministrador do Google Workspace principal trabalho no Google Cloud é atribuir à Organização Administrador 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 Cloud que os usuários normalmente procuram.

Benefícios do recurso de organização

Com um recurso da organização, os recursos do projeto pertencem à sua organização em vez do funcionário que criou o projeto. Isso significa que o projeto recursos não são mais excluídos quando um funcionário sai da empresa; em vez eles vão seguir o ciclo de vida dos recursos 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 dos projetos da empresa. Isso aplicação significa que não podem mais haver projetos sombra ou administradores não autorizados.

Também é possível conceder papéis no nível da organização, que são herdados por todos de projeto e de pasta no recurso da organização. Por exemplo, pode conceder o papel de Administrador de rede à sua equipe de rede na organização o que permite que ele gerencie todas as redes em todos os recursos do projeto em seu empresa, em vez de conceder a elas o papel para todos os recursos individuais do projeto.

O recurso da organização exposto pela API Cloud Resource Manager consiste no seguintes:

• Um ID de recurso da organização, que é um identificador exclusivo de uma organização.
• 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 na criação 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 de 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 de projetos e Criador da conta de faturamento a toda domínio do Google Workspace. Isso significa que os usuários poderão continuar criando recursos do projeto e contas de faturamento, recurso da organização. Nenhum outro recurso é criado recurso da organização é criado.

O recurso de pasta

Os recursos de pasta podem fornecer um mecanismo de agrupamento adicional e limites de isolamento entre projetos. Eles podem ser considerados suborganizações no 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 poderia ser usado para representar departamentos no recurso da sua organização. Como os recursos da pasta podem conter arquivos recursos e outras pastas, cada recurso de pasta poderia incluir em 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 existirem recursos de pasta em seu recurso de organização e você tiver recursos apropriados pelo console do Google Cloud. Para mais instruções detalhadas, consulte Como visualizar ou listar recursos de pastas e projetos.

Os recursos de pasta permitem a delegação de direitos administrativos. Por exemplo, cada o chefe de um departamento pode receber a propriedade total de todos o Google Cloud recursos que pertencem aos seus departamentos. Da mesma forma, o acesso a recursos pode limitada por recurso de pasta, para que os usuários em um departamento só possam acessar e criar recursos do 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 da organização e do projeto, os recursos da pasta atuam como uma política de herança para as políticas da organização e do IAM. Os papéis do IAM concedidos em um recurso de pasta são automaticamente herdado por todos os recursos de projeto e pasta incluídos nessa pasta.

O recurso do projeto

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

Todos os recursos do projeto consistem em:

• Dois identificadores:
  1. ID do recurso do projeto, que é um identificador exclusivo do projeto recurso.
  2. O número de recurso do projeto, que é atribuído automaticamente ao criar 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 recurso do projeto para cada solicitação. Você pode identificar um recurso do projeto de duas maneiras: um ID de recurso do projeto ou um número de recurso (projectId e projectNumber no snippet de código).

O ID de recurso do projeto é o nome personalizado que você escolheu quando criou o recurso do projeto. Se você ativar uma API que exige um recurso de projeto, serão direcionados para criar um recurso de projeto ou selecionar um recurso de projeto usando o ID do recurso do projeto. Observe que a string name, que é exibida na UI, não é o mesmo que o ID de recurso do projeto.)

Um recurso do projeto é gerado automaticamente pelo Google Cloud. Tanto o projeto o ID e o número do recurso do projeto podem ser encontrados no painel do recurso de projeto no console do Google Cloud. Para informações sobre como conseguir o identificadores e outras tarefas de gerenciamento de recursos do projeto 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 recurso pai. Se você definir uma política no nível da organização, ele é herdado por todas as pastas filhas e recursos e, se você definir uma política para envolvidos no projeto, ela será herdada por todos os recursos filhos dela.

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 políticas do projeto, herdam as políticas do recurso da organização. Portanto, a As políticas no nível da organização também se aplicam 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 [email protected], 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 [email protected] 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 recurso da organização atualizará a política de IAM do projeto para herdam da política do IAM do recurso da organização. Da mesma forma, mover um recurso do projeto de um recurso de pasta para outro altera a permissões herdadas. Permissões que foram herdadas pelo recurso do projeto do recurso pai original serão perdidos quando o recurso do projeto for movidos para um novo recurso de pasta. Permissões definidas na pasta de destino recurso será herdado pelo do projeto quando for movido.