Visão geral da VPC compartilhada

A VPC compartilhada permite que uma organização conecte recursos de vários projetos a uma rede VPC comum para que eles possam se comunicar de maneira segura e eficiente usando 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.

Com a VPC compartilhada, os administradores da organização delegam aos administradores de projetos 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 host e de serviço participantes não podem pertencer a organizações diferentes. 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 GCP para saber mais informações sobre organizações, pastas e 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. Ao ser anexado, o projeto participa da VPC compartilhada. É uma prática comum manter vários projetos de serviço operados e administrados por diferentes departamentos ou equipes dentro da 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. Veja o exemplo de vários projetos host para ilustraçã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.

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 é habilitado para a VPC compartilhada, todas as redes VPC nele tornam-se redes VPC compartilhadas, e qualquer nova rede criada nele também será automaticamente uma rede VPC compartilhada. Assim, um único projeto host pode ter mais de uma rede VPC compartilhada.

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.

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 membros do IAM, como usuários, grupos do Google, domínios do Google ou contas de serviço do GCP. 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 Finalidade
Administrador da organização
  • Membro 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
  • membro do IAM na organização ou
  • membro do IAM em uma pasta (Beta)
Os administradores de VPC compartilhada têm o papel de administrador de VPC compartilhada (compute.xpnAdmin) 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
  Membro do IAM em um projeto de serviço ou
  • Membro do IAM na organização
Um administrador de VPC compartilhada define um administrador de projeto de serviço concedendo a um membro 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 de 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 de 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 forem adicionadas ao projeto host, um administrador de VPC compartilhada precisa revisar as vinculações de permissão do papel compute.networkUser para garantir que as permissões no nível da sub-rede para todos os administradores de projeto de serviço 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 membros do IAM:

Administrador Finalidade
Administrador de rede
  • Membro do IAM no projeto de host ou
  • Membro do IAM na organização
O administrador de VPC compartilhada define um administrador de rede concedendo a um membro do IAM o papel de 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
  • Membro do IAM no projeto de host ou
  • Membro do IAM na organização
Um administrador de VPC compartilhada pode definir um administrador de segurança ao conceder a um membro do IAM o papel de 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, o relacionamento entre os projetos host e de serviço é determinado 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 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 em um projeto de serviço, mas usar uma rede VPC compartilhada, qualquer faturamento para o tráfego de saída gerada será atribuída 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 saber mais detalhes sobre o balanceamento de carga e a VPC compartilhada, consulte a seção de balanceamento de carga.
    • O tráfego de saída para VPNs é atribuído ao projeto que contém o recurso Gateway da 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, independentemente de qual projeto de serviço inicia a saída, é atribuído ao projeto host.

Recursos

Recursos qualificados

Os seguintes recursos de projeto de serviço podem usar a VPC compartilhada e estão sujeitos a algumas limitações práticas:

Limitações práticas para recursos qualificados

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.

Recursos não qualificados

Em um projeto de serviço, os recursos flexíveis do App Engine não podem participar da VPC compartilhada.

Endereços IP

Instâncias em projetos de serviço anexadas a um projeto host que usam a mesma rede VPC compartilhada podem se comunicar umas com as outras por meio de endereços IP internos estáticos reservados ou temporários, de acordo com as regras de firewall aplicáveis.

Um endereço IP interno temporário pode ser atribuído automaticamente a uma instância em um projeto de serviço. Por exemplo, quando os administradores de projetos de serviço criam instâncias, eles selecionam a rede VPC compartilhada, uma zona e uma sub-rede disponível. O endereço IP vem do intervalo de endereços IP disponíveis na sub-rede compartilhada selecionada.

Como alternativa, um Administrador de projeto de serviço pode optar por reservar um endereço IP interno estático. O próprio objeto de endereço IP precisa ser criado no mesmo projeto de serviço da instância que o usará, embora o valor do endereço IP venha do intervalo de IPs disponíveis em uma sub-rede compartilhada selecionada da rede VPC compartilhada. Para mais informações, consulte como reservar um IP interno estático na página Como provisionar a VPC compartilhada.

Endereços IP externos definidos no projeto de host só podem ser usados ​​por recursos nesse projeto. Eles não estão disponíveis para uso em projetos de serviço. Os projetos de serviço podem manter o próprio conjunto de endereços IP externos. Por exemplo, uma instância em um projeto de serviço precisa usar um endereço IP externo definido nesse mesmo projeto de serviço. Esse é o caso, mesmo se a instância usar um endereço IP interno de uma rede VPC compartilhada no projeto de host.

DNS interno

As VMs no mesmo projeto de serviço podem se comunicar usando os nomes DNS internos criados automaticamente pelo GCP. 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 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. Você precisa criar sua zona particular no projeto host e autorizar o acesso à zona da rede VPC compartilhada.

Balanceamento de carga

Use a VPC compartilhada em conjunto com o balanceamento de carga. Todos os componentes de balanceamento de carga precisam existir no mesmo projeto, ou todos em um projeto host ou todos em um projeto de serviço. A criação de alguns componentes do balanceador de carga em um projeto host e outros em um projeto de serviço anexado não é compatível. No entanto, a regra de encaminhamento de um balanceador de carga interno criado em um projeto de serviço pode fazer referência a uma sub-rede compartilhada no projeto host a que o projeto de serviço está anexado. Para mais informações, consulte Como criar um balanceador de carga interno na página Como provisionar a VPC compartilhada.

