VPC compartilhada

Nesta página, apresentamos uma visão geral da VPC compartilhada no Google Cloud. A VPC compartilhada permite que uma organização conecte recursos de vários projetos a uma rede de nuvem privada virtual (VPC) comum para que eles possam se comunicar de maneira segura e eficiente usando endereços IPs internos dessa rede.

Quando você usa a VPC compartilhada, é preciso designar um projeto como um projeto host e anexar um ou mais projetos de serviço. As redes VPC no projeto host são chamadas de redes VPC compartilhadas. Recursos qualificados de projetos de serviço podem usar sub-redes na rede VPC compartilhada.

Usando a VPC compartilhada, os administradores da organização delegam aos administradores de projeto de serviço responsabilidades administrativas, como a criação e o gerenciamento de instâncias, enquanto mantêm o controle centralizado dos recursos da rede, como sub-redes, rotas e firewalls. Esse modelo permite que as organizações façam o seguinte:

  • Implementem uma prática recomendada de segurança de menor privilégio para a administração de rede, auditoria e controle de acesso. Os administradores de VPCs compartilhadas podem delegar tarefas de administração de rede a administradores de rede e segurança na rede VPC compartilhada sem permitir que os administradores de projetos de serviços façam alterações com impacto na rede. Os administradores de projetos de serviços só têm a capacidade de criar e gerenciar instâncias que fazem uso da rede VPC compartilhada. Consulte a seção administradores e IAM para ver mais detalhes.
  • Apliquem e imponham políticas de controle de acesso consistentes no nível da rede para vários projetos de serviço na organização enquanto delegam responsabilidades administrativas. Por exemplo, os administradores do projeto de serviço podem ser administradores de instâncias do Compute no projeto para criar e excluir instâncias que usam sub-redes aprovadas no projeto host da VPC compartilhada.
  • Usem projetos de serviço para separar os centros de orçamento ou de custos internos. Consulte a seção de faturamento para saber mais detalhes.

Conceitos

Organizações, pastas e projetos

A VPC compartilhada conecta projetos dentro da mesma organização. Os projetos vinculados podem estar em pastas iguais ou diferentes, mas se estiverem em pastas diferentes, o administrador precisa ter os direitos de administrador de VPC compartilhada em ambas as pastas. Consulte a hierarquia de recursos do Google Cloud para ver mais informações sobre organizações, pastas e projetos.

Os projetos host e de serviço participantes não podem pertencer a organizações diferentes. A única exceção é durante uma migração dos projetos de uma organização para outra. Durante a migração, os projetos de serviço podem estar em uma organização diferente do projeto host temporariamente. Para mais informações sobre a migração de projetos, consulte Como migrar projetos.

Um projeto que participa da VPC compartilhada é um projeto host ou um projeto de serviço.

  • O projeto host contém uma ou mais redes VPC compartilhadas. Um administrador de VPC compartilhada precisa primeiro ativar um projeto como um projeto host. Depois disso, um administrador de VPC compartilhada pode anexar um ou mais projetos de serviço a ele.

  • Um projeto de serviço é qualquer projeto que tenha sido anexado a um projeto host por um administrador de VPC compartilhada. Esse anexo permite que participe da VPC compartilhada. É comum ter vários projetos de serviço operados e administrados por equipes ou departamentos diferentes na sua organização.

  • Um projeto não pode ser simultaneamente host e de serviço. Assim, um projeto de serviço não pode ser um projeto host para futuros projetos de serviço.

  • É possível criar e usar vários projetos host, mas cada projeto de serviço só pode ser anexado a um único projeto host. Para ver uma ilustração, consulte o exemplo de vários projetos host.

  • É preciso criar redes, sub-redes, intervalos de endereços secundários, regras de firewall e outros recursos de rede no projeto host. Assim, o projeto host poderá compartilhar as sub-redes selecionadas, incluindo intervalos secundários, com os projetos de serviço. Os serviços em execução em um projeto de serviço podem usar a VPC compartilhada para se comunicar com recursos em execução nos outros projetos de serviço.

Para esclarecer melhor, um projeto que não participa da VPC compartilhada é chamado de projeto autônomo. Isso evidencia que não se trata de um projeto host nem de um projeto de serviço.

Uma rede VPC independente é uma rede VPC não compartilhada que existe em um projeto independente ou em um projeto de serviço.

