VPC partilhada

Esta página oferece uma vista geral da VPC partilhada no Google Cloud. A VPC partilhada permite que uma organização ligue recursos de vários projetos a uma rede de nuvem virtual privada (VPC) para que possam comunicar entre si de forma segura e eficiente através de endereços IP internos dessa rede.

Quando usa a VPC partilhada, designa um projeto como um projeto anfitrião e anexa-lhe um ou mais projetos de serviço. As redes VPC no projeto anfitrião são denominadas redes VPC partilhadas. Os recursos elegíveis dos projetos de serviço podem usar sub-redes na rede de VPC partilhada.

A VPC partilhada permite que os administradores da organização deleguem responsabilidades administrativas, como a criação e a gestão de instâncias, nos administradores do projeto de serviço, mantendo o controlo centralizado dos recursos de rede, como sub-redes, rotas e firewalls. Este modelo permite que as organizações façam o seguinte:

  • Implemente uma prática recomendada de segurança de privilégio mínimo para a administração, a auditoria e o controlo de acesso à rede. Os administradores da VPC partilhada podem delegar tarefas de administração de rede a administradores de rede e de segurança na rede da VPC partilhada sem permitir que os administradores do projeto de serviço façam alterações que afetem a rede. Os administradores do projeto de serviço só têm a capacidade de criar e gerir instâncias que usam a rede de VPC partilhada. Consulte a secção administradores e IAM para mais detalhes.
  • Aplicar e impor políticas de controlo de acesso consistentes ao nível da rede para vários projetos de serviço na organização, ao mesmo tempo que delega responsabilidades administrativas. Por exemplo, os administradores do projeto de serviço podem ser administradores de instâncias de computação no respetivo projeto, criando e eliminando instâncias que usam sub-redes aprovadas no projeto anfitrião de VPC partilhada.
  • Use projetos de serviços para separar a orçamentação ou os centros de custos internos. Consulte a secção de faturação para ver mais detalhes.

Conceitos

Organizações, pastas e projetos

A VPC partilhada liga projetos na mesma organização. Os projetos associados podem estar na mesma pasta ou em pastas diferentes, mas, se estiverem em pastas diferentes, o administrador tem de ter direitos de administrador da VPC partilhada em ambas as pastas. Consulte a Google Cloud hierarquia de recursos para obter mais informações sobre organizações, pastas e projetos.

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

Um projeto que participa na VPC partilhada é um projeto anfitrião ou um projeto de serviço:

  • Um projeto anfitrião contém uma ou mais redes de VPC partilhada. Um administrador da VPC partilhada tem de ativar primeiro um projeto como um projeto anfitrião. Depois disso, um administrador da VPC partilhada pode anexar um ou mais projetos de serviço.

  • Um projeto de serviço é qualquer projeto que tenha sido anexado a um projeto anfitrião por um administrador da VPC partilhada. Esta associação permite-lhe participar na VPC partilhada. É uma prática comum ter vários projetos de serviços operados e administrados por diferentes departamentos ou equipas na sua organização.

  • Um projeto não pode ser um projeto anfitrião e um projeto de serviço em simultâneo. Assim, um projeto de serviço não pode ser um projeto anfitrião para outros projetos de serviço.

  • Pode criar e usar vários projetos anfitriões. No entanto, cada projeto de serviço só pode ser anexado a um único projeto anfitrião. Para uma ilustração, consulte o exemplo de vários projetos anfitriões.

  • Pode criar redes, sub-redes, intervalos de endereços secundários, regras de firewall e outros recursos de rede no projeto anfitrião. O projeto anfitrião pode, em seguida, partilhar sub-redes selecionadas, incluindo intervalos secundários, com os projetos de serviço. Os serviços executados num projeto de serviço podem usar a VPC partilhada para comunicar com os recursos executados nos outros projetos de serviço.

Para esclarecer, um projeto que não participa na VPC partilhada é denominado projeto autónomo. Isto enfatiza que não é um projeto anfitrião nem um projeto de serviço.

