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ços 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:

  • 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 de computação no projeto, para criar e excluir instâncias que usam sub-redes aprovadas no projeto de 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 mais detalhes.

Conceitos

Organizações e projetos

A VPC compartilhada conecta projetos dentro da mesma organização. Os projetos de host e de serviço participantes não podem pertencer a organizações diferentes. Consulte a hierarquia de recursos do GCP para mais informações sobre organizações 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 habilitar 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 existentes 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:

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 a eles papéis apropriados de criação e exclusão de projetos, 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
Administradores de VPC compartilhada têm o papel de administrador de VPC compartilhada (compute.xpnAdmin) para a organização. 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 da VPC compartilhada para um determinado projeto host normalmente é também o proprietário do projeto.
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 todo o projeto host ou para sub-redes específicas das suas redes de VPC compartilhadas. 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 da VPC compartilhada pode conceder permissão para usar todo o projeto de host ou apenas algumas sub-redes:

  • Permissões no nível do projeto: um administrador de projeto de serviço pode receber permissão para usar todas as sub-redes no projeto host se o Administrador da 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 de host, incluindo sub-redes e redes VPC adicionadas ao projeto de host no futuro.

  • Permissões no nível da sub-rede: como alternativa, um administrador de projetos 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 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. Quando novas redes VPC compartilhadas ou novas sub-redes forem adicionadas ao projeto de host, um Administrador da 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 é regido pelos seguintes limites específicos para a VPC compartilhada:

Item Limite Observações
Número de projetos de serviço que podem ser anexados a um projeto host 100 Entre em contato com a equipe de vendas do GCP se precisar aumentar esse limite.
Número de projetos host na VPC compartilhada 100 Esse limite não pode ser aumentado.
Número de projetos host aos quais um projeto de serviço pode ser anexado 1 Esse limite não pode ser aumentado.

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 cobrança 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 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 de VPN. Por exemplo, se um gateway de VPN for criado na rede VPC compartilhada, ele estará contido no projeto do host. O tráfego de saída através do gateway de VPN, independentemente de qual projeto de serviço inicia a saída, é atribuído ao projeto de 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.

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 de 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 uma zona, a rede VPC compartilhada 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

Além de usar endereços IP internos para comunicação, as instâncias em projetos de serviço podem se comunicar por meio de nomes de DNS internos totalmente qualificados, como o seguinte. Observe que o código do projeto para cada nome DNS interno é o código do projeto de serviço, mesmo que aponte para um endereço IP no projeto host.

  • Instâncias usando o DNS zonal interno: [INSTANCE_NAME].[ZONE].c.[SERVICE_PROJECT_ID].internal
  • Instâncias que usam DNS global interno: [INSTANCE_NAME].c.[SERVICE_PROJECT_ID].internal

em que:

  • [INSTANCE_NAME] é o nome da instância;
  • [ZONE] é a zona em que o disco está;
  • [SERVICE_PROJECT_ID] é o projeto de serviço ao qual a instância pertence.

Para mais informações sobre nomes de domínio totalmente qualificados (FQDN, na sigla em inglês), leia DNS interno.

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.

A tabela a seguir resume os componentes dos três tipos de balanceadores de carga globais. Na maioria dos casos de uso, as instâncias com balanceamento de carga existem em um projeto de serviço, portanto, todos os componentes do balanceador de carga são criados nesse projeto. O endereço IP externo do balanceador de carga também vem do projeto de serviço, embora as instâncias participantes tenham IPs internos em uma sub-rede de uma rede VPC compartilhada.

Balanceador de carga Endereço IP Regra de encaminhamento Outros componentes de front-end Componentes de back-end
Balanceamento de carga HTTP(S) Um IP externo global precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga. Uma regra de encaminhamento global precisa ser definida no mesmo projeto que as instâncias com balanceamento de carga. O proxy HTTP ou HTTPS de destino e o mapa de URL associado precisam ser definidos no mesmo projeto que as instâncias com balanceamento de carga. Um serviço de back-end global 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.
Balanceamento de carga de proxy SSL O proxy SSL de destino precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga.
Balanceamento de carga de proxy TCP O proxy TCP de destino precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga.

A tabela a seguir resume os componentes dos dois tipos de balanceadores de carga regionais. Ela destaca como uma regra de encaminhamento 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 regional dentro da rede VPC compartilhada.

Balanceador de carga Endereço IP Regra de encaminhamento Componentes de back-end
Balanceamento de carga de rede regional Um IP externo regional precisa ser definido no mesmo projeto que as instâncias com balanceamento de carga. Uma regra de encaminhamento regional precisa ser definida no mesmo projeto que as instâncias com balanceamento de carga. O pool de destino precisa ser definido no mesmo projeto e na mesma região em que as instâncias com balanceamento de carga existem. As verificações de integridade associadas ao pool de destino também precisam ser definidas no mesmo projeto.
Balanceamento de carga interno e regional O IP interno pode vir do projeto de host ou de serviço:
  • Se o balanceador de carga precisar estar disponível para a rede VPC compartilhada, o IP interno viria do intervalo na sub-rede compartilhada.
  • Se o balanceador de carga precisar ser local para um projeto de serviço, o IP interno vem de uma sub-rede nesse 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 que ele faz referência determina se o balanceador de carga funciona em um cenário de VPC compartilhada:
  • Se o balanceador de carga estiver disponível para a rede VPC compartilhada, a regra de encaminhamento fará 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 faria 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 da VPC compartilhada da organização criou um projeto de 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 de 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 da VPC compartilhada da organização criou dois projetos de 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 de 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 de 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.

  • Ambos os projetos de 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 a 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 de 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 da VPC compartilhada habilitou o projeto de 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 da VPC compartilhada concedeu permissões no nível da sub-rede ou do projeto aos Administradores de projetos 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 no nível do projeto para todo o projeto de host pode criar instâncias em qualquer sub-rede em qualquer rede VPC do projeto de 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 é cobrado separadamente.

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

  • Um Administrador da 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 através da Internet para um gateway local. O Cloud VPN troca e recebe rotas com a contraparte local porque um Cloud Router correspondente us-east1 foi configurado na mesma região.

    • 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 da 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 camada 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 camada são colocados em projetos de serviços individuais gerenciados por equipes diferentes.

  • Cada projeto de serviço de diferentes camadas foi anexado ao projeto de host por um Administrador da VPC compartilhada. O Administrador da VPC compartilhada também ativou o projeto de host.

    • Equipes separadas podem gerenciar cada camada do serviço da Web em virtude de ter 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 membros do IAM que trabalham apenas na camada 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 desses Administrador do projeto de serviço criou três Tier 1 Instances nessa sub-rede.

    • Os membros do IAM que trabalham apenas na camada 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, juntamente 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 no nível do projeto para o projeto de host, de modo que podem usar qualquer sub-rede definida nele.

    • Opcionalmente, um Administrador da VPC compartilhada pode delegar tarefas de administração de rede a Administradores de rede e segurança.

Próximas etapas

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