Redes

Uma rede VPC compartilhada é uma rede VPC definida em um projeto host e disponibilizada como uma rede compartilhada centralmente para recursos qualificados em projetos de serviço. As redes VPC compartilhadas podem ser do modo automático ou personalizado, mas redes legadas não são compatíveis.

Quando um projeto host está ativado, você tem duas opções para compartilhar redes:

  • É possível compartilhar todas as sub-redes do projeto host. Se você selecionar essa opção, todas as novas sub-redes criadas no projeto host, incluindo sub-redes em novas redes, também serão compartilhadas.
  • Você pode especificar individualmente quais sub-redes serão compartilhadas. Se você compartilhar sub-redes individualmente, somente essas sub-redes serão compartilhadas, a menos que você altere a lista manualmente.

Projetos host e de serviço são conectados por anexos no nível do projeto. As sub-redes das redes VPC compartilhadas no projeto host podem ser acessadas pelos Administradores do projeto de serviço, conforme descrito na próxima seção: administradores e IAM.

Restrições da política da organização

As políticas da organização e as permissões do IAM trabalham juntas para fornecer diferentes níveis de controle de acesso. As políticas da organização permitem definir controles no nível da organização, pasta ou projeto.

Se você é um administrador da política da organização, pode especificar as seguintes restrições de VPC compartilhada na política da organização:

  • É possível limitar o conjunto de projetos host aos quais um ou mais projetos não host em uma pasta ou organização podem ser anexados. A restrição se aplica quando um administrador de VPC compartilhada anexa um projeto de serviço com um projeto de host. A restrição não afeta anexos existentes. Os anexos existentes permanecem intactos, mesmo se uma política negar novos anexos. Para mais informações, consulte a restrição constraints/compute.restrictSharedVpcHostProjects.

  • É possível especificar as sub-redes da VPC compartilhada que um projeto de serviço pode acessar no nível do projeto, da pasta ou da organização. A restrição se aplica ao criar novos recursos nas sub-redes especificadas e não afeta recursos existentes. Os recursos existentes continuam funcionando normalmente em suas sub-redes, mesmo que uma política impeça a adição de novos recursos. Para mais informações, consulte a restrição constraints/compute.restrictSharedVpcSubnetworks.

Administradores e IAM

A VPC compartilhada faz uso dos papéis de gerenciamento de identidade e acesso (IAM) para administração delegada. Os seguintes papéis podem ser concedidos a principais do IAM, como usuários, grupos do Google, domínios do Google ou contas de serviço do Google Cloud. Se precisar entrar em contato com qualquer um desses administradores, consulte-os na política de IAM da organização ou do projeto. Se não tiver as permissões necessárias, você precisará entrar em contato com um administrador de rede ou de projeto na sua organização.

Papéis administrativos necessários

Administrador (papel do IAM) Finalidade
Administrador da organização (resourcemanager.organizationAdmin)
  • Principal do IAM na organização		 Os administradores da organização têm o papel resourcemanager.organizationAdmin para a organização. Eles nomeiam administradores de VPC compartilhada ao conceder papéis apropriados de criação e exclusão de projetos a eles, e o papel de administrador de VPC compartilhada para a organização. Esses administradores podem definir políticas no nível da organização, mas ações específicas de pastas e projetos exigem outros papéis de pastas e projetos.
Administrador de VPC compartilhada
(compute.xpnAdmin e
resourcemanager.projectIamAdmin)
  • Principal do IAM na organização ou
  • Principal do IAM em uma pasta		 Os administradores de VPC compartilhada têm os papéis Administrador de VPC compartilhada do Compute (compute.xpnAdmin) e Administrador IAM do projeto (resourcemanager.projectIamAdmin) na organização ou em uma ou mais pastas. Eles executam várias tarefas necessárias para configurar a VPC compartilhada, como ativar projetos host, anexar projetos de serviço a projetos host e delegar aos administradores do projeto de serviço o acesso a algumas ou a todas as sub-redes em redes VPC compartilhadas. Um administrador de VPC compartilhada para um determinado projeto host normalmente também é o proprietário do projeto.