Uma rede da VPC autónoma é uma rede da VPC não partilhada que existe num projeto autónomo ou num projeto de serviço.

Redes

Uma rede VPC partilhada é uma rede VPC definida num projeto anfitrião e disponibilizada como uma rede partilhada centralmente para recursos elegíveis em projetos de serviço. As redes de VPC partilhada podem estar no modo automático ou personalizado, mas as redes antigas não são suportadas.

Quando um projeto anfitrião está ativado, tem duas opções para partilhar redes:

  • Pode partilhar todas as sub-redes do projeto anfitrião. Se selecionar esta opção, todas as novas sub-redes criadas no projeto anfitrião, incluindo sub-redes em novas redes, também são partilhadas.
  • Pode especificar sub-redes individuais para partilhar. Se partilhar sub-redes individualmente, apenas essas sub-redes são partilhadas, a menos que altere manualmente a lista.

Os projetos anfitrião e de serviço estão ligados por anexos ao nível do projeto. As sub-redes das redes de VPC partilhada no projeto anfitrião são acessíveis pelos administradores do projeto de serviço, conforme descrito na secção seguinte, administradores e IAM.

Restrições de políticas da organização

As políticas de organização e as autorizações da IAM funcionam em conjunto para oferecer diferentes níveis de controlo de acesso. As políticas de organização permitem-lhe definir controlos ao nível da organização, da pasta ou do projeto.

Se for um administrador da política da organização, pode especificar as seguintes restrições da VPC partilhada numa política da organização:

  • Pode limitar o conjunto de projetos anfitriões aos quais um projeto não anfitrião ou projetos não anfitriões numa pasta ou organização podem ser anexados. A restrição aplica-se quando um administrador da VPC partilhada anexa um projeto de serviço a um projeto anfitrião. A restrição não afeta os anexos existentes. Os anexos existentes permanecem intactos, mesmo que uma política negue novos anexos. Para mais informações, consulte a restrição constraints/compute.restrictSharedVpcHostProjects.

  • Pode especificar as sub-redes da VPC partilhada às quais um projeto de serviço pode aceder ao nível do projeto, da pasta ou da organização. A restrição aplica-se quando cria novos recursos nas sub-redes especificadas e não afeta os recursos existentes. Os recursos existentes continuam a funcionar normalmente nas respetivas 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 partilhada usa funções de gestão de identidade e de acesso (IAM) para a administração delegada. As seguintes funções podem ser concedidas a principais do IAM, como utilizadores, grupos Google, domínios Google ou contas de serviço Google Cloud . Se precisar de contactar algum destes administradores, pode procurá-los na política de IAM da sua organização ou projeto. Se não tiver as autorizações necessárias, tem de contactar um administrador da rede ou do projeto na sua organização.

Funções administrativas necessárias

Administrador (função de IAM) Finalidade
Administrador da organização (resourcemanager.organizationAdmin)
  • Principal do IAM na organização		 Os administradores da organização têm a função de resourcemanager.organizationAdmin para a sua organização. Estes nominam administradores da VPC partilhada concedendo-lhes funções de criação e eliminação de projetos adequadas e a função de administrador da VPC partilhada para a organização. Estes administradores podem definir políticas ao nível da organização, mas as ações específicas de pastas e projetos requerem funções adicionais de pastas e projetos.
Administrador da VPC partilhada
(compute.xpnAdmin e
resourcemanager.projectIamAdmin)
  • Principal da IAM na organização ou
  • Principal da IAM numa pasta		 Os administradores da VPC partilhada têm as funções de Administrador da VPC partilhada do Compute (compute.xpnAdmin) e Administrador da IAM do projeto (resourcemanager.projectIamAdmin) para a organização ou uma ou mais pastas. Realizam várias tarefas necessárias para configurar a VPC partilhada, como ativar projetos anfitriões, anexar projetos de serviços a projetos anfitriões e delegar o acesso a algumas ou a todas as sub-redes em redes VPC partilhadas a administradores de projetos de serviços. Normalmente, um administrador de VPC partilhada para um determinado projeto anfitrião também é o proprietário do projeto.