A tabela a seguir resume os componentes para balanceamento de carga HTTP(S), proxy SSL e proxy TCP. 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. Também é possível criar as instâncias de back-end no projeto host. Nesse caso, todos os componentes do balanceador de carga precisariam estar no projeto host.

Balanceador de carga Endereço IP Regra de encaminhamento Outros componentes de front-end Componentes de back-end
Balanceamento de carga HTTP(S) Um endereço IP externo precisa ser definido no mesmo projeto que as instâncias balanceadas por carga (o projeto de serviço). A regra de encaminhamento externo precisa ser definida no mesmo projeto que as instâncias de back-end (o projeto de serviço). O proxy de destino HTTP ou HTTPS e o mapa de URL associado precisam ser definidos no mesmo projeto que as instâncias de back-end. Um serviço de back-end global precisa ser definido no mesmo projeto que as instâncias de back-end. Essas instâncias precisam estar em grupos de instâncias anexados ao serviço de back-end como back-ends. As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.
Balanceamento de carga de proxy SSL O proxy SSL de destino precisa ser definido no mesmo projeto que as instâncias de back-end.
Balanceamento de carga de proxy TCP O proxy TCP de destino precisa ser definido no mesmo projeto que as instâncias de back-end.

A tabela a seguir resume os componentes dos dois tipos de balanceadores de carga regionais. Ela destaca como uma regra de encaminhamento interno para um balanceador de carga interno pode fazer referência a uma sub-rede compartilhada em uma rede VPC compartilhada para fornecer balanceamento de carga interno dentro dessa rede.

Balanceador de carga Endereço IP Regra de encaminhamento Componentes de back-end
Balanceamento de carga da rede Um endereço IP externo regional precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga. Uma regra de encaminhamento externo regional precisa ser definida no mesmo projeto que as instâncias no pool de destino (o projeto de serviço). O pool de destino precisa ser definido no mesmo projeto e na mesma região em que as instâncias no pool de destino existirem. As verificações de integridade associadas ao pool de destino também precisam ser definidas no mesmo projeto.
Balanceamento de carga interno O endereço IP interno pode vir do projeto host ou de serviço:
  • Se o balanceador de carga precisar estar disponível para a rede VPC compartilhada, o endereço IP interno precisa vir do intervalo de endereços IP principal de uma sub-rede compartilhada.
  • Se o balanceador de carga precisar ser local para um projeto de serviço, o endereço IP interno pode vir de uma sub-rede em uma rede no projeto de serviço.
Uma regra de encaminhamento regional precisa ser definida no mesmo projeto que as instâncias com balanceamento de carga. No entanto, a sub-rede a qual ele faz referência determina se o balanceador de carga funciona em um cenário de VPC compartilhada:
  • Se o balanceador de carga precisar estar disponível para a rede VPC compartilhada, a regra de encaminhamento precisará fazer referência a uma sub-rede compartilhada. Para instruções específicas, consulte como criar um balanceador de carga interno na página Como provisionar a VPC compartilhada.
  • Se o balanceador de carga precisar ser local para um projeto de serviço, a regra de encaminhamento poderá fazer referência a uma sub-rede em uma rede nesse projeto de serviço.
Um serviço de back-end regional precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga. As instâncias com balanceamento de carga precisam estar em grupos de instâncias anexadas ao serviço de back-end como back-ends. As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.

Exemplos e casos de uso

Conceitos básicos

No exemplo a seguir, ilustramos um cenário simples de VPC compartilhada:

Conceitos básicos (clique para ampliar)
Conceitos básicos (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.

    • Os 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 membros do IAM que têm pelo menos o papel compute.InstanceAdmin para o projeto.

Vários projetos de host

No exemplo a seguir, demonstramos 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.

Vários projetos de host (clique para ampliar)
Vários projetos de host (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 um podem receber acesso a 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 um podem receber acesso a 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

  • Pense na Instance AT no projeto de serviço Apps Testing e a 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.

    • As 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 com essa sub-rede precisam escolher uma zona na mesma região, como us-west1-a.

Cenário de nuvem híbrida

No exemplo a seguir, demonstramos como a VPC compartilhada pode ser usada em um ambiente híbrido.

Nuvem híbrida (clique para ampliar)
Nuvem híbrida (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 por meio do Cloud VPN a uma rede local. Alguns serviços e aplicativos são hospedados no GCP 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 do projeto de serviço precisa escolher uma zona na região us-west1 para a 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 do projeto de serviço precisa escolher uma zona na região us-east1 para a 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 de Service Project C com permissões para envolvidos no projeto para todo o projeto host pode criar instâncias em qualquer sub-rede em qualquer rede VPC do projeto host. Por exemplo, o administrador do projeto de serviço pode criar a 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 é faturado 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 membros 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 por meio da 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 GCP 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

No exemplo a seguir, demonstramos como a VPC compartilhada pode ser usada para delegar responsabilidades administrativas e manter o princípio do menor privilégio. Para este caso, uma organização tem um serviço da Web que é separado em duas camadas e equipes diferentes gerenciam cada camada. A camada 1 representa o componente externo, atrás de um balanceador de carga HTTP global. A camada 2 representa um serviço interno em que a camada 1 se baseia, e é balanceada com um Balanceador de carga interno.

Serviço da Web de duas camadas (clique para ampliar)
Serviço da Web de duas camadas (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 é faturado 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 membros 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 membros 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, 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 membros 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

Esta página foi útil? Conte sua opinião sobre: