Acesso privado a serviços em redes sobrepostas no Google Cloud

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash


Crie um managed instance group no Projeto 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
Quando a criação termina com sucesso, 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 Projeto 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 Projeto A e do Projeto B não têm conectividade interna entre si. Por isso, a instância no Projeto A não consegue acessar o serviço que roda no Projeto B.
O VPC peering também não é uma opção, já que há sobreposição de faixas na rede padrão.
Configurar o load balancer interno
O Private Service Connect precisa de um load balancer interno para expor o serviço por meio de um service attachment. Para essa configuração, vamos criar um load balancer TCP interno no Projeto B.

Crie um novo health check HTTP regional para testar a conectividade HTTP nas VMs na 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


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

Reserve uma sub-rede para o Private Service Connect. A faixa dessa sub-rede 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 Projeto 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ê define quais consumidores podem acessar os serviços publicados por aprovação automática ou manual. Veja mais em Publish services by using 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


Configurar o Endpoint no projeto consumidor
Um endpoint no projeto consumidor se conecta aos serviços da rede VPC produtora por meio de uma forwarding rule do Private Service Connect.
Ao criar um endpoint, ele é registrado automaticamente no Service Directory, em um namespace que você escolhe ou no padrão, goog-psc-default.
Para disponibilizar o Endpoint em mais de uma região, ative o global access. O global access 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 Projeto 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


Testar a conectividade a partir do projeto consumidor
Os componentes do Private Service Connect já estão configurados nos Projetos A e B. Use o IP do endpoint do Projeto A para acessar o serviço nginx no Projeto B.
O teste confirma que as instâncias nas redes sobrepostas conseguem se comunicar de forma privada pelo Endpoint do Private Service Connect.

Este exemplo mostra como usar o Private Service Connect para publicar e consumir serviços com segurança em redes sobrepostas.
O tráfego permanece inteiramente dentro do Google Cloud, com acesso orientado a serviços entre consumidores e produtores e controle granular sobre como cada serviço é acessado.
Saiba mais sobre o Private Service Connect na página do produto.
\n'yum\ install\ epel-release


Crie um managed instance group no Projeto B.

Quando a criação termina com sucesso, 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 Projeto A.


As redes do Projeto A e do Projeto B não têm conectividade interna entre si. Por isso, a instância no Projeto A não consegue acessar o serviço que roda no Projeto B.
O VPC peering também não é uma opção, já que há sobreposição de faixas na rede padrão.
Configurar o load balancer interno
O Private Service Connect precisa de um load balancer interno para expor o serviço por meio de um service attachment. Para essa configuração, vamos criar um load balancer TCP interno no Projeto B.

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


Crie o backend service para o tráfego HTTP.


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


Crie uma forwarding rule para o backend service.


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



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

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


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

Você define quais consumidores podem acessar os serviços publicados por aprovação automática ou manual. Veja mais em Publish services by using Private Service Connect.

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



Configurar o Endpoint no projeto consumidor
Um endpoint no projeto consumidor se conecta aos serviços da rede VPC produtora por meio de uma forwarding rule do Private Service Connect.
Ao criar um endpoint, ele é registrado automaticamente no Service Directory, em um namespace que você escolhe ou no padrão, goog-psc-default.
Para disponibilizar o Endpoint em mais de uma região, ative o global access. O global access está em Preview.

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


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



Testar a conectividade a partir do projeto consumidor
Os componentes do Private Service Connect já estão configurados nos Projetos A e B. Use o IP do endpoint do Projeto A para acessar o serviço nginx no Projeto B.
O teste confirma que as instâncias nas redes sobrepostas conseguem se comunicar de forma privada pelo Endpoint do Private Service Connect.

Este exemplo mostra como usar o Private Service Connect para publicar e consumir serviços com segurança em redes sobrepostas.
O tráfego permanece inteiramente dentro do Google Cloud, com acesso orientado a serviços entre consumidores e produtores e controle granular sobre como cada serviço é acessado.
Saiba mais sobre o Private Service Connect na página do produto.
\n'yum\ -y\ install\ nginx


Crie um managed instance group no Projeto B.

Quando a criação termina com sucesso, 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 Projeto A.


As redes do Projeto A e do Projeto B não têm conectividade interna entre si. Por isso, a instância no Projeto A não consegue acessar o serviço que roda no Projeto B.
O VPC peering também não é uma opção, já que há sobreposição de faixas na rede padrão.
Configurar o load balancer interno
O Private Service Connect precisa de um load balancer interno para expor o serviço por meio de um service attachment. Para essa configuração, vamos criar um load balancer TCP interno no Projeto B.

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


Crie o backend service para o tráfego HTTP.


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


Crie uma forwarding rule para o backend service.


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



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

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


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

Você define quais consumidores podem acessar os serviços publicados por aprovação automática ou manual. Veja mais em Publish services by using Private Service Connect.

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



Configurar o Endpoint no projeto consumidor
Um endpoint no projeto consumidor se conecta aos serviços da rede VPC produtora por meio de uma forwarding rule do Private Service Connect.
Ao criar um endpoint, ele é registrado automaticamente no Service Directory, em um namespace que você escolhe ou no padrão, goog-psc-default.
Para disponibilizar o Endpoint em mais de uma região, ative o global access. O global access está em Preview.

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


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



Testar a conectividade a partir do projeto consumidor
Os componentes do Private Service Connect já estão configurados nos Projetos A e B. Use o IP do endpoint do Projeto A para acessar o serviço nginx no Projeto B.
O teste confirma que as instâncias nas redes sobrepostas conseguem se comunicar de forma privada pelo Endpoint do Private Service Connect.

Este exemplo mostra como usar o Private Service Connect para publicar e consumir serviços com segurança em redes sobrepostas.
O tráfego permanece inteiramente dentro do Google Cloud, com acesso orientado a serviços entre consumidores e produtores e controle granular sobre como cada serviço é acessado.
Saiba mais sobre o Private Service Connect na página do produto.
\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