Um utilizador ao qual foi atribuída a função de administrador de VPC partilhada de computação para a organização tem essa função para todas as pastas na organização. Um utilizador com a função para uma pasta tem essa função para a pasta em questão e para todas as pastas aninhadas abaixo desta. Um administrador da VPC partilhada só pode associar projetos em duas pastas diferentes se tiver a função para ambas as pastas.
Administrador do projeto de serviço
(compute.networkUser)
  • Principal do IAM na organização ou
  • Principal do IAM num projeto anfitrião ou
  • Principal do IAM em algumas sub-redes no projeto anfitrião		 Um administrador da VPC partilhada define um administrador do projeto de serviço concedendo a um principal do IAM a função Utilizador da rede (compute.networkUser) a todo o projeto anfitrião ou a sub-redes selecionadas das respetivas redes VPC partilhadas. Os administradores do projeto de serviço também mantêm a propriedade e o controlo sobre os recursos definidos nos projetos de serviço, pelo que devem ter a função Instance Admin (compute.instanceAdmin) nos projetos de serviço correspondentes. Podem ter funções de IAM adicionais nos projetos de serviço, como proprietário do projeto.

Administradores de projetos de serviço

Ao definir cada administrador do projeto de serviço, um administrador da VPC partilhada pode conceder autorização para usar todo o projeto anfitrião ou apenas algumas sub-redes:

  • Autorizações ao nível do projeto: pode definir um administrador do projeto de serviço para ter autorização para usar todas as sub-redes no projeto anfitrião se o administrador da VPC partilhada conceder a função de compute.networkUser para todo o projeto anfitrião ao administrador do projeto de serviço. O resultado é que o administrador do projeto de serviço tem autorização para usar todas as sub-redes em todas as redes VPC do projeto anfitrião, incluindo sub-redes e redes VPC adicionadas ao projeto anfitrião no futuro.

  • Autorizações ao nível da sub-rede: em alternativa, um administrador do projeto de serviço pode receber um conjunto mais restritivo de autorizações para usar apenas algumas sub-redes se o administrador da VPC partilhada atribuir a função de compute.networkUser para essas sub-redes selecionadas ao administrador do projeto de serviço. Um administrador do projeto de serviço que só tenha autorizações ao nível da sub-rede está restrito à utilização apenas dessas sub-redes. Depois de adicionar novas redes de VPC partilhada ou novas sub-redes ao projeto anfitrião, um administrador da VPC partilhada deve rever as associações de autorizações para a função compute.networkUser para garantir que as autorizações ao nível da sub-rede para todos os administradores do projeto de serviço correspondem à configuração pretendida.

Administradores de rede e segurança

Os administradores da VPC partilhada têm controlo total sobre os recursos no projeto anfitrião, incluindo a administração da rede VPC partilhada. Opcionalmente, podem delegar determinadas tarefas administrativas da rede a outros principais do IAM:

Administrador Finalidade
Administrador de rede
  • Principal do IAM no projeto anfitrião ou
  • Principal do IAM na organização		 O administrador da VPC partilhada define um administrador de rede concedendo a um principal do IAM a função Administrador de rede (compute.networkAdmin) ao projeto anfitrião. Os administradores de rede têm controlo total sobre todos os recursos de rede, exceto as regras de firewall e os certificados SSL.
Administrador de segurança
  • Principal do IAM no projeto anfitrião ou
  • Principal do IAM na organização		 Um administrador da VPC partilhada pode definir um administrador de segurança concedendo a um principal da IAM a função de administrador de segurança (compute.securityAdmin) ao projeto anfitrião. Os administradores de segurança gerem as regras de firewall e os certificados SSL.

Especificações

Quotas e limites

Os projetos anfitriões da VPC partilhada estão sujeitos às quotas de VPC por projeto padrão. As redes VPC partilhadas 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 anfitrião e de serviço são regidas por limites específicos da VPC partilhada.

Faturação

A faturação dos recursos que participam numa rede VPC partilhada é atribuída ao projeto de serviço onde o recurso está localizado, mesmo que o recurso use a rede VPC partilhada no projeto anfitrião.

  • As tarifas e as regras usadas para calcular os valores de faturação para recursos em projetos de serviço que usam uma rede VPC partilhada são as mesmas que se os recursos estivessem localizados no próprio projeto anfitrião.
  • A faturação do tráfego de saída gerado por um recurso é atribuída ao projeto onde o recurso 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 num projeto de serviço, mas usar uma rede de VPC partilhada, qualquer faturação do tráfego de saída que gerar é atribuída ao respetivo projeto de serviço. Desta forma, pode usar a VPC partilhada para organizar os recursos em centros de custos para a sua organização.
    • Os custos associados a um equilibrador de carga são cobrados ao projeto que contém os componentes do equilibrador de carga. Para mais detalhes acerca do equilíbrio de carga e da VPC partilhada, consulte a secção sobre o equilíbrio de carga.
    • O tráfego de saída para VPNs é atribuído ao projeto que contém o recurso de gateway de VPN. Por exemplo, se for criado um gateway de VPN na rede de VPC partilhada, este é incluído no projeto anfitrião. O tráfego de saída através do gateway de VPN, independentemente do projeto de serviço que inicia a transferência de dados de saída, é atribuído ao projeto anfitrião.
    • Os custos do tráfego de um recurso num projeto de serviço de VPC partilhada que é transferido através de uma associação VLAN são atribuídos ao projeto que detém a associação VLAN. Para mais informações, consulte os preços do Cloud Interconnect.

Recursos

Recursos elegíveis

Pode usar a maioria dos Google Cloud produtos e funcionalidades em projetos de serviço de VPC partilhada.

As seguintes limitações aplicam-se aos recursos elegíveis para participação num cenário de VPC partilhada:

  • A utilização de uma rede VPC partilhada não é obrigatória. Por exemplo, os administradores de instâncias podem criar instâncias no projeto de serviço que usam uma rede VPC nesse projeto. As redes definidas em projetos de serviço não são partilhadas.

  • Alguns recursos têm de ser recriados para usar uma rede VPC partilhada. Quando um administrador da VPC partilhada associa um projeto existente a um projeto anfitrião, esse projeto torna-se um projeto de serviço, mas os respetivos recursos existentes não usam automaticamente recursos de rede partilhados. Para usar uma rede VPC partilhada, um administrador do projeto de serviço tem de criar um recurso elegível e configurá-lo para usar uma sub-rede de uma rede VPC partilhada. Por exemplo, não é possível reconfigurar uma instância existente num projeto de serviço para usar uma rede de VPC partilhada, mas pode criar uma nova instância para usar sub-redes disponíveis numa rede de VPC partilhada. Esta limitação aplica-se a zonas privadas.

Endereços IP

Quando cria uma instância num projeto de serviço, as versões de IP que pode configurar dependem da configuração da sub-rede do projeto anfitrião. Para mais informações, consulte o artigo Crie uma instância.

