Hierarquia de recursos

Esta página descreve a Google Cloud hierarquia de recursos e os recursos que podem ser geridos através do Resource Manager.

A finalidade da hierarquia de recursos Google Cloud é dupla:

• Fornece uma hierarquia de propriedade que vincula o ciclo de vida de um recurso ao respetivo superior imediato na hierarquia.
• Fornecer pontos de ligação e herança para controlo de acesso e políticas de organização.

Metaforicamente, a hierarquia de recursos assemelha-se ao sistema de ficheiros encontrado nos sistemas operativos tradicionais como forma de organizar e gerir entidades hierarquicamente. Google Cloud Geralmente, cada recurso tem exatamente um elemento principal. Esta organização hierárquica de recursos permite-lhe definir políticas de controlo de acesso e definições de configuração num recurso principal. As políticas e as definições de gestão de identidade e de acesso (IAM) são herdadas pelos recursos secundários.

Nota: se estiver a começar a usar o Google Cloud, pode configurar a hierarquia de recursos e conceder acesso inicial como parte do Google Cloud processo de configuração.

Google Cloud hierarquia de recursos em detalhe

Google Cloud Os recursos estão organizados hierarquicamente. Todos os recursos, exceto o recurso mais elevado numa hierarquia, têm exatamente um recurso principal. No nível mais baixo, os recursos de serviço são os componentes fundamentais que compõem todos os Google Cloud serviços. Alguns exemplos de recursos de serviço incluem: máquinas virtuais (MVs) do Compute Engine, tópicos do Pub/Sub, contentores do Cloud Storage e instâncias do App Engine. Todos estes recursos de nível inferior têm recursos de projeto como principais, que representam o primeiro mecanismo de agrupamento da hierarquia de recursos. Google Cloud

Todos os utilizadores, incluindo os utilizadores da avaliação gratuita, os utilizadores do nível gratuito e os clientes do Google Workspace e do Cloud Identity, podem criar recursos de projetos. Os utilizadores do Google Cloud Programa gratuito só podem criar recursos de projetos e recursos de serviços em projetos. Os recursos do projeto podem estar no topo da respetiva hierarquia, mas apenas se forem criados por um utilizador da avaliação gratuita ou do plano gratuito. Os clientes do Google Workspace e do Cloud Identity têm acesso a funcionalidades adicionais da Google Cloud hierarquia de recursos, como recursos de organização e de pasta. Saiba mais na vista geral do Cloud Identity. Os recursos de projeto na parte superior da respetiva hierarquia não têm recursos principais, mas podem ser migrados para um recurso de organização assim que este for criado para o domínio. Para ver mais detalhes sobre a migração de recursos do projeto, consulte o artigo Migrar recursos do projeto.

Os clientes do Google Workspace e do Cloud ID podem criar recursos de organização. Cada conta do Google Workspace ou do Cloud ID está associada a um recurso de organização. Quando existe um recurso de organização, este encontra-se no topo da Google Cloud hierarquia de recursos, e todos os recursos que pertencem a uma organização são agrupados no recurso de organização. Isto oferece visibilidade e controlo centralizados sobre todos os recursos pertencentes a um recurso da organização.

Os recursos de pastas são um mecanismo de agrupamento adicional e opcional entre os recursos de organização e os recursos de projetos. É necessário um recurso de organização como pré-requisito para usar pastas. Os recursos de pastas e os respetivos recursos de projetos secundários são mapeados no recurso de organização.

A Google Cloud hierarquia de recursos, especialmente na sua forma mais completa, que inclui um recurso de organização e recursos de pastas, permite que as empresas mapeiem o respetivo recurso de organização para Google Cloud e fornece pontos de ligação lógicos para políticas de gestão de acesso (IAM) e políticas da organização. As políticas de permissão, restrição e organização são herdadas através da hierarquia, e a política efetiva para cada recurso na hierarquia é o resultado das políticas aplicadas diretamente no recurso e das políticas herdadas dos respetivos antecessores.

O diagrama seguinte representa um exemplo de Google Cloud hierarquia de recursos na sua forma completa:

O recurso da organização

O recurso organization representa uma organização (por exemplo, uma empresa) e é o nó de raiz na Google Cloud hierarquia de recursos quando presente. O recurso de organização é o ancestral hierárquico dos recursos de pastas e projetos. As políticas de permissão e restrição aplicadas no recurso da organização aplicam-se em toda a hierarquia em todos os recursos da organização.

Google Cloud Os utilizadores não têm de ter um recurso de organização, mas algumas funcionalidades do Resource Manager não são utilizáveis sem um. O recurso de organização está estreitamente associado a uma conta do Google Workspace ou do Cloud ID. Quando um utilizador com uma conta do Google Workspace ou do Cloud Identity cria um Google Cloud recurso de projeto, é automaticamente aprovisionado um recurso de organização para esse utilizador.

