Private Service Connect: como usar back-ends do PSC para acessar um serviço de produtor

1. Introdução

O Private Service Connect permite que os produtores de serviços exponham serviços de forma privada de uma rede VPC para outra. Os consumidores podem acessar os serviços do produtor por endpoints ou back-ends do PSC.

O foco deste codelab é o back-end do PSC. Os back-ends do PSC são usados com os balanceadores de carga de proxy do Google Cloud (aplicativo ou rede). O uso de back-ends do PSC oferece controles mais granulares do lado do consumidor, como:

• Observabilidade e geração de registros mais profundas
• Integração do Cloud Armor
• URLs personalizados
• Gerenciamento de tráfego avançado
• Certificados TLS personalizados

Neste codelab, você vai aprender a criar um back-end do Private Service Connect com o balanceador de carga de aplicativo externo global para acessar um serviço de produtor em particular em outra rede.

O que você vai aprender

• Criar e configurar um back-end de PSC associado ao balanceador de carga de aplicativo externo global
• Configurar um serviço da Web gerenciado pelo Apache e expô-lo como um serviço do PSC usando um anexo de serviço
• Criar certificados SSL para encerrar SSL em balanceadores de carga de aplicativo internos e externos
• Configurar uma zona pública do Cloud DNS para acessar o serviço PSC

O que é necessário

• Um projeto do Google Cloud com permissões de proprietário

2. Ambiente de teste

O ambiente que você vai criar vai consistir em uma VPC de consumidor e uma VPC de produtor. Na VPC do produtor, você vai implantar um grupo de instâncias gerenciadas usando um modelo de instância que cria um serviço da Web Apache de código aberto. Você também vai implantar uma VM de teste para garantir a funcionalidade local adequada do serviço. Você vai expor o serviço do Apache como um serviço de produtor do PSC usando um anexo de serviço.

Na VPC do consumidor, você implanta um balanceador de carga de aplicativo externo global com um serviço de back-end PSC que aponta para o serviço Apache. Em seguida, você vai configurar uma zona de DNS pública para acessar o serviço PSC na Internet pública.

3. Configuração e requisitos

Configuração de ambiente autoguiada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você usa uma conta do Gmail, defina o local padrão como Sem organização. Se você usa uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

4. Antes de começar

Ativar APIs

No Cloud Shell, verifique se o ID do projeto está configurado:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export project=YOUR-PROJECT-NAME
export region=us-central1
echo $project
echo $region

Ativar todos os serviços necessários

gcloud services enable compute.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable dns.googleapis.com

5. Configuração da VPC do produtor

Criar rede VPC

No Cloud Shell

gcloud compute networks create producer-vpc --subnet-mode custom

Criar sub-redes

Duas sub-redes de finalidade geral serão implantadas na VPC do produtor. A sub-rede de serviço será usada para implantar as VMs do serviço da Web Apache e a regra de encaminhamento do balanceador de carga. A sub-rede de cliente de teste vai estar em uma região diferente e será usada para implantar uma VM para testar o serviço Apache com o acesso global ativado.

No Cloud Shell

gcloud compute networks subnets create service-subnet \
    --network=producer-vpc \
    --range=10.0.0.0/28 \
    --region=$region

No Cloud Shell

gcloud compute networks subnets create test-client-subnet \
    --network=producer-vpc \
    --range=10.0.1.0/28 \
    --region=us-east4

Também precisamos implantar uma sub-rede somente proxy para ser usada com o balanceador de carga de aplicativo interno regional.

No Cloud Shell

gcloud compute networks subnets create central-proxy-subnet \
    --network=producer-vpc \
    --range=10.100.101.0/24 \
    --region=$region \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE

Quando um serviço do PSC é implantado, cada serviço único precisa de uma sub-rede NAT do PSC correspondente para ser associado ao anexo de serviço. O tamanho dessa sub-rede precisa ser adequado ao número de endpoints conectados esperados.

