Private Service Connect: como usar controles de serviço HTTP(S) do consumidor para XLB global em serviços gerenciados

1. Introdução

O Private Service Connect permite que um produtor de serviços ofereça serviços a um consumidor de serviços. Uma rede VPC de produtor de serviços pode oferecer suporte a vários consumidores de serviço.

Há dois tipos de endpoints do Private Service Connect que podem se conectar a um serviço publicado:

  • Endpoint do Private Service Connect (com base em uma regra de encaminhamento)

Com esse tipo de endpoint, os consumidores se conectam a um endereço IP interno definido por eles. O Private Service Connect realiza a conversão de endereços de rede (NAT) para encaminhar a solicitação ao produtor de serviços.

  • Endpoint do Private Service Connect com controles de serviço HTTP(S) do consumidor (com base em um balanceador de carga HTTP(S) externo global)

Com esse tipo de endpoint, os consumidores se conectam a um endereço IP externo. O Private Service Connect usa um grupo de endpoints de rede para rotear a solicitação para o produtor de serviço.

Usar um balanceador de carga HTTP(S) externo global como ponto de aplicação da política tem os seguintes benefícios:

  • Você pode renomear serviços e mapeá-los para URLs de sua escolha.
  • É possível configurar o balanceador de carga para registrar todas as solicitações no Cloud Logging.
  • É possível usar certificados TLS gerenciados pelo cliente. ou gerenciados pelo Google.

Neste codelab, você vai aprender a criar um endpoint do Private Service Connect para controles de serviço HTTP(S) para consumidores usando o XLB global para acessar de forma particular um serviço em outra rede. Esse padrão de PSC pode ser feito usando um único projeto ou projetos separados. Neste laboratório, vamos usar um único projeto com duas VPCs separadas.

O que você vai aprender

  • Criar um endpoint do Private Service Connect com os controles de serviço HTTP(S) do consumidor usando o XLB global
  • Configure um serviço gerenciado que será exposto por meio de um anexo de serviço para aceitar conexões L7 XLB.
  • Crie um certificado SSL e configure um servidor da Web Apache para encerrar o TLS e aceitar o tráfego na porta 443.
  • Crie um PSC NEG.

O que é necessário

  • um projeto do Google Cloud;
  • Saber implantar instâncias e configurar componentes de rede.

2. Ambiente de teste

O ambiente que você vai criar vai consistir em um balanceador de carga HTTP(S) externo e um PSC NEG em uma VPC de consumidor. A VPC do produtor hospedará um serviço da Web Apache simples configurado com HTTPS. Você vai criar um serviço de back-end no serviço da Web Apache e enfrentá-lo com um balanceador de carga TCP interno configurado com um anexo de serviço PSC.

bbca972cf488ece.png

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.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • O Nome do projeto é o nome de exibição para os participantes do projeto. Ele é uma string de caracteres que não é usada pelas APIs do Google e pode ser atualizada a qualquer momento.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O Console do Cloud gera automaticamente uma string única, geralmente não importa o que seja. Na maioria dos codelabs, você precisará fazer referência ao ID do projeto, que geralmente é identificado como PROJECT_ID. Então, se você não gostar dele, gere outro ID aleatório ou crie um próprio e veja se ele está disponível. Em seguida, ele fica "congelado" depois que o projeto é criado.
  • Há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
  1. Em seguida, você precisará ativar o faturamento no Console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar cobranças além deste tutorial, siga as instruções de "limpeza" encontradas no final do codelab. 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:

55efc1aaa7a4d3ad.png

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:

7ffe5cbb04455448.png

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. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

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

Ative todos os serviços necessários

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

5. VPC do produtor, sub-rede, configuração de regras de firewall

Rede VPC

No Cloud Shell

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

Criar sub-redes

Uma sub-rede é necessária no lado do produtor para realizar a conversão de endereços de rede (NAT) para PSC. A finalidade é PRIVATE_SERVICE_CONNECT. Isso significa que essa sub-rede não pode ser usada para implantar cargas de trabalho.