Um usuário atribuído ao papel de administrador de VPC compartilhada para a organização tem esse papel para todas as pastas da organização. Um usuário atribuído ao papel de uma pasta tem essa função para a pasta especificada e quaisquer pastas aninhadas abaixo dela. Um administrador de VPC compartilhada pode vincular projetos em duas pastas diferentes somente se o administrador tiver o papel para ambas as pastas.
Administrador do projeto de serviço
(compute.networkUser .
• Principal do IAM na organização ou
• Principal do IAM em um projeto host ou
• Principal do IAM em algumas sub-redes no projeto host		 Um administrador de VPC compartilhada define um administrador de projeto de serviço concedendo a um principal do IAM o papel de Usuário de rede (compute.networkUser) para o projeto host inteiro ou para selecionar sub-redes de redes de VPC compartilhada desse projeto. Os administradores de projetos de serviço também mantêm a propriedade e o controle sobre os recursos definidos nos projetos de serviço. Portanto, eles precisam ter o papel Administrador de instâncias (compute.instanceAdmin) para os projetos de serviço correspondentes. Eles podem ter outros papéis do IAM para os projetos de serviço, como proprietário do projeto.

Administradores de projetos de serviço

Ao definir cada administrador de projeto de serviço, um administrador de VPC compartilhada pode conceder permissão para usar todo o projeto host ou apenas algumas sub-redes:

  • Permissões para envolvidos no projeto: um administrador de projeto de serviço pode receber permissão para usar todas as sub-redes no projeto host se o administrador de VPC compartilhada conceder a ele o papel compute.networkUser para todo o projeto host. O resultado é que o administrador do projeto de serviço tem permissão para usar todas as sub-redes em todas as redes VPC do projeto host, incluindo sub-redes e redes VPC adicionadas ao projeto host no futuro.

  • Permissões para envolvidos na sub-rede: como alternativa, um administrador de projeto de serviço pode receber um conjunto mais restrito de permissões para usar apenas algumas sub-redes se o administrador de VPC compartilhada conceder a ele o papel de compute.networkUser para as sub-redes selecionadas. Um administrador de projeto de serviço que tem somente permissões no nível da sub-rede está restrito a usar somente essas sub-redes. Depois que novas redes VPC compartilhadas ou novas sub-redes são adicionadas ao projeto host, um administrador de VPC compartilhada examina as vinculações de permissão do papel compute.networkUser para garantir que as permissões de nível de sub-rede correspondam à configuração pretendida.

Administradores de rede e segurança

Administradores da VPC compartilhada têm controle total sobre os recursos no projeto de host, incluindo a administração da rede VPC compartilhada. Eles podem, opcionalmente, delegar determinadas tarefas administrativas de rede a outros principais do IAM:

Administrador Finalidade
Administrador de rede
• Principal do IAM no projeto host ou
• Principal do IAM na organização		 O administrador de VPC compartilhada define um administrador de rede concedendo a um principal do IAM o papel Administrador de rede (compute.networkAdmin) para o projeto host. Os administradores de rede têm controle total sobre todos os recursos de rede, exceto regras de firewall e certificados SSL.
Administrador de segurança
• Principal do IAM no projeto host ou
• Principal do IAM na organização		 Um administrador de VPC compartilhada pode definir um administrador de segurança ao conceder a um principal do IAM o papel Administrador de segurança (compute.securityAdmin) para o projeto host. Os administradores de segurança gerenciam regras de firewall e certificados SSL.

Especificações

Cotas e limites

Os projetos host de VPC compartilhada estão sujeitos a cotas VPC padrão por projeto. Redes VPC compartilhadas estão sujeitas aos limites por rede e aos limites por instância para redes VPC. Além disso, as relações entre os projetos host e de serviço são regidas pelos limites específicos da VPC compartilhada.

Faturamento

O faturamento de recursos que participam de uma rede VPC compartilhada é atribuído ao projeto de serviço em que o recurso está localizado, mesmo que o recurso use a rede VPC compartilhada no projeto host.

  • As taxas e regras usadas para calcular os valores de faturamento para recursos em projetos de serviço que usam uma rede VPC compartilhada são as mesmas que se os recursos estivessem localizados no próprio projeto host.
  • O faturamento para o tráfego de saída gerado por um recurso é atribuído ao projeto em que ele está definido:
    • O tráfego de saída de uma instância é atribuído ao projeto que contém a instância. Por exemplo, se uma instância for criada em um projeto de serviço, mas usar uma rede VPC compartilhada, qualquer faturamento para o tráfego de saída gerado será atribuído ao projeto de serviço. Dessa maneira, você pode usar a VPC compartilhada para organizar recursos em centros de custo para sua organização.
    • Os custos associados a um balanceador de carga são cobrados no projeto que contém os componentes desse balanceador. Para mais detalhes sobre balanceamento de carga e VPC compartilhada, consulte a seção sobre balanceamento de carga.
    • O tráfego de saída para VPNs é atribuído ao projeto que contém o recurso do gateway de VPN. Por exemplo, se um gateway de VPN for criado na rede VPC compartilhada, ele estará contido no projeto host. O tráfego de saída por meio do gateway de VPN, seja qual for o projeto de serviço que inicia a transferência de dados de saída, é atribuído ao projeto host.
    • Os custos do tráfego de um recurso em um projeto de serviço de VPC compartilhada que é transferido por um anexo da VLAN são atribuídos ao projeto que contém o anexo. Para saber mais, consulte os preços do Cloud Interconnect.

Recursos

Recursos qualificados

É possível usar a maioria dos produtos e recursos do Google Cloud em projetos de serviço de VPC compartilhada.

As seguintes limitações se aplicam a recursos qualificados para participação em um cenário de VPC compartilhada:

  • O uso de uma rede VPC compartilhada não é obrigatório. Por exemplo, os administradores da instância podem criar instâncias no projeto de serviço que usam uma rede VPC nesse projeto. Redes definidas em projetos de serviço não são compartilhadas.

  • Alguns recursos precisam ser recriados para usar uma rede VPC compartilhada. Quando um administrador da VPC compartilhada anexa um projeto existente a um projeto de host, esse projeto se torna um projeto de serviço, mas os recursos existentes dele não usam automaticamente os recursos de rede compartilhados. Para usar uma rede VPC compartilhada, um administrador do projeto de serviço precisa criar um recurso qualificado e configurá-lo para usar uma sub-rede de uma rede VPC compartilhada. Por exemplo, uma instância existente em um projeto de serviço não pode ser reconfigurada para usar uma rede VPC compartilhada, mas uma nova instância pode ser criada para usar sub-redes disponíveis em uma rede VPC compartilhada. Esta limitação aplica-se a zonas particulares.

Endereços IP

Ao criar uma instância em um projeto de serviço, é possível configurá-la como uma instância de pilha única (somente IPv4) ou de pilha dupla (IPv4 e IPv6), dependendo da configuração de sub-rede do projeto host. Para mais informações, consulte Criar uma instância.

As instâncias em projetos de serviço anexadas a um projeto host que usam a mesma rede VPC compartilhada podem se comunicar internamente entre elas usando os endereços IPv4 internos ou endereços IPv6 internos ou externos, sujeitos às regras de firewall aplicáveis.

Os administradores do projeto de serviço podem atribuir qualquer um dos seguintes tipos de endereço IP aos recursos em um projeto de serviço:

  • Endereços IPv4 e IPv6 temporários: um endereço IP temporário pode ser atribuído automaticamente a uma instância em um projeto de serviço. Por exemplo, quando os administradores de projeto de serviço criam instâncias, eles selecionam a rede VPC compartilhada e uma sub-rede compartilhada disponível. O endereço IPv4 interno principal da instância vem do intervalo de endereços IP disponíveis no intervalo de endereços IPv4 principal da sub-rede compartilhada selecionada. Se eles configurarem a instância como uma instância de pilha dupla, o endereço IPv6 da instância virá do intervalo de endereços IP disponíveis no intervalo de sub-redes IPv6 da sub-rede compartilhada selecionada.

    Endereços IPv4 temporários também podem ser atribuídos a balanceadores de carga internos. Para mais informações, consulte Criar um balanceador de carga de rede de passagem interna ou criar um balanceador de carga de aplicativo interno.

  • Endereços IPv4 e IPv6 internos estáticos: podem ser reservados em um projeto de serviço. O objeto de endereço IPv4 ou IPv6 interno precisa ser criado no mesmo projeto de serviço do recurso que o usa, embora o valor do endereço IP venha dos endereços IP disponíveis em uma sub-rede compartilhada selecionada em uma rede VPC compartilhada. Para mais informações, consulte Reservar endereços IPv4 e IPv6 internos estáticos na página "Provisionar VPC compartilhada".

  • Endereços IPv4 externos estáticos: objetos de endereço IPv4 externos definidos no projeto host podem ser usados por recursos em qualquer projeto host ou em qualquer projeto de serviço anexado. Os projetos de serviço também podem usar os próprios objetos de endereços IPv4 externos. Por exemplo, uma instância em um projeto de serviço pode usar um endereço IPv4 externo regional definido no seu projeto de serviço ou no projeto host.

  • Endereços IPv6 externos estáticos: um administrador de projeto de serviço também pode optar por reservar um endereço IPv6 externo estático. O objeto de endereço IPv6 externo precisa ser criado no mesmo projeto de serviço do recurso que o usa, embora o valor do endereço IP venha dos endereços IPv6 disponíveis em uma sub-rede compartilhada selecionada em uma rede VPC compartilhada. Para mais informações, consulte Reservar um endereço IPv6 externo estático na página Provisionar VPC compartilhada.

DNS interno

As VMs no mesmo projeto de serviço podem se comunicar usando os nomes DNS internos que o Google Cloud cria automaticamente. Esses nomes DNS usam o ID do projeto de serviço em que as VMs são criadas, mesmo que os nomes apontem para endereços IP internos no projeto de host. Para ver uma explicação completa, consulte Nomes DNS internos e VPC compartilhada na documentação do DNS interno.

Zonas particulares do Cloud DNS

É possível usar zonas de DNS particular do Cloud DNS em uma rede VPC compartilhada. É possível criar sua zona particular no projeto host e autorizar o acesso à zona da rede VPC compartilhada ou configurar a zona em um projeto de serviço usando a vinculação entre projetos.

Balanceamento de carga

Use a VPC compartilhada com o Cloud Load Balancing. Na maioria dos casos, você cria as instâncias de back-end em um projeto de serviço. Nesse caso, todos os componentes do balanceador de carga são criados nesse projeto. Embora seja possível criar instâncias de back-end no projeto host, essa configuração não é adequada para implantações típicas de VPC compartilhada, já que não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Use os links na tabela a seguir para saber mais sobre as arquiteturas de VPC compartilhada compatíveis para cada tipo de balanceador de carga.

Tipo de balanceador de carga Links
Balanceador de carga de aplicativo externo Arquitetura da VPC compartilhada
Balanceador de carga de aplicativo interno Arquitetura da VPC compartilhada
Balanceador de carga de rede de proxy externo Arquitetura da VPC compartilhada
Balanceador de carga de rede de proxy interno Arquitetura da VPC compartilhada
Balanceador de carga de rede de passagem interno Arquitetura da VPC compartilhada
Balanceador de carga de rede de passagem externo Arquitetura da VPC compartilhada

Exemplos e casos de uso

Conceitos básicos

A Figura 1 mostra um cenário simples de VPC compartilhada:

Figura 1. Um projeto host com uma rede VPC compartilhada fornece conectividade interna para dois projetos de serviço, enquanto um projeto autônomo não usa a VPC compartilhada (clique para ampliar).

  • Um administrador de VPC compartilhada da organização criou um projeto host e anexou dois projetos de serviço a ele:

    • Administradores de projetos de serviço em Service project A podem receber acesso a todas ou algumas das sub-redes na rede VPC compartilhada. Um administrador de projeto de serviço com pelo menos permissões no nível da sub-rede para a 10.0.1.0/24 subnet criou a Instance A em uma zona da região us-west1. Essa instância recebe um endereço IP interno, 10.0.1.3, do bloco CIDR 10.0.1.0/24.

    • Administradores de projetos de serviço em Service project B podem receber acesso a todas ou algumas das sub-redes na rede VPC compartilhada. Um administrador de projeto de serviço com pelo menos permissões no nível da sub-rede para a 10.15.2.0/24 subnet criou a Instance B em uma zona da região us-east1. Essa instância recebe um endereço IP interno, 10.15.2.4, do bloco CIDR 10.15.2.0/24.

  • O projeto autônomo não participa da VPC compartilhada. Ele não é nem um projeto host nem um projeto de serviço. Instâncias autônomas são criadas por principais do IAM que têm pelo menos o papel compute.InstanceAdmin para o projeto.

Vários projetos de host

A Figura 2 mostra como a VPC compartilhada pode ser usada para criar ambientes de teste e produção separados. Para esse caso, uma organização decidiu usar dois projetos de host separados: um ambiente de teste e um ambiente de produção.

Figura 2. Um projeto host de teste e um de ambiente de produção usam a VPC compartilhada para criar ambientes distintos de produção e teste (clique para ampliar).

  • Um administrador de VPC compartilhada da organização criou dois projetos host e anexou dois projetos de serviço a eles da seguinte maneira:

    • Os projetos de serviço Apps testing e Mobile testing foram anexados ao projeto host Test environment. Os administradores de projetos de serviço em cada projeto podem ser configurados para acessar todas ou algumas das sub-redes na Testing network.

    • Os projetos de serviço Apps production e Mobile production foram anexados ao projeto host Production environment. Os administradores de projetos de serviço em cada projeto podem ser configurados para acessar todas ou algumas das sub-redes na Production network.

  • Os dois projetos host têm uma rede VPC compartilhada com sub-redes configuradas para usar os mesmos intervalos de CIDR. Tanto na Testing network quanto na Production network, as duas sub-redes são:

    • 10.0.1.0/24 subnet na região us-west1

    • 10.15.2.0/24 subnet na região us-east1

  • Considere Instance AT no projeto de serviço Apps testing e Instance AP no projeto de serviço Apps production:

    • Os administradores de projetos de serviço podem criar instâncias como essas, desde que tenham pelo menos permissões no nível da sub-rede para a 10.0.1.0/24 subnet.

    • Observe que ambas as instâncias usam o endereço IP 10.0.1.3. Isso é aceitável porque cada instância existe em um projeto de serviço anexado a um projeto host exclusivo que contém uma rede VPC compartilhada própria. As redes de teste e produção foram propositadamente configuradas da mesma maneira.

    • Instâncias que usam a 10.0.1.0/24 subnet precisam estar localizadas em uma zona na mesma região da sub-rede, mesmo que a sub-rede e as instâncias estejam definidas em projetos separados. Como a 10.0.1.0/24 subnet está localizada na região us-west1, os administradores de projeto de serviço que criam instâncias usando essa sub-rede precisam escolher uma zona na mesma região, como us-west1-a.

Cenário de nuvem híbrida

A Figura 3 mostra como a VPC compartilhada pode ser usada em um ambiente híbrido.

Figura 3. Uma rede VPC compartilhada é conectada a uma rede local e a três projetos de serviço (clique para ampliar).

Para este exemplo, uma organização criou um projeto de host único com uma única rede VPC compartilhada. A rede VPC compartilhada é conectada pelo Cloud VPN a uma rede local. Alguns serviços e aplicativos são hospedados no Google Cloud enquanto outros são mantidos no local:

  • Um administrador de VPC compartilhada ativou o projeto host e conectou três projetos de serviço a ele: Service project A, Service project B e Service project C.

    • Equipes separadas podem gerenciar cada um dos projetos de serviço. As permissões do IAM foram configuradas de maneira que um administrador do projeto de serviço de um projeto não tenha permissões para os outros projetos de serviço.

    • O administrador de VPC compartilhada concedeu permissões no nível da sub-rede ou para envolvidos no projeto aos administradores de projeto de serviço necessários para que eles possam criar instâncias que usem a rede VPC compartilhada:

      • Um administrador de projeto de serviço de Service project A com permissões no nível da sub-rede para 10.0.1.0/24 subnet pode criar a Instance A nela. O administrador de projeto de serviço deve escolher uma zona na região us-west1 da instância, porque essa é a região que contém a 10.0.1.0/24 subnet. Instance A recebe o endereço IP, 10.0.1.3, do intervalo de endereços IP livres na 10.0.1.0/24 subnet.

      • Um administrador de projeto de serviço de Service project B com permissões no nível da sub-rede para 10.15.2.0/24 subnet pode criar a Instance B nela. O administrador de projeto de serviço deve escolher uma zona na região us-east1 da instância, porque essa é a região que contém a 10.15.2.0/24 subnet. Instance B recebe o endereço IP, 10.15.2.4, do intervalo de endereços IP livres na 10.15.2.0/24 subnet.

      • Um administrador de projeto de serviço para Service project C que tem permissões de nível de projeto para todo o projeto host pode criar instâncias em qualquer uma das sub-redes em qualquer rede VPC no projeto host. Por exemplo, o administrador do projeto de serviço pode criar Instance C na 10.7.1.0/24 subnet, escolhendo uma zona na região us-east1 para corresponder à região da sub-rede. Instance C recebe o endereço IP, 10.7.1.50, do intervalo de endereços IP livres na 10.7.1.0/24 Subnet.

    • Cada projeto de serviço é cobrado separadamente.

    • Os administradores do projeto de serviço em cada projeto são responsáveis por criar e gerenciar recursos.

  • Um administrador de VPC compartilhada delegou tarefas de administração de rede a outros principais do IAM que são administradores de rede e segurança da rede VPC compartilhada.

    • Um administrador de rede criou um gateway do Cloud VPN e configurou um túnel VPN pela Internet para um gateway local. O Cloud VPN recebe e troca rotas com a contraparte local dele porque um Cloud Router correspondente na mesma região us-east1 foi configurado.

    • Se o modo de roteamento dinâmico da VPC for global, o Cloud Router aplicará as rotas aprendidas à rede local em todas as sub-redes da rede VPC e compartilhará as rotas com todas as sub-redes VPC com a contraparte local.

    • Os administradores de segurança criam e gerenciam regras de firewall na rede VPC compartilhada para controlar o tráfego entre instâncias no Google Cloud e na rede local.

    • Sujeitas às regras de firewall aplicáveis, as instâncias nos projetos de serviço podem ser configuradas para se comunicarem com serviços internos, como servidores de banco de dados ou de diretório locais.

Serviço da Web de dois níveis

A Figura 4 demonstra como a VPC compartilhada pode ser empregada para delegar responsabilidades administrativas e manter o princípio de privilégio mínimo. Para este caso, uma organização tem um serviço da Web que é separado em duas camadas e equipes diferentes gerenciam cada camada. O nível 1 representa o componente externo, atrás de um balanceador de carga HTTP(S). A camada 2 representa um serviço interno em que a camada 1 se baseia, e é balanceada com um Balanceador de carga TCP/UDP interno.

Figura 4. Nesse serviço da Web de dois níveis, um componente externo e um serviço interno estão conectados a uma rede VPC compartilhada comum e gerenciados por equipes diferentes (clique para ampliar).

A VPC compartilhada permite mapear cada nível do serviço da Web para diferentes projetos, de modo que eles possam ser gerenciados por equipes diferentes ao compartilhar uma rede VPC comum:

  • Recursos, como instâncias e componentes do balanceador de carga, para cada nível são colocados em projetos de serviços individuais gerenciados por equipes diferentes.

  • Cada projeto de serviço de diferentes níveis foi anexado ao projeto host por um administrador de VPC compartilhada. O administrador de VPC compartilhada também ativou o projeto host.

    • Equipes separadas podem gerenciar cada nível do serviço da Web em virtude de ser um administrador do projeto de serviço no projeto de serviço apropriado.

    • Cada projeto de serviço é cobrado separadamente.

    • Os administradores do projeto de serviço em cada projeto são responsáveis por criar e gerenciar recursos.

  • O controle de acesso à rede é delineado da seguinte maneira:

    • Os principais do IAM que trabalham apenas no Nível 1 são administradores do projeto de serviço para o Tier 1 service project e recebem permissões no nível da sub-rede apenas para a 10.0.1.0/24 subnet. Neste exemplo, um administrador do projeto de serviço criou três Tier 1 instances nessa sub-rede.

    • Os principais do IAM que trabalham apenas no Nível 2 são administradores do projeto de serviço para o Tier 2 service project e recebem permissões no nível da sub-rede apenas para a 10.0.2.0/24 subnet. Neste exemplo, outro administrador de projeto de serviço criou três Tier 2 instances nessa sub-rede junto com um balanceador de carga interno com uma regra de encaminhamento que usa um endereço IP do intervalo disponível nessa sub-rede.

    • Os principais do IAM que supervisionam todo o serviço da Web são administradores do projeto de serviço em ambos os projetos de serviço e têm permissões para envolvidos no projeto para o projeto host, de modo que podem usar qualquer sub-rede definida nele.

    • Opcionalmente, um administrador de VPC compartilhada pode delegar tarefas de administração de rede a administradores de rede e segurança.

A seguir