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 maneira particular a um consumidor de serviços. O Private Service Connect oferece os seguintes benefícios:

  • Uma rede VPC de produtor de serviços pode oferecer suporte a 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 encaminhar a solicitação ao 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 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) por meio de um anexo de serviço
  • Criar um ambiente do consumidor
  • Criar uma regra de encaminhamento na rede do consumidor
  • Validar o acesso do consumidor
  • Ativar o controle de acesso de políticas
  • Usar uma regra de firewall de saída para bloquear o acesso a uma regra de encaminhamento do consumidor

O que é necessário

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

2. Benefícios do Private Service Connect

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

Melhor controle do espaço IP privado

  • Como consumidor de serviço, você pode controlar o endereço IP particular usado para se conectar ao serviço gerenciado que gostaria de acessar.
  • Como consumidor de serviço, você não precisa se preocupar em reservar intervalos de endereços IP particulares para serviços de back-end que são consumidos na VPC. Você só precisa 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 consumidor. Os consumidores com intervalos de sub-redes sobrepostos não são mais um problema.
  • Como provedor de serviços, é possível escalonar seu serviço para quantas instâncias de VM forem necessárias, sem precisar entrar em contato com o consumidor para solicitar mais endereços IP.

Mais segurança e isolamento

  • Como consumidor de serviço, somente você pode iniciar a comunicação com o produtor. Essa conectividade unidirecional simplifica consideravelmente 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 alterar suas regras de firewall com base nos intervalos de sub-redes da VPC do consumidor. Basta criar regras de firewall para o intervalo de endereços IP do NAT configurado para seu serviço.

Melhor escalonabilidade

  • O PSC permite um design altamente escalonável ao oferecer suporte a milhares de consumidores e permite que os produtores de serviços ofereçam serviços altamente escalonáveis de um ou vários locatários.
  • Como consumidor de serviço usando o Private Service Connect, você pode 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 os endpoints do Private Service Connect para consumir serviços que estão fora da sua rede VPC. Os consumidores de serviço 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 da regra de encaminhamento.

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

Metas

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

  • Um pacote de APIs:
  • 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 a um serviço de um produtor de serviços, você precisa do anexo de serviço do 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) de endereços IP de consumidores. Em seguida, você cria 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 Private Service Connect.

Quando uma solicitação é enviada de uma rede VPC de consumidor, o endereço IP de origem do consumidor é convertido com 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 do endereço IP da conexão do consumidor, consulte Como visualizar as informações de conexão do consumidor.

Elas 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 entrada do consumidor.

A sub-rede do Private Service Connect precisa conter pelo menos um endereço IP para cada 63 VMs de consumidor. Assim,cada VM de consumidor recebe 1.024 tuplas de origem para 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ços cria um anexo de serviço que se refere à regra de encaminhamento do balanceador de carga do serviço.
  • Para acessar um serviço, o 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 automaticamente conexões para todos os projetos: qualquer consumidor de serviço pode configurar um endpoint e se conectar ao serviço automaticamente.
  • Aceitar conexões para os projetos selecionados: os consumidores de serviço configuram um endpoint para se conectar ao serviço, e o produtor de serviços aceita ou rejeita as solicitações de conexão.

Requisitos e limitações

  • Aplicam-se limitações ao Private Service Connect.
  • É possível criar um anexo de serviço nas versões 1.21.4-gke.300 e posteriores 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 é mapeado para o anexo de serviço do produtor (serviço publicado).

1ce5607c0c56d77d.jpeg

Agora vamos conhecer a rede de produtores. A rede dos produtores não tem um mapeamento para a rede dos consumidores. Em vez disso, ela contém um anexo de serviço (serviço publicado) que o consumidor usa para serviços. O anexo de serviço do produtor é exposto por um ILB (serviço publicado) de entrada do GKE, permitindo a comunicação com os pods do GKE e aplicativos associados.

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

Elas 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 entrada do consumidor.

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

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 requer dois projetos, embora não seja um requisito para o PSC. Observe as referências para dar suporte a um ou vários projetos.

Projeto único: atualizar o projeto para oferecer suporte às redes 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 auxiliar a 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

Observe a seguinte 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 

Crie a sub-rede do 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)

É preciso criar uma ou mais sub-redes dedicadas para uso 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 as 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

Aplicar o manifesto ao cluster pelo 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

Aplicar o manifesto ao cluster pelo Cloud Shell

kubectl apply -f my-service.yaml

Criar ServiceAttachment

O manifesto a seguir descreve um ServiceAttachment que expõe o serviço que você criou 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

Aplicar o manifesto ao cluster pelo 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. Você pode usar a aprovação automática de projetos com ACCEPT_AUTOMATIC ou a aprovação explícita de projetos 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-redes a serem usados no 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 são disponibilizados nas solicitações. Esse campo é opcional e o padrão será falso se não for fornecido.
  • consumerAllowList: a lista de projetos do consumidor 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

É possível visualizar os detalhes de um ServiceAttachment usando o seguinte comando no Cloud Shell

kubectl describe serviceattachment emoji-sa

Ver o ILB do GKE L4

No console do Cloud, acesse Serviços de rede → Balanceamento de carga → Front-ends

Identifique o endereço IP do front-end que se alinha à sub-rede do nó 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, acesse Network Services → Private Service Connect → Serviços publicados

Identifique o serviço com a rede usada no laboratório, gke-producer-l4-vpc,, confira a captura de tela abaixo. No entanto, os valores de serviço e destino podem ser diferentes.

5a00836ee514b918.png

Clique no nome do serviço para acessar a tela abaixo e observe os detalhes do anexo de serviço preenchidos nas Informações básicas. Além disso, observe "Projetos conectados" está vazio, pois o consumidor ainda não se registrou no serviço. ACEITAR e REJECT permanecerão esmaecidos porque a opção 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 a rede VPC dos 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 é realizada por meio do anexo de serviço definido na rede dos consumidores.

O codelab requer dois projetos, embora não seja um requisito para o PSC. Observe as referências para dar suporte a um ou vários projetos.

Projeto único: atualizar o projeto para oferecer suporte às redes 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 à rede 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
echo $consumerproject

Rede VPC

No Cloud Shell

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

Crie uma sub-rede para 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

Crie 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

Crie 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 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 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 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 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 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. Vamos inserir o valor armazenado em "target-service-attach". .

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

Usaremos CURL e registros de firewall para validar a comunicação do consumidor e do 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

Nas VPCs de consumidor, use o shell do Cloud para identificar a regra de encaminhamento e o IP estático

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

Saída abaixo: usaremos 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

Visualizar o serviço conectado

No console do Cloud, acesse Network Services → Private Service Connect → Endpoints conectados e exibir 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, abra uma nova guia clicando no botão +

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 em relação ao endereço IP 10.0.60.100 da regra de encaminhamento

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, abra uma nova guia clicando no botão +

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

Como usar a Análise de registros valida a regra de firewall "vpc-consumner-psc" captura o fluxo entre a instância da VM e o IP estático

  1. No console do Cloud, identifique a geração de registros de operações → a Análise 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 mostram os itens a seguir por captura de tela fornecida

23e427b3060473.png

  1. Expanda o registro (jsonPayload → Conexão) e identifique a saída fornecida abaixo. Anote o 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 da instância da VM. A disposição é permitida.

2669743fd1f1cb0d.png

15. Validação: produtor

afe738fc869f0d6e.png

No projeto do Producers, 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 e o status de consumidor conectado, conforme ilustrado abaixo

15966d47423ebc5f.png

16. Restringir o acesso a um serviço publicado

1f3c90f1e139e906.png

Até agora, confirmamos que ambas as 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 todas as saídas, mas nega todo o tráfego do Ingress. Nas etapas a seguir, vamos criar uma regra de firewall com base em uma tag de rede "google2" definida anteriormente usada ao criar a instância de consumer-instance-2 para negar o acesso ao serviço publicado.

7fa2cda1dfec33a.png

Abra uma nova guia do Cloud Shell clicando em + 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 expirar, você precisará abrir um novo Cloud Shell e fazer 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

Usar a Análise de registros para validar a regra de firewall "psc-endpoint-deny-egress" captura o fluxo entre a instância de VM e o IP estático

  1. No console do Cloud, identifique a geração de registros de operações → a Análise 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:psc-endpoint-deny-egress")

  1. Os resultados da consulta mostram os itens a seguir por captura de tela fornecida

83b4fc7348ac93cd.png

  1. Expanda o registro e identifique a saída fornecida abaixo. Anote o dest_ip: 10.0.60.100 é o IP TCP STATIC 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

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

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

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

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) por meio de um anexo de serviço
  • Criar um ambiente do consumidor
  • Criar uma regra de encaminhamento na rede do consumidor
  • Validar o acesso do consumidor
  • Ativar o controle de acesso de políticas
  • Usou uma regra de firewall de saída para bloquear o acesso a uma regra de encaminhamento do consumidor