Como usar o Private Service Connect para publicar e consumir serviços com o GKE

1. Introdução

O Private Service Connect permite que um produtor de serviços ofereça serviços de modo particular a um consumidor de serviço. O Private Service Connect oferece os seguintes benefícios:

  • Uma rede VPC de produtor de serviços é compatível com mais de um consumidor de serviço.
  • Cada consumidor se conecta ao endereço IP interno definido por ele. O Private Service Connect realiza a conversão de endereços de rede (NAT) para rotear a solicitação para o produtor de serviços.

45b90d50690dd111.png

Figura 2. O Private Service Connect usa endpoints e anexos de serviço para permitir que os consumidores de serviços enviem tráfego da rede VPC do consumidor para os serviços na rede VPC do produtor de serviços (clique para ampliar).

O que você vai aprender

  • Benefícios do Private Service Connect
  • Principais conceitos para consumidores de serviço
  • Principais conceitos para produtores de serviços
  • Criar um ambiente de produtor
  • Expor o serviço (ambiente do produtor) usando um anexo de serviço
  • Criar um ambiente de consumidor
  • Criar uma regra de encaminhamento na rede consumidora
  • Validar o acesso do consumidor
  • Ativar o controle de acesso à política
  • Usar uma regra de firewall de saída para bloquear o acesso a uma regra de encaminhamento do consumidor

O que é necessário

  • Conhecimento sobre como implantar clusters e serviços do GKE
  • Conhecimento sobre balanceadores de carga internos
  • Saber criar VPCs em dois projetos
  • Capacidade de criar um cluster do GKE

2. Benefícios do Private Service Connect

Com o PSC, você tem vários benefícios em comparação com o uso do peering de VPC:

Melhor controle do espaço de IP particular

  • Como consumidor de serviços, você pode controlar o endereço IP privado usado para se conectar ao serviço gerenciado que quer acessar.
  • Como consumidor de serviços, não é necessário se preocupar em reservar intervalos de endereços IP particulares para serviços de back-end consumidos na sua VPC. Basta escolher um endereço IP da sua própria sub-rede para se conectar aos serviços do produtor.
  • Como produtor de serviços, você pode implantar um modelo multilocatário, em que sua VPC contém serviços que atendem a várias VPCs de consumidores. Os consumidores com intervalos de sub-redes sobrepostos não são mais um problema.
  • Como provedor de serviços, você pode escalonar seu serviço para quantas instâncias de VM forem necessárias, sem precisar entrar em contato com o consumidor para pedir mais endereços IP.

Segurança e isolamento aprimorados

  • Como consumidor de serviços, somente você pode iniciar a comunicação com o produtor de serviços. Essa conectividade unidirecional simplifica muito a configuração do firewall, mas também reduz o risco de tráfego não autorizado do produtor de serviços.
  • Como produtor de serviços, você não precisa mudar as regras de firewall com base nos intervalos de sub-redes na VPC do consumidor. Basta criar regras de firewall para o intervalo de endereços IP NAT configurado em seu serviço.

Melhor escalonabilidade

  • O PSC permite um design altamente escalonável, oferecendo suporte a milhares de consumidores e permitindo que os produtores de serviços ofereçam serviços multitenant ou de locatário único altamente escalonáveis.
  • Como consumidor de serviços que usa o Private Service Connect, é possível criar recursos conforme necessário na sua VPC. A escala disso não é afetada pelo número de recursos criados na VPC do produtor.

3. Principais conceitos para consumidores de serviço

É possível usar endpoints do Private Service Connect para consumir serviços que estão fora da sua rede VPC. Os consumidores de serviços criam endpoints do Private Service Connect que se conectam a um serviço de destino.

Endpoints

Use os endpoints do Private Service Connect para se conectar a um serviço de destino. Os endpoints têm um endereço IP interno na rede VPC e são baseados no recurso de regra de encaminhamento.

Você envia o tráfego ao endpoint, que o encaminha para destinos fora da sua rede VPC.

Destinos

Os endpoints do Private Service Connect têm um destino, que é o serviço a que você quer se conectar:

  • Um pacote de API:
  • Todas as APIs: a maioria das APIs do Google
  • VPC-SC: APIs compatíveis com VPC Service Controls
  • Um serviço publicado em outra rede VPC. O serviço pode ser gerenciado pela organização ou por terceiros.