Uma conta do Google Workspace ou do Cloud ID pode ter exatamente um recurso de organização aprovisionado com a mesma. Depois de criar um recurso de organização para um domínio, todos os novos recursos de projeto criados por membros do domínio da conta pertencem por predefinição ao recurso de organização. Google Cloud Quando um utilizador gerido cria um recurso de projeto, o requisito é que este tem de estar num recurso de organização qualquer. Se um utilizador especificar um recurso de organização e tiver as autorizações corretas, o projeto é atribuído a essa organização. Caso contrário, é predefinido para o recurso da organização ao qual o utilizador está associado. É impossível para as contas associadas a um recurso de organização criar recursos de projeto que não estejam associados a um recurso de organização.

Associe contas do Google Workspace ou Cloud ID

Para simplificar, vamos referir-nos ao Google Workspace, o que significa utilizadores do Google Workspace e do Cloud Identity.

A conta do Google Workspace ou do Cloud ID representa uma empresa e é um pré-requisito para ter acesso ao recurso da organização. No contexto, fornece gestão de identidades, mecanismo de recuperação, propriedade e gestão do ciclo de vida. Google Cloud A imagem abaixo mostra a associação entre a conta do Google Workspace, o Cloud ID e a Google Cloud hierarquia de recursos.

O superadministrador do Google Workspace é o indivíduo responsável pela validação da propriedade do domínio e o contacto em casos de recuperação. Por este motivo, o superadministrador do Google Workspace tem a capacidade de atribuir funções do IAM por predefinição. A principal função do superadministrador do Google Workspace relativamente ao Google Cloud é atribuir a função do IAM de administrador da organização aos utilizadores adequados no respetivo domínio. Isto vai criar a separação entre o Google Workspace e as responsabilidades de administração que os utilizadores procuram normalmente. Google Cloud

Vantagens do recurso de organização

Com um recurso de organização, os recursos do projeto pertencem à sua organização em vez ao funcionário que criou o projeto. Isto significa que os recursos do projeto já não são eliminados quando um funcionário sai da empresa. Em vez disso, seguem o ciclo de vida do recurso da organização no Google Cloud.

Além disso, os administradores da organização têm controlo central de todos os recursos. Podem ver e gerir todos os recursos do projeto da sua empresa. Esta aplicação significa que já não podem existir projetos ocultos nem administradores não autorizados.

Além disso, pode conceder funções ao nível da organização, que são herdadas por todos os recursos de projetos e pastas no recurso de organização. Por exemplo, pode conceder a função de administrador de rede à sua equipa de rede ao nível da organização, o que lhe permite gerir todas as redes em todos os recursos do projeto na sua empresa, em vez de lhe conceder a função para todos os recursos do projeto individuais.

Um recurso de organização exposto pela API Cloud Resource Manager consiste no seguinte:

• Um ID do recurso da organização, que é um identificador exclusivo de uma organização.
• Um nome a apresentar, que é gerado a partir do nome do domínio principal no Google Workspace ou Cloud ID.
• A hora de criação do recurso da organização.
• A data/hora da última modificação do recurso da organização.
• O proprietário do recurso da organização. O proprietário é especificado quando cria o recurso de organização. Não pode ser alterado depois de definido. É o ID de cliente do Google Workspace especificado na API Directory.

O seguinte fragmento de código mostra a estrutura de um recurso organization:

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

A política de autorização inicial para um recurso de organização recém-criado concede as funções de criador do projeto e criador da conta de faturação a todo o domínio do Google Workspace. Isto significa que os utilizadores vão poder continuar a criar recursos de projetos e contas de faturação como faziam antes de o recurso de organização existir. Não são criados outros recursos quando é criado um recurso de organização.

O recurso de pasta

Os recursos de pastas oferecem opcionalmente um mecanismo de agrupamento adicional e limites de isolamento entre projetos. Podem ser vistas como suborganizações no recurso organization. Os recursos de pastas podem ser usados para modelar diferentes entidades legais, departamentos e equipas numa empresa. Por exemplo, um primeiro nível de recursos de pastas pode ser usado para representar os principais departamentos no recurso da sua organização. Uma vez que os recursos de pastas podem conter recursos de projetos e outras pastas, cada recurso de pasta pode incluir outras subpastas para representar diferentes equipas. Cada pasta de equipa pode conter subpastas adicionais para representar diferentes aplicações. Para ver mais detalhes sobre a utilização de recursos de pastas, consulte o artigo Criar e gerir recursos de pastas.

Se existirem recursos de pastas no recurso da sua organização e tiver as autorizações de visualização adequadas, pode vê-los a partir da Google Cloud consola. Para obter instruções mais detalhadas, consulte o artigo Ver ou listar recursos de pastas e projetos.

Os recursos de pastas permitem a delegação de direitos de administração. Por exemplo, a cada chefe de um departamento pode ser concedida a propriedade total de todos os Google Cloud recursos pertencentes aos respetivos departamentos. Da mesma forma, o acesso aos recursos pode ser limitado pelo recurso de pasta, para que os utilizadores num departamento só possam aceder e criar Google Cloud recursos nesse recurso de pasta.