As instâncias em projetos de serviço anexados a um projeto anfitrião que usa a mesma rede de VPC partilhada podem comunicar internamente entre si usando os respetivos endereços IPv4 internos ou os respetivos 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ços IP aos recursos num projeto de serviço:

  • Endereços IPv4 e IPv6 efémeros: um endereço IP efémero pode ser atribuído automaticamente a uma instância num projeto de serviço. Por exemplo, quando os administradores do projeto de serviço criam instâncias, selecionam a rede da VPC partilhada e uma sub-rede partilhada disponível. Para instâncias com endereços IPv4, o endereço IPv4 interno principal provém do intervalo de endereços IP no intervalo de endereços IPv4 principal da sub-rede partilhada selecionada. Para instâncias com endereços IPv6, o endereço IPv6 vem do intervalo de endereços IP no intervalo de sub-rede IPv6 da sub-rede partilhada selecionada.

    Os endereços IPv4 efémeros também podem ser atribuídos automaticamente a equilibradores de carga internos. Para mais informações, consulte o artigo Crie um balanceador de carga de encaminhamento interno ou crie um balanceador de carga de aplicações interno.

  • Endereços IPv4 e IPv6 internos estáticos: um endereço IPv4 ou IPv6 interno estático pode ser reservado num projeto de serviço. O objeto de endereço IPv4 ou IPv6 interno tem de ser criado no mesmo projeto de serviço que o recurso que o usa, mesmo que o valor do endereço IP provenha dos endereços IP disponíveis da sub-rede partilhada selecionada numa rede de VPC partilhada. Para mais informações, consulte o artigo Reserve endereços IPv4 e IPv6 internos estáticos na página "Aprovisione a VPC partilhada".

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

  • Endereços IPv6 externos estáticos: um administrador do projeto de serviço também pode optar por reservar um endereço IPv6 externo estático. O objeto de endereço IPv6 externo tem de ser criado no mesmo projeto de serviço que o recurso que o usa, mesmo que o valor do endereço IP provenha dos endereços IPv6 disponíveis da sub-rede partilhada selecionada numa rede de VPC partilhada. Para mais informações, consulte o artigo Reserve um endereço IPv6 externo estático na página Aprovisione a VPC partilhada.

DNS interno

As VMs no mesmo projeto de serviço podem comunicar entre si através dos nomes DNS internos que o Google Cloud cria automaticamente. Google Cloud Estes nomes DNS usam o ID do projeto do projeto de serviço onde as VMs são criadas, embora os nomes apontem para endereços IP internos no projeto anfitrião. Para uma explicação completa, consulte Nomes DNS internos e VPC partilhada na documentação DNS interno.

Zonas privadas do Cloud DNS

Pode usar zonas privadas do Cloud DNS numa rede VPC partilhada. Pode criar a sua zona privada no projeto anfitrião e autorizar o acesso à zona para a rede de VPC partilhada ou configurar a zona num projeto de serviço através da associação entre projetos.

Balanceamento de carga

A VPC partilhada pode ser usada em conjunto com o Cloud Load Balancing. Na maioria dos casos, cria as instâncias de back-end num 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 anfitrião, esta configuração não é adequada para implementações típicas de VPC partilhada, uma vez que não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Use os links na tabela seguinte para saber mais sobre as arquiteturas de VPC partilhada suportadas para cada tipo de equilibrador de carga.

Tipo de balanceador de carga Links
Balanceador de carga de aplicações externo Arquitetura de VPC partilhada
Balanceador de carga de aplicações interno Arquitetura de VPC partilhada
Balanceador de carga de rede de proxy externo Arquitetura de VPC partilhada
Balanceador de carga de rede de proxy interno Arquitetura de VPC partilhada
Balanceador de carga de rede de passagem interno Arquitetura de VPC partilhada
Balanceador de carga de rede de passagem externo Arquitetura de VPC partilhada

Exemplos e exemplos de utilização

Conceitos básicos

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

Figura 1. Um projeto anfitrião com uma rede VPC partilhada oferece conetividade interna para dois projetos de serviço, enquanto um projeto autónomo não usa a VPC partilhada (clique para aumentar).

  • Um administrador da VPC partilhada da organização criou um projeto anfitrião e anexou-lhe dois projetos de serviço:

    • Os administradores do projeto de serviço no Service project A podem ser configurados para aceder a todas ou a algumas das sub-redes na rede de VPC partilhada. Um administrador do projeto de serviço com, pelo menos, autorizações ao nível da sub-rede para 10.0.1.0/24 subnet criou Instance A numa zona da região us-west1. Esta instância recebe o respetivo endereço IP interno, 10.0.1.3, do bloco CIDR 10.0.1.0/24.

    • Os administradores do projeto de serviço no Service project B podem ser configurados para aceder a todas ou a algumas das sub-redes na rede de VPC partilhada. Um administrador do projeto de serviço com, pelo menos, autorizações ao nível da sub-rede para 10.15.2.0/24 subnet criou Instance B numa zona da região us-east1. Esta instância recebe o respetivo endereço IP interno, 10.15.2.4, do 10.15.2.0/24 bloco CIDR.

  • O projeto autónomo não participa de todo na VPC partilhada. Não é um projeto anfitrião nem um projeto de serviço. As instâncias autónomas são criadas por principais da IAM que têm, pelo menos, a função compute.InstanceAdmin para o projeto.