No Cloud Shell

gcloud compute networks subnets create psc-nat-subnet \
    --network=producer-vpc \
    --region=$region \
    --range=10.100.100.0/24 \
    --purpose=PRIVATE_SERVICE_CONNECT

OBSERVAÇÃO: as sub-redes com a finalidade de PRIVATE_SERVICE_CONNECT só podem ser usadas para serviços PSC. Não é possível implantar cargas de trabalho nessa sub-rede.

Criar o Cloud NAT

É necessário um NAT do Cloud para instalar os pacotes adequados para nossos serviços de produtor.

No Cloud Shell

gcloud compute routers create central-cr \
    --network=producer-vpc \
    --region=$region

No Cloud Shell

gcloud compute routers nats create central-nat \
    --router=central-cr \
    --region=$region \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

Criar políticas e regras de firewall de rede

No Cloud Shell

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create \
    --firewall-policy producer-vpc-policy \
    --network producer-vpc \
    --name network-producer-vpc \
    --global-firewall-policy

Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias da VM que você quer que sejam acessíveis usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.

No Cloud Shell

gcloud compute network-firewall-policies rules create 1000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "SSH with IAP" \
    --direction INGRESS \
    --src-ip-ranges 35.235.240.0/20 \
    --layer4-configs tcp:22  \
    --global-firewall-policy

Duas regras de firewall adicionais serão necessárias para permitir o tráfego de entrada nos back-ends do balanceador de carga provenientes da sub-rede somente proxy do balanceador de carga (2000), além de uma regra para permitir verificações de integridade do balanceador de carga nas instâncias de back-end (2001).

No Cloud Shell

gcloud compute network-firewall-policies rules create 2000 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow traffic from load balancer proxy subnet" \
    --direction INGRESS \
    --src-ip-ranges 10.100.101.0/24 \
    --layer4-configs tcp:443 \
    --global-firewall-policy


gcloud compute network-firewall-policies rules create 2001 \
    --action ALLOW \
    --firewall-policy producer-vpc-policy \
    --description "allow load balancer health checks" \
    --direction INGRESS \
    --src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
    --layer4-configs tcp:443 \
    --global-firewall-policy

6. Criar um serviço da Web Apache

Vamos criar um serviço da Web Apache simples que mostra "PSC Service".

Criar modelo de instância

No Cloud Shell

gcloud compute instance-templates create apache-service-template \
    --network producer-vpc \
    --subnet service-subnet \
    --region $region \
    --no-address \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "PSC Service" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Criar uma verificação de integridade para o MIG

No Cloud Shell

gcloud compute health-checks create https service-mig-healthcheck \
    --port=443 \
    --global

Criar grupo gerenciado de instâncias

No Cloud Shell

gcloud compute instance-groups managed create psc-service-mig \
    --region $region \
    --size=2 \
    --template=apache-service-template \
    --health-check=service-mig-healthcheck

gcloud compute instance-groups managed set-named-ports psc-service-mig \
    --named-ports=https:443 \
    --region=$region

7. Criar um certificado autoassinado

Conclua a etapa 1 das instruções aqui para criar um certificado autoassinado. É possível executar todos os comandos no Cloud Shell. Volte a esta página quando a Etapa 1 for concluída. SEU NOME COMUM PRECISA SER CONFIGURADO COM EXAMPLE.COM.

Crie um recurso de certificado para associar ao balanceador de carga. Substitua os parâmetros de certificado e chave privada pelos nomes dos arquivos específicos.

No Cloud Shell

gcloud compute ssl-certificates create producer-service-cert \
    --certificate=<your-producer-certfile.cert> \
    --private-key=<your-producer-keyfile.pem> \
    --region=$region

8. Criar o balanceador de carga de aplicativo interno regional

