Como proteger o tráfego de entrada do Cloud Run

1. Visão geral

Este laboratório mostra como restringir o acesso a um serviço do Cloud Run e permitir apenas solicitações de uma carga de trabalho em execução no local ou na VPC do seu projeto. Há duas camadas de controle de acesso que podem ser usadas: configurações de entrada e políticas do Identity and Access Management (IAM).

Configurações de entrada

As configurações de entrada permitem filtrar solicitações com base na origem da rede (interna ou externa). Por padrão, todas as solicitações podem ser transmitidas, incluindo aquelas da Internet pública.

Política de IAM

As políticas do IAM permitem filtrar solicitações com base na identidade do remetente e são normalmente usadas para autenticar solicitações de serviço a serviço.

Neste laboratório, você vai aprender como e quando usar as configurações de entrada.

Hosts locais se conectam pela VPC

Neste laboratório, vamos simular uma carga de trabalho no local. Para conectar um host local ao Cloud Run, configure o Acesso privado do Google para hosts locais. Isso inclui a configuração de um gateway do Cloud VPN na rede VPC, conforme mostrado abaixo.

Como simular uma carga de trabalho local usando um servidor de salto na VPC

Neste laboratório, você vai simular o envio de solicitações de um host no local enviando solicitações de uma máquina virtual do Compute Engine na VPC, como mostrado aqui.

A máquina virtual do Compute Engine que você vai usar como servidor de salto tem a mesma origem de rede que o gateway do Cloud VPN. É por isso que você pode usá-la para simular solicitações de envio de cargas de trabalho no local.

2. Configuração e requisitos

Configuração de ambiente personalizada

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 Você pode atualizar a qualquer momento.
• 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. normalmente você não se importa com o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, que normalmente é identificado como PROJECT_ID. Se você não gostar do ID gerado, pode gerar outro ID aleatório. Como alternativa, você pode tentar o seu próprio e ver se ele está disponível. Ela não pode ser alterada após essa etapa e permanecerá durante a duração do projeto.
• Para sua informação, há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Cuidado:um ID de projeto é globalmente exclusivo e não pode ser usado por mais ninguém depois de selecionado. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá mais ser usado

Observação: se você estiver usando uma conta do Gmail, deixe o local padrão definido como Sem organização. Se você estiver usando 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 será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar faturamento além deste tutorial, exclua os recursos criados ou exclua o projeto inteiro. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Configuração do ambiente

1. Defina uma variável de ambiente como o ID do projeto para uso em comandos posteriores:

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export ZONE=us-central1-a

2. Ative as APIs necessárias para executar este laboratório.

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com

3. Clone o repositório do app de exemplo e navegue até o diretório

git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git

cd cymbal-eats/partner-registration-service

4. Definir a região e a zona padrão para o Compute Engine e o Cloud Run

gcloud config set compute/region ${REGION}
gcloud config set run/region ${REGION}
gcloud config set compute/zone ${ZONE}

3. Implante o serviço

Primeiro, implante o serviço e deixe-o acessível ao público. Depois que você confirmar que pode enviar solicitações do seu navegador, bloquearemos o serviço e permitiremos apenas solicitações de fontes internas da rede.

Ao executar o comando a seguir, siga estas instruções:

• Local do código-fonte (...): verifique se você está no diretório partner-register-service e pressione Enter para aceitar o padrão.
• Nome do serviço (partner-register-service): pressione "Enter" para aceitar o padrão
• Permitir invocações não autenticadas ao [partner-register-service] (S/N)? S

gcloud run deploy 

Quando o comando é concluído, ele lista o URL do serviço do Cloud Run. A saída vai ser semelhante a esta listagem:

Service [partner-registration-service] revision [partner-registration-service-00001-haz] has been deployed and is serving 100 percent of traffic.
Service URL: https://partner-registration-service-ssssssssss-uc.a.run.app

Abra o URL do serviço no navegador. Você vai ver esta saída:

Partner registration service: RUNNING

Configurar o serviço para permitir apenas solicitações internas

Agora, você usará as configurações de entrada do serviço Cloud Run para permitir apenas solicitações de origens internas. As origens internas incluem recursos em redes VPC que estão no mesmo projeto (ou perímetro do VPC Service Controls) que o serviço do Cloud Run, o que é perfeito para nosso caso de uso.