Vários projetos anfitriões

A Figura 2 mostra como a VPC partilhada pode ser usada para criar ambientes de teste e produção separados. Neste caso, uma organização decidiu usar dois projetos anfitriões separados, um ambiente de teste e um ambiente de produção.

Figura 2. Um projeto anfitrião do ambiente de teste e um projeto anfitrião do ambiente de produção usam a VPC partilhada para criar ambientes de produção e de teste distintos (clique para aumentar).

  • Um administrador da VPC partilhada da organização criou dois projetos anfitriões e anexou-lhes dois projetos de serviço da seguinte forma:

    • Os projetos de serviço Apps testing e Mobile testing estão anexados ao projeto anfitrião Test environment. Os administradores do projeto de serviço em cada projeto podem ser configurados para aceder a todas ou a algumas das sub-redes no Testing network.

    • Os projetos de serviço Apps production e Mobile production estão anexados ao projeto anfitrião Production environment. Os administradores do projeto de serviço em cada projeto podem ser configurados para aceder a todas ou a algumas das sub-redes na Production network.

  • Ambos os projetos anfitriões têm uma rede de VPC partilhada com sub-redes configuradas para usar os mesmos intervalos CIDR. Tanto na Testing network como na Production network, as duas sub-redes são:

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

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

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

    • Os administradores do projeto de serviço podem criar instâncias como as que lhes são fornecidas, desde que tenham, pelo menos, autorizações ao nível da sub-rede para o 10.0.1.0/24 subnet.

    • Repare que ambas as instâncias usam o endereço IP 10.0.1.3. Isto é aceitável porque cada instância existe num projeto de serviço anexado a um projeto anfitrião exclusivo que contém a sua própria rede de VPC partilhada. As redes de teste e de produção foram configuradas intencionalmente da mesma forma.

    • As instâncias que usam o 10.0.1.0/24 subnet têm de estar localizadas numa zona na mesma região que a sub-rede, mesmo que a sub-rede e as instâncias estejam definidas em projetos separados. Uma vez que a 10.0.1.0/24 subnet está localizada na região us-west1, os administradores do projeto de serviço que criam instâncias através dessa sub-rede têm de escolher uma zona na mesma região, como us-west1-a.

Cenário de nuvem híbrida

A Figura 3 mostra como a VPC partilhada pode ser usada num ambiente híbrido.

Figura 3. Uma rede VPC partilhada está ligada a uma rede no local e a três projetos de serviço (clique para aumentar).