O seguinte fragmento de código 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"
}

Tal como os recursos de organização e de projeto, os recursos de pasta atuam como um ponto de herança de políticas para políticas de permissão, negação e organização. As funções de IAM concedidas num recurso de pasta são automaticamente herdadas por todos os recursos de projeto e de pasta incluídos nessa pasta.

O recurso do projeto

O recurso de projeto é a entidade organizadora de nível base. Os recursos de organização e pasta podem conter vários projetos. É necessário um recurso de projeto para usar Google Cloude constitui a base para criar, ativar e usar todos os Google Cloud serviços, gerir APIs, ativar a faturação, adicionar e remover colaboradores, bem como gerir autorizaçõ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. Número do recurso do projeto, que é atribuído automaticamente quando cria o projeto. É só de leitura.
• Um nome a apresentar mutável.
• O estado do ciclo de vida do recurso do projeto; por exemplo, ACTIVE ou DELETE_REQUESTED.
• Uma coleção de etiquetas que podem ser usadas para filtrar projetos.
• A hora em que o recurso do projeto foi criado.

O seguinte fragmento do código 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 Google Cloud recursos, tem de fornecer as informações de recursos do projeto de identificação para cada pedido. Pode identificar um recurso do projeto de duas formas: um ID do recurso do projeto ou um número do recurso do projeto (projectId e projectNumber no fragmento do código).

Um ID do recurso do projeto é o nome personalizado que escolheu quando criou o recurso do projeto. Se ativar uma API que requer um recurso de projeto, é-lhe pedido que crie um recurso de projeto ou selecione um recurso de projeto através do respetivo ID do recurso de projeto. (Tenha em atenção que a string name, que é apresentada na IU, não é igual ao ID do recurso do projeto.)

Um número de recurso do projeto é gerado automaticamente por Google Cloud. Pode encontrar o ID do recurso do projeto e o número do recurso do projeto no painel de controlo do recurso do projeto na Google Cloud consola. Para obter informações sobre como obter identificadores de projetos e outras tarefas de gestão para recursos de projetos, consulte o artigo Criar e gerir recursos de projetos.

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

Permita e recuse a herança de políticas

Google Cloud oferece a IAM, que lhe permite atribuir acesso detalhado a recursos Google Cloud específicos e impede o acesso indesejado a outros recursos. O IAM permite-lhe controlar quem (utilizadores) tem que acesso (funções) a que recursos definindo políticas de permissão e negação nos recursos.

Pode definir políticas de permissão e recusa em recursos da organização, recursos de pastas e recursos de projetos. Também pode definir políticas de permissão em alguns recursos de serviço.

Os recursos herdam as políticas do recurso principal. Se definir uma política de permissão ou restrição ao nível da organização, esta é herdada por todos os recursos subordinados. Se definir uma política de permissão ao nível do projeto, esta é herdada por todos os respetivos recursos subordinados.

A política de permissão ou negação efetiva para um recurso é a união da política de permissão ou negação definida no recurso e a política de permissão ou negação herdada dos respetivos antecessores. Esta herança é transitiva. Para mais informações, consulte o artigo Avaliação de políticas.

Por exemplo, no diagrama da hierarquia de recursos anterior, se definir uma política de permissão na pasta "Departamento Y" que conceda a função de administrador da instância do Compute Engine (roles/compute.instanceAdmin) a [e-mail], o Bob terá essa função no "Projeto de desenvolvimento", no "Projeto de teste" e no "Projeto de produção". Se atribuir o papel de administrador de instâncias do Compute Engine a [e-mail] no "Projeto de teste", só pode gerir instâncias do Compute Engine nesse projeto.

As funções são sempre herdadas. Se removeu a função de administrador (roles/compute.instanceAdmin) da instância do Compute Engine do utilizador Bob no "Projeto de teste", este herda essa função da pasta "Departamento Y". Pode usar uma política de recusa para impedir que os responsáveis usem autorizações herdadas.

As políticas de permissão e negação são herdadas através da hierarquia de recursos Google Cloud . Se alterar a hierarquia de recursos, a hierarquia da política de permissão e negação também é alterada. Por exemplo, mover um projeto para um recurso de organização atualiza as políticas de permissão e restrição do projeto para herdar as políticas de permissão e restrição do recurso de organização. Da mesma forma, mover um recurso de projeto de um recurso de pasta para outro altera as autorizações herdadas. As autorizações que foram herdadas pelo recurso do projeto do recurso principal original são perdidas quando o recurso do projeto é movido para um novo recurso de pasta. As autorizações definidas no recurso da pasta de destino são herdadas pelo recurso do projeto à medida que é movido.

Experimente

Se for um novo utilizador do Google Cloud, crie uma conta para avaliar o desempenho dos nossos produtos em cenários reais. Os novos clientes também recebem 300 USD em créditos gratuitos para executar, testar e implementar cargas de trabalho.

Comece gratuitamente