No Cloud Shell

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

Vamos implantar duas sub-redes na VPC do produtor. A primeira a implantar o serviço do produtor e a outra em outra região para implantar uma client-vm para testar a conectividade com o serviço pelo acesso global no balanceador de carga TCP interno.

No Cloud Shell

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

No Cloud Shell

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

Criar o Cloud NAT

Um Cloud NAT é necessário para instalar os pacotes adequados para nossos serviços de produtor.

No Cloud Shell

gcloud compute routers create service-cr \
--region=$region --network=producer-vpc \
--asn=65501

No Cloud Shell

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

Criar regras de firewall

Neste laboratório, você usará o IAP para se conectar às instâncias criadas. A regra de firewall a seguir permitirá que você se conecte a instâncias por meio do IAP. Se preferir não usar o IAP, pule esta etapa. Em vez disso, adicione endereços IP públicos à instância e crie uma regra de firewall que permita a entrada de 0.0.0.0/0 na porta TCP 22.

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

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

No Cloud Shell

gcloud compute firewall-rules create allow-ssh-iap \
    --network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20

Como o tráfego do cliente é originado do balanceador de carga HTTP(S) externo global, é preciso criar uma regra de firewall para permitir o tráfego nos servidores de destino marcados que vão hospedar nosso serviço da Web. Também vamos abrir a regra de firewall da client-subnet para fazer testes.

No Cloud Shell

gcloud compute firewall-rules create allow-xlb-client \
  --network=producer-vpc \
  --direction=ingress \
  --allow=tcp:443 \
  --target-tags=psc-service \
  --source-ranges=130.211.0.0/22,35.191.0.0/16,10.0.1.0/24

Criar serviço da Web Apache

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

Criar modelo de instância

No Cloud Shell

gcloud compute instance-templates create producer-service-template \
    --network producer-vpc \
    --subnet service-subnet \
    --region $region \
    --no-address \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=psc-service \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    echo "PSC Service" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Criar verificação de integridade para o MIG

No Cloud Shell

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

Criar um grupo gerenciado de instâncias

No Cloud Shell

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

Configurar o SSL nos servidores da Web Apache

Em seguida, configure o SSL em cada um dos servidores da Web Apache. Para isso, vamos gerar um certificado e adicioná-lo à configuração do Apache.

A terminação SSL precisa ser configurada nos serviços de back-end porque o serviço precisa estar liderado por um balanceador de carga TCP/UDP (L4) interno para esse padrão de PSC específico. O balanceador de carga TCP/UDP interno não encerra o SSL na camada do balanceador de carga.

Comece usando SSH na primeira VM no MIG. A zona e o nome da VM serão alocados dinamicamente por ambiente. No console, navegue até Compute Engine > instâncias de VM para encontrar o nome e a zona das suas instâncias.

No Cloud Shell

gcloud compute ssh --zone "<YOUR_VM_ZONE>" "<YOUR_MIG_VM_1>"  --tunnel-through-iap --project $project

Em seguida, criaremos o certificado pelo OpenSSL. Você precisará preencher informações sobre país, estado, localidade, organização, nome da unidade organizacional, nome comum e endereço de e-mail. A única informação que você precisa preencher é o Nome comum, que deve ser um FQDN interno de sua escolha. Para este laboratório, escolha example.com.

No Cloud Shell

sudo openssl genrsa -out private-key-file.pem 2048

No Cloud Shell

cat <<'EOF' >config.txt
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
countryName               = Country Name (2 letter code)
stateOrProvinceName       = State or Province Name (full name)
localityName              = Locality Name (eg, city)
0.organizationName        = Organization Name (eg, company)
organizationalUnitName    = Organizational Unit Name (eg, section)
commonName                = Common Name (e.g. server FQDN or YOUR name)
emailAddress              = Email Address

[sans_list]
DNS.1                     = example.com

EOF

No Cloud Shell

sudo openssl req -new -key private-key-file.pem \
    -out csr.pem \
    -config config.txt

No Cloud Shell