Serviço publicado

Para conectar seu endpoint ao serviço de um produtor de serviços, você precisa do anexo de serviço para o serviço. O URI do anexo de serviço tem este formato: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

4. Principais conceitos para produtores de serviços

Para disponibilizar um serviço aos consumidores, crie uma ou mais sub-redes dedicadas para usar na conversão de endereços de rede (NAT) dos endereços IP dos consumidores. Em seguida, crie um anexo de serviço que se refere a essas sub-redes.

Sub-redes do Private Service Connect

Para expor um serviço, o produtor de serviços primeiro cria uma ou mais sub-redes com a finalidade do Private Service Connect.

Quando uma solicitação é enviada de uma rede VPC do consumidor, o endereço IP de origem do consumidor é convertido usando NAT de origem (SNAT) para um endereço IP selecionado de uma das sub-redes do Private Service Connect.

Se você quiser manter as informações de endereço IP de conexão do consumidor, consulte Como visualizar informações de conexão do consumidor.

Essas sub-redes não podem ser usadas para recursos como instâncias de VM ou regras de encaminhamento. As sub-redes são usadas apenas para fornecer endereços IP para SNAT de conexões de consumidor recebidas.

A sub-rede do Private Service Connect precisa conter pelo menos um endereço IP para cada 63 VMs pessoais de consumidor. Assim,cada VM de consumidor recebe 1.024 tuplas de origem para a conversão de endereços de rede.

O tamanho mínimo de uma sub-rede do Private Service Connect é /24.

Anexos de serviço

Os produtores de serviços expõem o serviço deles utilizando um anexo.

  • Para expor um serviço, um produtor de serviço cria um anexo de serviço que se refere à regra de encaminhamento do balanceador de carga do serviço.
  • Para acessar um serviço, um consumidor de serviço cria um endpoint que se refere ao anexo de serviço.

Preferências de conexão

Ao criar um serviço, você escolhe como disponibilizá-lo. Existem duas opções:

  • Aceitar conexões automaticamente para todos os projetos: qualquer consumidor de serviço pode configurar um endpoint e se conectar ao serviço automaticamente.
  • Aceitar conexões para projetos selecionados: os consumidores de serviço configuram um endpoint para se conectar ao serviço, e o produtor de serviço aceita ou rejeita as solicitações de conexão.

Requisitos e limitações

  • As limitações do Private Service Connect se aplicam.
  • É possível criar um anexo de serviço nas versões 1.21.4-gke.300 e mais recentes do GKE.
  • Não é possível usar a mesma sub-rede em várias configurações de anexos do serviço.
  • Crie um serviço do GKE que use um balanceador de carga TCP/UDP interno.

5. Ambiente de teste

A rede do consumidor consiste em um endereço IP estático usado para originar solicitações ao produtor de serviços, além do anexo de serviço de destino que mapeia para o anexo de serviço do produtor (serviço publicado).

1ce5607c0c56d77d.jpeg

Agora, vamos dar uma olhada na rede de produtores. Observe como a rede de produtores não tem um mapeamento para a rede de consumidores. Em vez disso, ela contém um anexo de serviço (serviço publicado) usado pelo consumidor para serviços. O anexo de serviço do produtor é exposto por um ILB L4 de entrada do GKE (serviço publicado), permitindo a comunicação com os pods do GKE e os aplicativos associados.

A sub-rede NAT é usada quando uma solicitação é enviada de uma rede VPC do consumidor. O endereço IP de origem do consumidor é convertido usando NAT de origem (SNAT) para um endereço IP selecionado de uma das sub-redes do Private Service Connect.

Essas sub-redes não podem ser usadas para recursos como instâncias de VM ou regras de encaminhamento. As sub-redes são usadas apenas para fornecer endereços IP para SNAT de conexões de consumidor recebidas.

Para saber mais sobre o L4ILB para o Private Service Connect do GKE e ter acesso direto ao conteúdo usado para fazer este laboratório, consulte o seguinte.

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.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.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 GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

bce75f34b2c53987.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:

f6ef2b5f13479f3a.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.