Além disso, as solicitações de outros produtos do Google Cloud são consideradas internas, mesmo que não façam parte da VPC. Esses produtos incluem, por exemplo, Pub/Sub e Workflows.

As solicitações dessas origens permanecem na rede do Google, mesmo que acessem seu serviço no URL run.app, e o acesso público é proibido.

Atualize o serviço para permitir apenas solicitações internas:

gcloud run services update partner-registration-service --ingress=internal

Se você abrir o URL do serviço novamente, a mensagem "Error: Forbidden - Access is forbidden" será exibida.

Como o navegador envia a solicitação de uma origem de rede externa, e não de uma origem interna para o projeto do Google Cloud, isso é exatamente o que você espera que aconteça. Seu serviço agora está mais seguro.

4. Criar uma máquina virtual do Compute Engine como um servidor de salto

A próxima etapa é simular solicitações de um servidor local por um gateway do Cloud VPN, criando uma instância do Compute Engine na VPC para usar como um servidor de salto:

gcloud compute instances create jump-server --scopes=https://www.googleapis.com/auth/cloud-platform

A saída desse comando será semelhante a:

NAME         ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP   STATUS
jump-server  us-central1-a  n1-standard-1               10.128.0.10  34.170.108.8  RUNNING

Enviar uma solicitação da instância do Compute Engine para o serviço

Agora você vai abrir um terminal na máquina virtual e enviar uma solicitação diretamente da máquina na rede VPC.

Se o comando a seguir solicitar que você configure o SSH no Cloud Shell, siga as instruções:

gcloud compute ssh jump-server

Consiga o URL do serviço do Cloud Run com este comando:

gcloud run services describe partner-registration-service --region us-central1

As primeiras linhas da saída vão ficar assim:

✔ Service partner-registration-service in region us-central1

URL:     https://partner-registration-service-ssssssssss-uc.a.run.app
Ingress: internal

Agora, copie o URL e envie uma solicitação da instância do Compute Engine usando curl. Essa solicitação precisa ser bem-sucedida, já que a instância de VM é executada na rede VPC do seu projeto, que é uma origem interna.

export SERVICE_URL=https://

curl ${SERVICE_URL}

A saída deve ser:

Partner registration service: RUNNING

5. E o controle de acesso baseado em IAM?

Este laboratório mostrou como e quando usar as configurações de entrada. As configurações de entrada são uma ótima primeira etapa ao conectar uma carga de trabalho local ao Cloud Run.

O controle de acesso baseado em IAM requer mais esforço para ser implementado, especialmente se você estiver chamando de um host local:

• O IAM exige que você gerencie credenciais de conta de serviço de longa duração no host
• O IAM exige alterações no código para assinar solicitações usando as credenciais da conta de serviço.

O Google recomenda uma abordagem com várias camadas para o controle de acesso. Usar as configurações de entrada para restringir o acesso apenas a hosts internos é um ótimo primeiro passo, mas não pare por aí.

6. Parabéns!

Parabéns, você concluiu o codelab.

O que vem em seguida:

Conheça outros codelabs da Cymbal Eats:

• Como acionar fluxos de trabalho do Cloud com o Eventarc
• Como acionar o processamento de eventos no Cloud Storage
• Como se conectar ao CloudSQL particular pelo Cloud Run
• Como se conectar a bancos de dados totalmente gerenciados pelo Cloud Run
• Aplicativo seguro sem servidor com o Identity Aware Proxy (IAP)
• Como acionar jobs do Cloud Run com o Cloud Scheduler
• Como implantar com segurança no Cloud Run
• Como se conectar ao AlloyDB particular no Autopilot do GKE

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto ou mantenha o projeto e exclua cada um dos recursos.

Excluir o projeto

O jeito mais fácil de evitar cobranças é excluindo o projeto que você criou para este tutorial.

Referências úteis

Confira outros recursos que ajudam você a saber mais sobre as duas camadas de controle de acesso no Cloud Run.

• Como restringir a entrada no Cloud Run
• Como autenticar entre serviços
• Rede particular e Cloud Run