sudo openssl x509 -req \
    -signkey private-key-file.pem \
    -in csr.pem \
    -out cert.cert \
    -extfile config.txt \
    -extensions extension_requirements \
    -days 10

Agora vamos atualizar as informações de configuração do Apache com os novos detalhes do certificado.

sudo vi /etc/apache2/sites-enabled/default-ssl.conf

Adicione uma linha em ServerAdmin que diz

ServerName example.com

Atualize o SSLCertificateFile e o SSLCertificateKeyFile o local do arquivo cert.cert e os locais de private-key-file.pem na VM. Veja um exemplo abaixo. Não se esqueça de atualizar <profile> pelo nome do diretório.

SSLCertificateFile  /home/<profile>/cert.cert

SSLCertificateKeyFile /home/<profile>/private-key-file.pem

Feche o editor e reinicie o Apache.

sudo a2enmod ssl
sudo systemctl restart apache2

Saia da instância e repita as mesmas etapas na outra instância no grupo gerenciado de instâncias.

6. Criar o serviço do produtor

Em seguida, vamos criar os componentes do balanceador de carga para o serviço.

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

No Cloud Shell

gcloud compute health-checks create https service-lb-healthcheck \
    --port=443 \
    --region=$region

Crie o serviço de back-end:

No Cloud Shell

 gcloud compute backend-services create psc-backend-service \
    --load-balancing-scheme=internal \
    --protocol=TCP \
    --region=$region \
    --health-checks=service-lb-healthcheck \
    --health-checks-region=$region

gcloud compute backend-services add-backend psc-backend-service \
--region=$region \
--instance-group=psc-service-mig

Crie a regra de encaminhamento. A regra de encaminhamento precisa ser configurada na porta 443 e com acesso global. Isso é necessário para que o padrão do PSC funcione.

No Cloud Shell

 gcloud compute forwarding-rules create producer-fr \
    --region=$region \
    --load-balancing-scheme=internal \
    --network=producer-vpc \
    --subnet=service-subnet \
    --address=10.0.0.100 \
    --ip-protocol=TCP \
    --ports=443 \
    --backend-service=psc-backend-service \
    --backend-service-region=$region \
    --allow-global-access

7. Testar o serviço

Antes de criar o anexo de serviço, vamos criar um cliente em uma região diferente para testar o balanceador de carga configurado com acesso global, bem como o serviço Apache configurado para encerrar o TLS.

No Cloud Shell

gcloud compute instances create vm-client \
    --zone=us-east4-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=client-subnet \
    --no-address

acessar a instância por SSH.

No Cloud Shell

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

Conecte-se pelo balanceador de carga para testar o serviço Apache.

curl https://example.com:443 -k --connect-to example.com:443:10.0.0.100:443

RESULTADO ESPERADO

PSC Service

8. Criar o anexo de serviço

No Cloud Shell

gcloud compute service-attachments create pscservice \
    --region=$region \
    --producer-forwarding-rule=producer-fr \
    --connection-preference=ACCEPT-AUTOMATIC \
    --nat-subnets=producer-nat-subnet

Anote o URI do anexo de serviço, porque você vai precisar dele na próxima etapa da configuração do endpoint. Para consegui-lo, execute o seguinte comando no Cloud Shell:

No Cloud Shell

gcloud compute service-attachments describe pscservice --region $region

Copie o URI que começa em /projects.

Exemplo: /projects/<YOUR_PROJECT_ID>/regions/us-central1/serviceAttachments/pscservice

9. Configuração da VPC e da sub-rede do consumidor

Rede VPC

No Cloud Shell

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

Criar sub-rede

No lado do consumidor, é necessária uma sub-rede onde o grupo de endpoints da rede (NEG) do Private Service Connect será implantado.

No Cloud Shell

gcloud compute networks subnets create psc-neg-subnet \
--network=consumer-vpc \
--region=$region \
--range=10.100.200.0/24 \
--purpose=private

10. Crie o endpoint do Private Service Connect e teste a conexão