Para este exemplo, uma organização criou um único projeto anfitrião com uma única rede VPC partilhada. A rede VPC partilhada está ligada através do Cloud VPN a uma rede no local. Alguns serviços e aplicações estão alojados na Google Cloud , enquanto outros são mantidos no local:

  • Um administrador da VPC partilhada ativou o projeto anfitrião e associou-lhe três projetos de serviço: Service project A, Service project B e Service project C.

    • As equipas separadas podem gerir cada um dos projetos de serviços. As autorizações de IAM foram configuradas de forma que um administrador do projeto de serviço de um projeto não tenha autorizações para os outros projetos de serviço.

    • O administrador da VPC partilhada concedeu autorizações ao nível da sub-rede ou do projeto aos administradores do projeto de serviço necessários para que possam criar instâncias que usam a rede VPC partilhada:

      • Um administrador do projeto de serviço para Service project A que tenha autorizações ao nível da sub-rede para a 10.0.1.0/24 subnet pode criar Instance A na mesma. O administrador do projeto de serviço tem de escolher uma zona na us-west1região para a instância, porque essa é a região que contém o10.0.1.0/24 subnet. Instance A recebe o respetivo endereço IP, 10.0.1.3, do intervalo de endereços IP gratuitos no 10.0.1.0/24 subnet.

      • Um administrador do projeto de serviço para Service project B com autorizações ao nível da sub-rede para 10.15.2.0/24 subnet pode criar Instance B no mesmo. O administrador do projeto de serviço tem de escolher uma zona na us-east1região para a instância, porque essa é a região que contém o10.15.2.0/24 subnet. Instance B recebe o respetivo endereço IP, 10.15.2.4, do intervalo de endereços IP gratuitos em 10.15.2.0/24 subnet.

      • Um administrador do projeto de serviço para Service project C que tenha autorizações ao nível do projeto para todo o projeto anfitrião pode criar instâncias em qualquer uma das sub-redes em qualquer uma das redes VPC no projeto anfitrião. Por exemplo, o administrador do projeto de serviço pode criar uma 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 respetivo endereço IP, 10.7.1.50, do intervalo de endereços IP gratuitos no 10.7.1.0/24 Subnet.

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

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

    • Um administrador de rede criou um gateway do Cloud VPN e configurou um túnel de VPN através da Internet para um gateway no local. A Cloud VPN troca e recebe trajetos com a respetiva contrapartida no local porque foi configurado um Cloud Router correspondente na mesma us-east1região.

    • Se o modo de encaminhamento dinâmico da VPC for global, o Cloud Router aplica os trajetos aprendidos à rede nas instalações em todas as sub-redes na rede VPC e partilha trajetos com todas as sub-redes da VPC com a respetiva contrapartida nas instalações.

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

    • Sujeitas às regras de firewall aplicáveis, as instâncias nos projetos de serviço podem ser configuradas para comunicar com serviços internos, como servidores de bases de dados ou diretórios localizados no local.

Serviço Web de dois níveis

A Figura 4 demonstra como a VPC partilhada pode ser usada para delegar responsabilidades administrativas e manter o princípio do menor privilégio. Neste caso, uma organização tem um serviço Web separado em dois níveis, e equipas diferentes gerem cada nível. O nível 1 representa o componente virado para o exterior, atrás de um balanceador de carga HTTP(S). O nível 2 representa um serviço interno no qual o nível 1 se baseia e é equilibrado através de um balanceador de carga de TCP/UDP interno.

Figura 4. Neste serviço Web de dois níveis, um componente virado para o exterior e um serviço interno estão ligados a uma rede de VPC partilhada comum e são geridos por equipas diferentes (clique para aumentar).

A VPC partilhada permite-lhe mapear cada nível do serviço Web para diferentes projetos, de modo que possam ser geridos por diferentes equipas enquanto partilham uma rede VPC comum:

  • Os recursos, como instâncias e componentes do balanceador de carga, para cada nível são colocados em projetos de serviço individuais geridos por equipas diferentes.

  • Cada projeto de serviço de nível foi anexado ao projeto anfitrião por um administrador da VPC partilhada. O administrador da VPC partilhada também ativou o projeto anfitrião.

    • As equipas separadas podem gerir cada camada do serviço Web por serem administradores do projeto de serviço no projeto de serviço adequado.

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

  • O controlo de acesso à rede é delineado da seguinte forma:

    • Os principais da IAM que só trabalham no nível 1 são administradores do projeto de serviço para o Tier 1 service project e recebem autorizações ao nível da sub-rede apenas para o 10.0.1.0/24 subnet. Neste exemplo, um desses administradores 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 autorizações ao nível da sub-rede apenas para o 10.0.2.0/24 subnet. Neste exemplo, outro administrador do projeto de serviço criou três Tier 2 instances nessa sub-rede, juntamente com um equilibrador de carga interno cuja regra de encaminhamento usa um endereço IP do intervalo disponível nessa sub-rede.

    • Os principais da IAM que supervisionam todo o serviço Web são administradores do projeto de serviço em ambos os projetos de serviço e têm autorizações ao nível do projeto para o projeto anfitrião, para que possam usar qualquer sub-rede definida no mesmo.

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

O que se segue?