6. Antes de começar

O codelab exige dois projetos, mas isso não é um requisito para o PSC. Observe as referências para oferecer suporte a um ou vários projetos.

Projeto único: atualize o projeto para oferecer suporte à rede do produtor e do consumidor

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
consumerproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Vários projetos: atualize o projeto para oferecer suporte à rede do produtor

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
echo $prodproject

Observação sobre a convenção de código de cores:

f251ebb137e37136.png

7. Criar rede VPC de produtores

afe738fc869f0d6e.png

Rede VPC

No Cloud Shell

gcloud compute networks create gke-producer-l4-vpc --project=$prodproject --subnet-mode=custom 

Criar uma sub-rede de cluster do GKE

No Cloud Shell

gcloud compute networks subnets create node-subnet1 --project=$prodproject --range=192.168.10.0/24 --network=gke-producer-l4-vpc --region=us-central1 --secondary-range=pod=10.10.10.0/24,service=10.10.20.0/24 --enable-private-ip-google-access

Criar cluster do GKE

No Cloud Shell

gcloud container clusters create gke-psc-l4 \
    --release-channel=rapid \
    --enable-ip-alias \
    --zone=us-central1-a \
    --network gke-producer-l4-vpc \
    --num-nodes 1 \
    --subnetwork node-subnet1 \
    --cluster-secondary-range-name pod \
    --services-secondary-range-name service

Criar uma sub-rede para o Private Service Connect (sub-rede NAT)

Crie uma ou mais sub-redes dedicadas para usar com o Private Service Connect. Se você estiver usando o console do Google Cloud para publicar um serviço, poderá criar as sub-redes durante esse procedimento.

Para informações sobre sub-redes do Private Service Connect, consulte Sub-redes do Private Service Connect.

No Cloud Shell

gcloud beta compute networks subnets create gke-nat-subnet \
    --project $prodproject \
    --network gke-producer-l4-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

8. Implantar uma carga de trabalho e serviços

O manifesto a seguir descreve uma implantação que executa uma imagem de contêiner de aplicativo da Web de amostra. Salve o manifesto como my-deployment.yaml no Cloud Shell.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Aplique o manifesto ao cluster no Cloud Shell

kubectl apply -f my-deployment.yaml

Criar um serviço

O manifesto a seguir descreve um serviço que cria um balanceador de carga TCP/UDP interno na porta TCP 8080. Salve o manifesto como my-service.yaml no Cloud Shell.

apiVersion: v1
kind: Service
metadata:
  name: gke-l4-psc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: psc-ilb
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Aplique o manifesto ao cluster no Cloud Shell

kubectl apply -f my-service.yaml

Criar ServiceAttachment

O manifesto a seguir descreve um ServiceAttachment que expõe o serviço criado para os consumidores de serviço. Salve o manifesto como my-psc.yaml no Cloud Shell.

apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
 name: emoji-sa
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - gke-nat-subnet
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: gke-l4-psc

Aplique o manifesto ao cluster no Cloud Shell

kubectl apply -f my-psc.yaml

O ServiceAttachment tem os seguintes campos:

  • connectionPreference:a preferência de conexão que determina como os clientes se conectam ao serviço. É possível usar a aprovação automática do projeto usando ACCEPT_AUTOMATIC ou a aprovação explícita do projeto usando ACCEPT_MANUAL. Para mais informações, consulte Como publicar serviços usando o Private Service Connect.
  • natSubnets: uma lista de nomes de recursos de sub-rede a serem usados para o anexo de serviço.
  • proxyProtocol:quando definido como verdadeiro, o IP de origem do consumidor e o ID da conexão do Private Service Connect estão disponíveis nas solicitações. Esse campo é opcional e o padrão será falso se não for fornecido.
  • consumerAllowList:a lista de projetos de consumidores que têm permissão para se conectar ao ServiceAttachment. Esse campo só pode ser usado quando connectionPreference é ACCEPT_MANUAL. Para mais informações sobre esse campo e outras opções, consulte Como publicar serviços usando o Private Service Connect.

Validação do produtor

Como visualizar os detalhes do anexo de serviço

Para conferir os detalhes de um ServiceAttachment, use o seguinte comando do Cloud Shell:

kubectl describe serviceattachment emoji-sa

Conferir o ILB L4 do GKE

No console do Cloud, navegue até Serviços de rede > Balanceamento de carga > Front-ends.

Identifique o endereço IP de front-end que se alinha à sub-rede de nós definida anteriormente 192.168.10.0/24. Observe a captura de tela abaixo. Seu endereço IP pode ser diferente.

ed7a25ed4774977b.png

Ver o serviço publicado

No console do Cloud, navegue até Serviços de rede → Private Service Connect → Serviços publicados.

Identifique o serviço com a rede usada no laboratório, gke-producer-l4-vpc,. Consulte a captura de tela abaixo, embora os valores de "Service" e "Target" possam ser diferentes.

5a00836ee514b918.png

Clique no nome do serviço que leva à tela abaixo e observe os detalhes do anexo de serviço preenchidos em "Informações básicas". Além disso, observe que "Projetos conectados" está vazio porque o consumidor ainda não se registrou no serviço. ACEITAR e REJEITAR vão permanecer esmaecidos porque a Preferência de conexão está definida como "ACCEPT_AUTOMATICALLY". Essa opção pode ser alterada a qualquer momento para "ACCEPT_MANUAL" modificando o YAML do anexo de serviço (my-psc.yaml).

497f5f43920018c0.png

e246063a23771273.png

9. Criar rede VPC de consumidores

1f3c90f1e139e906.png

Na seção a seguir, a VPC do consumidor é configurada em um projeto separado. A comunicação entre as redes do consumidor e do produtor é feita pelo anexo de serviço definido na rede do consumidor.

O codelab exige dois projetos, mas isso não é um requisito para o PSC. Observe as referências para oferecer suporte a um ou vários projetos.

Projeto único: atualize o projeto para oferecer suporte à rede do produtor e do consumidor

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
prodproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Vários projetos: atualize o projeto para oferecer suporte a uma rede de consumidores

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
echo $consumerproject

Rede VPC

No Cloud Shell

gcloud compute networks create vpc-demo-consumer --project=$consumerproject --subnet-mode=custom

Criar uma sub-rede para o PSC

No Cloud Shell

gcloud compute networks subnets create consumer-subnet --project=$consumerproject  --range=10.0.60.0/24 --network=vpc-demo-consumer --region=us-central1

Criar uma sub-rede para instâncias de VM

No Cloud Shell

gcloud compute networks subnets create consumer-subnet-vm --project=$consumerproject  --range=10.0.70.0/24 --network=vpc-demo-consumer --region=us-central1

Criar um endereço IP estático para acessar o serviço publicado

No Cloud Shell

gcloud compute addresses create vpc-consumer-psc --region=us-central1 --subnet=consumer-subnet --addresses 10.0.60.100

Criar regras de firewall

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 de VM que você quer acessar 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 firewall-rules create psclab-iap-consumer --network vpc-demo-consumer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

Embora não seja necessário para o PSC, crie uma regra de firewall de saída para monitorar o tráfego do PSC do consumidor para o anexo de serviço dos produtores.

gcloud compute --project=$consumerproject firewall-rules create vpc-consumer-psc --direction=EGRESS --priority=1000 --network=vpc-demo-consumer --action=ALLOW --rules=all --destination-ranges=10.0.60.0/24 --enable-logging

10. Criar a instância de teste do consumidor 1

No Cloud Shell

gcloud compute instances create consumer-instance-1 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.10 --no-address --subnet=consumer-subnet-vm --tags=google1 --image-family=debian-10 --image-project=debian-cloud

11. Criar a instância de teste do consumidor 2

No Cloud Shell

gcloud compute instances create consumer-instance-2 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.20 --no-address --subnet=consumer-subnet-vm --tags=google2 --image-family=debian-10 --image-project=debian-cloud

12. Criar um anexo de serviço

Em uma etapa anterior, você copiou a string do anexo de serviço do produtor em um local seguro. Agora, vamos inserir o valor armazenado no campo "target-service-attachment".

7abaccc4e24f1ef7.png

No Cloud Shell

gcloud compute forwarding-rules create vpc-consumer-psc-fr --region=us-central1 --network=vpc-demo-consumer --address=vpc-consumer-psc --target-service-attachment=yoursavedproducerserviceattachment