Em seguida, vamos criar os componentes do balanceador de carga para o serviço. Estamos usando o balanceador de carga de aplicativo regional interno, mas você pode usar qualquer balanceador de carga interno do Google Cloud. Siga a documentação adequada do balanceador de carga para o processamento de TLS.

No momento da publicação deste codelab, não é possível usar balanceadores de carga de aplicativo internos entre regiões para serviços de produtor PSC.

Crie o endereço IP interno que será usado para a regra de encaminhamento do balanceador de carga e anote o IP que será usado mais tarde ao fazer uma chamada de teste para o serviço.

No Cloud Shell

gcloud compute addresses create apache-service-ip \
 --region=$region \
 --subnet=service-subnet

gcloud compute addresses describe apache-service-ip \
   --format="get(address)" \
   --region=$region

Crie a verificação de integridade do balanceador de carga.

No Cloud Shell

gcloud compute health-checks create https lb-apache-service-hc \
    --region=$region \
    --port-name=https

Crie o serviço de back-end:

No Cloud Shell

gcloud compute backend-services create apache-bes\
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --port-name=https \
  --health-checks=lb-apache-service-hc \
  --health-checks-region=$region \
  --region=$region


gcloud compute backend-services add-backend apache-bes \
  --balancing-mode=UTILIZATION \
  --instance-group=psc-service-mig \
  --region=$region

Crie o mapa de URLs.

No Cloud Shell

gcloud compute url-maps create producer-url-map \
  --default-service=apache-bes \
  --region=$region

Crie os proxies HTTPS de destino.

No Cloud Shell

gcloud compute target-https-proxies create https-proxy \
  --url-map=producer-url-map \
  --region=$region \
  --ssl-certificates=producer-service-cert

Crie a regra de encaminhamento.

Observação:para permitir o acesso por um back-end do Private Service Connect em um balanceador de carga global ou inter-regional, o balanceador de carga do produtor precisa ter o acesso global ativado antes da criação do anexo de serviço.

No Cloud Shell

gcloud compute forwarding-rules create apache-fr \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=producer-vpc \
  --subnet=service-subnet \
  --address=apache-service-ip \
  --ports=443 \
  --region=$region \
  --target-https-proxy=https-proxy \
  --target-https-proxy-region=$region \
  --allow-global-access

9. Criar uma VM de teste e testar o serviço localmente

Antes de criar o anexo de serviço, vamos criar uma VM de cliente de teste em uma região diferente para testar se o balanceador de carga está configurado corretamente com o acesso global e o TLS.

No Cloud Shell

gcloud compute instances create vm-client \
    --zone=us-east4-a \
    --subnet=test-client-subnet \
    --no-address

Aguarde cerca de um minuto para que o provisionamento seja concluído e use SSH na instância.

No Cloud Shell

gcloud compute ssh \
    --zone "us-east4-a" "vm-client" \
    --tunnel-through-iap \
    --project $project

Teste o serviço Apache se conectando pelo 443 pelo balanceador de carga. O endereço IP interno é aquele que você reservou e anotou anteriormente.

curl https://example.com:443 -k --connect-to example.com:443:<YOUR-INTERNAL-IP>:443

RESULTADO ESPERADO

PSC Service

Se você estiver recebendo erros de SSL, verifique se configurou o commonName do certificado e/ou o DNS sanlist_list como example.com.

Saia da VM.

Em vm-client

exit

10. Criar o anexo de serviço

Neste exemplo, estamos configurando o anexo de serviço para permitir apenas conexões PSC desse projeto. Isso pode ser configurado para aceitar um ou mais projetos ou redes específicos, mas não os dois. Definimos o limite máximo de conexões em 5. Cada projeto ou rede precisa ter um limite definido.

No Cloud Shell

gcloud compute service-attachments create apache-service-attachment \
    --region=$region \
    --producer-forwarding-rule=apache-fr \
    --connection-preference=ACCEPT_MANUAL \
    --consumer-accept-list=$project=5 \
    --nat-subnets=psc-nat-subnet