Vamos seguir o processo de criação de um PSC NEG que será associado ao anexo de serviço recém-criado, anexar o PSC NEG a um serviço de back-end e associar o serviço de back-end a uma regra de encaminhamento.

Tenha à mão o URI do anexo de serviço que observamos na última etapa. Substitua o URL abaixo pelo seu URI.

No Cloud Shell

gcloud beta compute network-endpoint-groups create xlb-psc-neg \
--network-endpoint-type=private-service-connect \
--psc-target-service=projects/<PROJECT-ID>/regions/us-central1/serviceAttachments/pscservice \
--region=$region \
--network=consumer-vpc \
--subnet=psc-neg-subnet

Crie o endereço IP público do XLB e capture o endereço IP real atribuído para testes posteriores.

No Cloud Shell

gcloud compute addresses create xlb-psc-address \
--ip-version=IPv4 --global

gcloud compute addresses describe xlb-psc-address --format="get(address)" --global

Em seguida, vamos criar o endpoint do PSC que, neste caso, está em um balanceador de carga externo.

No Cloud Shell

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

No Cloud Shell

gcloud beta compute backend-services add-backend pscneg-backend-service \
--network-endpoint-group=xlb-psc-neg \
--network-endpoint-group-region=$region \
--global

No Cloud Shell

gcloud beta compute url-maps create xlb-psc-map \
--default-service=pscneg-backend-service \
--global

No Cloud Shell

gcloud beta compute target-http-proxies create psc-http-proxy \
--url-map=xlb-psc-map

No Cloud Shell

gcloud beta compute forwarding-rules create xlb-psc-fr \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network-tier=PREMIUM \
--address=xlb-psc-address \
--target-http-proxy=psc-http-proxy \
--ports=80 \
--global

Aguarde de 5 a 7 minutos e insira o endereço IP associado a xlb-psc-address na barra de endereço do seu navegador.

Se "Serviço PSC" for exibida, isso significa que você configurou a solução corretamente.

11. Etapas de limpeza

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

gcloud beta compute forwarding-rules delete xlb-psc-fr --global --quiet

gcloud beta compute target-http-proxies delete psc-http-proxy --quiet

gcloud beta compute url-maps delete xlb-psc-map --global --quiet

gcloud beta compute backend-services delete pscneg-backend-service --global --quiet

gcloud compute addresses delete xlb-psc-address --global --quiet

gcloud beta compute network-endpoint-groups delete xlb-psc-neg --region $region --quiet

gcloud compute networks subnets delete psc-neg-subnet --region $region --quiet

gcloud compute networks delete consumer-vpc --quiet

gcloud compute service-attachments delete pscservice --region $region --quiet

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

gcloud compute forwarding-rules delete producer-fr --region $region --quiet

gcloud compute backend-services delete psc-backend-service --region $region --quiet

gcloud compute health-checks delete service-lb-healthcheck --region $region --quiet

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

gcloud compute health-checks delete psc-service-mig-healthcheck --region $region --quiet

gcloud compute instance-templates delete producer-service-template --quiet

gcloud compute firewall-rules delete allow-xlb-client --quiet

gcloud compute firewall-rules delete allow-ssh-iap --quiet

gcloud compute routers nats delete service-nat-gw –router service-cr --region $region --quiet

gcloud compute routers delete service-cr --region $region --quiet

gcloud compute networks subnets delete client-subnet --quiet

gcloud compute networks subnets delete service-subnet --quiet

gcloud compute networks subnets delete producer-nat-subnet --quiet

gcloud compute networks delete producer-vpc --quiet

12. Parabéns!

Parabéns por concluir o codelab.

O que vimos

  • Criar um endpoint do Private Service Connect com os controles de serviço HTTP(S) do consumidor usando o XLB global
  • Configure um serviço gerenciado que será exposto por meio de um anexo de serviço para aceitar conexões L7 XLB.
  • Crie um certificado SSL e configure um servidor da Web Apache para encerrar o TLS e aceitar o tráfego na porta 443.
  • Crie um PSC NEG.