13. Validação: consumidor

Vamos usar o CURL e os registros de firewall para validar a comunicação entre consumidor e produtor.

No projeto do consumidor, os endereços IP estáticos são usados para originar a comunicação com o produtor. Esse mapeamento do endereço IP estático para a regra de encaminhamento do consumidor é validado executando a seguinte sintaxe.

1f3c90f1e139e906.png

No shell de uso do Cloud das VPCs de consumidor, identifique a regra de encaminhamento e o IP estático.

gcloud compute forwarding-rules describe vpc-consumer-psc-fr --region us-central1

Na saída abaixo, vamos usar 10.0.60.100 para alcançar o produtor em uma etapa posterior.

IPAddress: 10.0.60.100
creationTimestamp: '2021-09-30T21:13:54.124-07:00'
id: '3564572805904938477'
kind: compute#forwardingRule
labelFingerprint: 42WmSpB8rSM=
name: vpc-consumer-psc-fr
network: https://www.googleapis.com/compute/v1/projects/deepakmichaelstage/global/networks/vpc-demo-consumer
networkTier: PREMIUM
pscConnectionId: '36583161500548196'
pscConnectionStatus: ACCEPTED

Ver o serviço conectado

No console do Google Cloud, navegue até Serviços de rede → Private Service Connect → Endpoints conectados e veja o endpoint recém-criado.

206bc00297aaa260.png

Vamos fazer login em consumer-instance-1 e testar o acesso ao serviço publicado do produtor.

No Cloud Shell, clique em + para abrir uma nova guia.

81f3210b29faebd3.png

No Cloud Shell, faça o seguinte:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-1" --project "$projectname"

Depois de fazer login na instância consumer-instance-1, execute um curl no endereço IP da regra de encaminhamento 10.0.60.100.

No Cloud Shell, faça o seguinte:

user@consumer-instance-1:~$ curl 10.0.60.100

Exemplo de saída

user@consumer-instance-1:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodprojectid.internal",
  "pod_name": "psc-ilb-588887dfdb-w7tbr",
  "pod_name_emoji": "🤷",
  "project_id": "prodorijectid",
  "timestamp": "2021-10-01T17:43:37",
  "zone": "us-central1-a"

Vamos fazer login em consumer-instance-2 e testar o acesso ao serviço publicado do produtor.

No Cloud Shell, clique em + para abrir uma nova guia.

81f3210b29faebd3.png

No Cloud Shell, faça o seguinte:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

No Cloud Shell, faça o seguinte:

user@consumer-instance-2:~$ curl 10.0.60.100

Exemplo de saída

deepakmichael@consumer-instance-2:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodproject.internal",
  "pod_name": "psc-ilb-588887dfdb-4jdql",
  "pod_name_emoji": "🧑🏿",
  "project_id": "prodproject",
  "timestamp": "2021-10-01T17:49:51",
  "zone": "us-central1-a"

14. Geração de registros de firewall: validação alocada

Usando a Análise de registros, valide se a regra de firewall "vpc-consumner-psc" está capturando o fluxo entre a instância da VM e o IP estático.

  1. No console do Cloud, identifique o Logging do pacote de operações → Explorador de registros.
  2. No campo "Consulta", atualize a entrada abaixo com yourconsumerproject e selecione "Executar consulta".

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:vpc-consumer-psc")

  1. Os resultados da consulta fornecem o seguinte por captura de tela:

23e427b3060473.png

  1. Expanda o registro (jsonPayload → Connection) e identifique a saída fornecida abaixo. Observe que dest_ip: 10.0.60.100 é o IP TCP estático usado para acessar o serviço do produtor, e src_ip: 10.0.70.10 ou 10.0.70.20 são os endereços IP das instâncias de VM. A disposição é permitida.

2669743fd1f1cb0d.png

15. Validação: produtor

afe738fc869f0d6e.png

No projeto de produtores, verifique se o anexo de serviço está conectado. Acesse Serviços de rede → Private Service Connect → Serviços publicados

89ded87a63888f60.png

Clique no serviço para revelar o projeto do consumidor conectado e o status, conforme ilustrado abaixo.

15966d47423ebc5f.png

16. Restringir o acesso a um serviço publicado

1f3c90f1e139e906.png

Até agora, confirmamos que as duas instâncias têm acesso aos serviços publicados. Vamos criar uma regra de firewall de saída para negar o acesso de consumer-instance-2 ao serviço publicado.

Por padrão, o GCP permite toda a saída, mas nega todo o tráfego de entrada. Nas etapas a seguir, vamos criar uma regra de firewall com base em uma tag de rede definida anteriormente, "google2", usada ao criar consumer-instance-2 para negar o acesso ao serviço publicado.

7fa2cda1dfec33a.png

Abra uma nova guia do Cloud Shell clicando em + e execute a seguinte regra de firewall no Cloud Shell:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute --project=$projectname firewall-rules create psc-endpoint-deny-egress --direction=EGRESS --priority=999 --network=vpc-demo-consumer --action=DENY --rules=all --destination-ranges=10.0.60.100/32 --target-tags=google2 --enable-logging

Agora, vamos testar se consumer-instance-2 consegue acessar o serviço publicado. Se a sessão expirou, abra um novo Cloud Shell + e faça login na VM conforme detalhado abaixo.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

No Cloud Shell, faça o seguinte:

user@consumer-instance-2:~$ curl 10.0.60.100

Exemplo de saída

user@consumer-instance-2:~$ curl 10.0.60.100
curl: (7) Failed to connect to 10.0.60.100 port 80: Connection timed out

Geração de registros de firewall: validação negada

Usando a Análise de registros, valide se a regra de firewall "psc-endpoint-deny-egress" está capturando o fluxo entre a instância de VM e o IP estático.

  1. No console do Cloud, identifique o Logging do pacote de operações → Explorador de registros.
  2. No campo "Consulta", atualize a entrada abaixo com seuconsumerproject e selecione "Executar consulta".

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:psc-endpoint-deny-egress")

  1. Os resultados da consulta fornecem o seguinte por captura de tela:

83b4fc7348ac93cd.png

  1. Expanda o registro e identifique a saída fornecida abaixo. Observe o dest_ip: 10.0.60.100 é o IP TCP estático e src_ip: 10.0.70.10 ou 10.0.70.20 são os endereços IP da instância de VM. A disposição é "Negada".

a344f75f67590655.png

17. Etapas de limpeza

Etapas de limpeza da rede do produtor

afe738fc869f0d6e.png

Em um único Cloud Shell no terminal do projeto produtor, exclua os componentes do laboratório.

gcloud container clusters delete gke-psc-l4 --region us-central1-a --quiet

gcloud compute networks subnets delete gke-nat-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete node-subnet1 --region=us-central1 --quiet

gcloud compute networks delete gke-producer-l4-vpc --quiet

1f3c90f1e139e906.png

Etapas de limpeza da rede do consumidor

Em um único shell do Cloud no terminal do projeto do consumidor, exclua os componentes do laboratório.

gcloud compute instances delete consumer-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete consumer-instance-2 --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete vpc-consumer-psc-fr --region=us-central1 --quiet

gcloud compute addresses delete vpc-consumer-psc --region=us-central1 --quiet

gcloud compute firewall-rules delete psclab-iap-consumer --quiet

gcloud compute networks subnets delete consumer-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete consumer-subnet-vm --region=us-central1 --quiet

gcloud compute firewall-rules delete vpc-consumer-psc --quiet

gcloud compute firewall-rules delete psc-endpoint-deny-egress --quiet

gcloud compute networks delete vpc-demo-consumer --quiet

18. Parabéns!

Parabéns por concluir o codelab.

O que vimos

  • Benefícios do Private Service Connect
  • Principais conceitos para consumidores de serviço
  • Principais conceitos para produtores de serviços
  • Criar um ambiente de produtor
  • Expor o serviço (ambiente do produtor) usando um anexo de serviço
  • Criar um ambiente de consumidor
  • Criar uma regra de encaminhamento na rede consumidora
  • Validar o acesso do consumidor
  • Ativar o controle de acesso à política
  • Usou uma regra de firewall de saída para bloquear o acesso a uma regra de encaminhamento do consumidor