Anote o URI do anexo do serviço (selfLink), porque você vai precisar dele na próxima etapa da configuração do back-end do PSC. Para isso, execute o seguinte comando no Cloud Shell:

No Cloud Shell

gcloud compute service-attachments describe apache-service-attachment \
    --region $region

Copie o URI a partir de projects.

Exemplo:projects/$project/regions/$region/serviceAttachments/apache-service-attachment

11. Configuração da VPC do consumidor

Criar rede VPC

No Cloud Shell

gcloud compute networks create consumer-vpc --subnet-mode custom

Criar sub-rede

Uma sub-rede é necessária no lado do consumidor, onde o grupo de endpoints de rede (NEG, na sigla em inglês) do Private Service Connect será implantado.

No Cloud Shell

gcloud compute networks subnets create consumer-subnet \
    --network=consumer-vpc \
    --region=$region \
    --range=10.0.0.0/28

12. Reservar IP externo e criar certificado autoassinado do lado do consumidor

IP Externo

Crie o endereço IP estático externo que será usado mais tarde para a regra de encaminhamento do balanceador de carga e capture o endereço IP em uma variável do Cloud Shell.

No Cloud Shell

gcloud compute addresses create external-psc-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

export externalip=$(gcloud compute addresses describe external-psc-ip \
    --format="get(address)" \
    --global)

echo $externalip

Certificado autoassinado do consumidor

Pela segunda vez, conclua a Etapa 1 das instruções aqui para criar um certificado autoassinado. É possível executar todos os comandos no Cloud Shell. Volte a esta página quando a Etapa 1 for concluída. Vamos usar um serviço de DNS curinga público de código aberto chamado nip.io em vez de ter nossa própria zona de DNS pública. O URL público do serviço PSC vai usar o endereço IP externo que você acabou de configurar. SEU NOME COMUM PRECISA SER CONFIGURADO COM <YOUR-EXTERNAL-IP.nip.io>

Crie um recurso de certificado para associar ao balanceador de carga externo. Substitua os parâmetros de certificado e chave privada pelos nomes dos arquivos específicos.

No Cloud Shell

gcloud compute ssl-certificates create consumer-service-cert \
    --certificate=<your-consumer-certfile.cert> \
    --private-key=<your-consumer-keyfile.pem> \
    --global

13. Criar os componentes do balanceador de carga

Vamos criar um balanceador de carga de aplicativo externo global com um NEG do PSC que aponte para o novo anexo de serviço como um serviço de back-end.

É possível usar qualquer balanceador de carga de proxy do Google Cloud com um back-end do PSC. Não há suporte para as versões clássicas dos balanceadores de carga de rede e de aplicativo externos.

Tenha em mãos o URI do anexo de serviço que você anotou na última etapa. Substitua o psc-target-service abaixo pelo seu URI.

No Cloud Shell

gcloud compute network-endpoint-groups create apache-psc-neg \
--network-endpoint-type=private-service-connect \
--psc-target-service=projects/$project/regions/$region/serviceAttachments/apache-service-attachment \
--region=$region \
--network=consumer-vpc \
--subnet=consumer-subnet

Crie o serviço de back-end.

No Cloud Shell

gcloud compute backend-services create apache-pscneg-bes \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTPS \
    --global

gcloud compute backend-services add-backend apache-pscneg-bes \
    --network-endpoint-group=apache-psc-neg \
    --network-endpoint-group-region=$region \
    --global

Criar o mapa de URLs

No Cloud Shell

gcloud compute url-maps create consumer-url-map \
    --default-service=apache-pscneg-bes \
    --global

Crie os proxies HTTPS de destino.

No Cloud Shell

gcloud compute target-https-proxies create psc-https-proxy \
    --url-map=consumer-url-map \
    --ssl-certificates=consumer-service-cert

Criar a regra de encaminhamento

No Cloud Shell

