Acesso privado a serviços em redes sobrepostas no GCP

Configuração final do Private Service Connect

O Project B é o projeto produtor do serviço, com um serviço nginx de exemplo implantado em uma instância de um managed instance group.

O Project A é o projeto consumidor e precisa acessar de forma privada o serviço do Project B. As instâncias dos dois projetos não têm IP externo atribuído.

• A região GCP dos recursos é us-west4
• A API compute.googleapis.com está habilitada no Project A e no Project B
• Cloud NAT para que as instâncias privadas tenham acesso à internet e possam baixar pacotes

Atualize as variáveis nos comandos abaixo.

• Crie um instance template no Project B.

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash$'\n'yum\ install\ epel-release$'\n'yum\ -y\ install\ nginx$'\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B

• Crie um managed instance group no Project B.

gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B

Após a criação bem-sucedida, o managed instance group sobe uma instância na zona de destino.

Acesse a instância via SSH e confira o status do serviço nginx.

• Crie uma instância de teste de conectividade no Project A.

gcloud compute instances create instance-1 \
    --zone=us-west4-b \
    --machine-type=e2-medium \
    --network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
    --maintenance-policy=MIGRATE \
    --provisioning-model=STANDARD \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
    --no-shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --labels=ec-src=vm_add-gcloud \
    --reservation-affinity=any \
    --project=$PROJECT_A

As redes do Project A e do Project B não têm conectividade interna entre si. Por isso, a instância no Project A não consegue acessar o serviço que roda no Project B.

O VPC peering também não é uma opção, já que há sobreposição de faixas na rede padrão.

Um load balancer interno é necessário para que o Private Service Connect exponha o serviço por meio do service attachment. Vamos criar um load balancer TCP interno para esta configuração no Project B.

• Crie um novo health check HTTP regional para testar a conectividade HTTP nas VMs pela porta 80.

gcloud compute health-checks create http nginx-service-health-check \
    --region=us-west4 \
    --port=80 \
    --project=$PROJECT_B

• Crie o backend service para o tráfego HTTP.

gcloud compute backend-services create nginx-service-internal-lb-backend \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west4 \
    --health-checks=nginx-service-health-check \
    --health-checks-region=us-west4 \
    --project=$PROJECT_B

• Adicione o instance group do serviço nginx ao backend service.

gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
    --region=us-west4 \
    --instance-group=nginx-service-instance-group \
    --instance-group-zone=us-west4-a \
    --project=$PROJECT_B

• Crie uma forwarding rule para o backend service.

gcloud compute forwarding-rules create nginx-service-internal-fr \
    --region=us-west4 \
    --load-balancing-scheme=internal \
    --network=default \
    --subnet=default \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=nginx-service-internal-lb-backend \
    --backend-service-region=us-west4 \
    --project=$PROJECT_B

• Crie uma regra de firewall para liberar os health checks do load balancer.

gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B

Publique o serviço no Project B (o projeto produtor) para que consumidores em outras redes VPC possam se conectar e acessar o serviço de forma privada e segura.

• Reserve uma sub-rede para o Private Service Connect. Essa faixa não pode se sobrepor à rede padrão.

gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B

• Publique o serviço nginx para o Project A com aprovação explícita do projeto.

gcloud compute service-attachments create nginx-service \
    --region=us-west4 \
    --producer-forwarding-rule=nginx-service-internal-fr  \
    --connection-preference=ACCEPT_MANUAL \
    --nat-subnets=private-service-connect \
    --consumer-accept-list=$PROJECT_A=10 \
    --project=$PROJECT_B

Você pode controlar quais consumidores acessam os serviços publicados via aprovação automática ou manual. Consulte Publicar serviços usando o Private Service Connect.

• Crie uma regra de firewall para permitir que o Private Service Connect acesse as instâncias de destino.

gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B

Um endpoint no projeto consumidor se conecta aos serviços na rede VPC do produtor por meio de uma forwarding rule do Private Service Connect.

Ao criar um endpoint, ele é registrado automaticamente no Service Directory, usando um namespace que você definir ou o namespace padrão, goog-psc-default.

Para deixar o Endpoint disponível em mais de uma região, ative o acesso global. O acesso global está em Preview.

• Reserve um endereço IP interno para atribuir ao Endpoint.

gcloud compute addresses create private-service-connect-endpoint \
    --region=us-west4 \
    --subnet=default \
    --project=$PROJECT_A

• Crie uma forwarding rule para conectar o Endpoint ao service attachment do Project B.

PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
   --region=us-west4 \
   --project=$PROJECT_B \
   --format="value(selfLink.scope(projects))")

gcloud compute forwarding-rules create nginx-service \
  --region=us-west4 \
  --network=default \
  --address=private-service-connect-endpoint \
  --target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
  --project=$PROJECT_A

Os componentes do Private Service Connect já estão configurados no Project A e no Project B. Use o IP do endpoint no Project A para acessar o serviço nginx no Project B.

O teste confirma que as instâncias nas redes sobrepostas conseguem se comunicar de forma privada via Endpoint do Private Service Connect.