gcloud compute forwarding-rules create external-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=external-psc-ip \
  --global \
  --target-https-proxy=psc-https-proxy \
  --ports=443

14. Criar uma zona de DNS pública

No Cloud Shell

gcloud dns managed-zones create "psc-service" \
    --dns-name=$externalip.nip.io. \
    --description="public dns for psc service" \
    --visibility=public

No Cloud Shell

gcloud dns record-sets transaction start \
   --zone="psc-service"

gcloud dns record-sets transaction add $externalip \
   --name=$externalip.nip.io \
   --ttl=300 \
   --type=A \
   --zone="psc-service"

gcloud dns record-sets transaction execute \
   --zone="psc-service"

15. Testar a conexão PSC do consumidor

Aguarde de 7 a 10 minutos antes de testar para permitir que o DNS público seja propagado.

No Cloud Shell

curl https://$externalip.nip.io -k

Também é possível testar no navegador inserindo https://<YOUR-EXTERNAL-IP>.nip.io no navegador ou no terminal de computador.

Precisamos ignorar os erros de SSL usando -k porque estamos usando certificados autoassinados.

RESULTADO ESPERADO

PSC Service

Se você estiver recebendo erros de SSL, verifique se configurou o commonName do certificado e/ou o DNS sanlist_list como <YOUR-EXTERNAL-IP>.nip.io.

16. Etapas de limpeza

Excluir componentes do laboratório em um único terminal do Cloud Shell

gcloud dns record-sets delete $externalip.nip.io --zone="psc-service" --type=A -q

gcloud dns managed-zones delete "psc-service" -q

gcloud compute forwarding-rules delete external-fr --global -q 

gcloud compute target-https-proxies delete psc-https-proxy -q

gcloud compute url-maps delete consumer-url-map --global -q

gcloud compute backend-services delete apache-pscneg-bes --global -q

gcloud compute network-endpoint-groups delete apache-psc-neg --region=$region -q

gcloud compute ssl-certificates delete consumer-service-cert --global -q

gcloud compute addresses delete external-psc-ip --global -q

gcloud compute networks subnets delete consumer-subnet --region $region -q

gcloud compute networks delete consumer-vpc -q

gcloud compute instances delete vm-client --zone=us-east4-a -q

gcloud compute service-attachments delete apache-service-attachment --region $region -q

gcloud compute forwarding-rules delete apache-fr --region $region -q

gcloud compute target-https-proxies delete https-proxy --region $region -q

gcloud compute url-maps delete producer-url-map --region $region -q

gcloud compute backend-services delete apache-bes --region $region -q

gcloud compute health-checks delete lb-apache-service-hc --region $region -q

gcloud compute addresses delete apache-service-ip --region $region -q

gcloud compute ssl-certificates delete producer-service-cert --region $region -q

gcloud compute instance-groups managed delete psc-service-mig --region $region -q

gcloud compute health-checks delete service-mig-healthcheck --global -q

gcloud compute instance-templates delete apache-service-template -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=network-producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute routers nats delete central-nat --router=central-cr --region $region -q

gcloud compute routers delete central-cr --region $region -q

gcloud compute networks subnets delete psc-nat-subnet --region $region -q

gcloud compute networks subnets delete service-subnet --region $region -q

gcloud compute networks subnets delete test-client-subnet --region us-east4 -q 

gcloud compute networks subnets delete central-proxy-subnet --region $region -q

gcloud compute networks delete producer-vpc -q

17. Parabéns!

Parabéns por concluir o codelab.

O que vimos

• Criar e configurar um back-end PSC associado ao balanceador de carga de aplicativo externo global
• Configurar um serviço da Web gerenciado pelo Apache e expô-lo como um serviço PSC usando um anexo de serviço
• Criar certificados SSL para encerrar SSL em balanceadores de carga de aplicativo internos e externos
• Configurar uma zona pública do Cloud DNS para acessar o serviço PSC