Se a sua arquitetura estiver a usar vários serviços, é provável que estes serviços tenham de comunicar entre si através de meios assíncronos ou síncronos. Muitos destes serviços podem ser privados e, por isso, requerem credenciais para acesso.
Para a comunicação assíncrona, pode usar os seguintes Google Cloud serviços:
- Cloud Tasks para comunicação assíncrona individual
- Pub/Sub para comunicação assíncrona de um para muitos, um para um e muitos para um
- Cloud Scheduler para comunicação assíncrona agendada regularmente
- Eventarc para comunicação baseada em eventos
Em todos estes casos, o serviço usado gere a interação com o serviço de receção, com base na configuração que configurou.
No entanto, para a comunicação síncrona, o seu serviço chama outro serviço diretamente, através de HTTP, usando o URL do respetivo ponto final. Para este exemplo de utilização, deve certificar-se de que cada serviço só pode fazer pedidos a serviços específicos. Por exemplo, se tiver um serviço login
, este deve poder aceder ao serviço user-profiles
, mas não ao serviço search
.
Nesta situação, a Google recomenda que use o IAM e uma identidade de serviço baseada numa conta de serviço gerida pelo utilizador por serviço à qual foi concedido o conjunto mínimo de autorizações necessárias para fazer o seu trabalho.
Além disso, o pedido tem de apresentar um comprovativo da identidade do serviço de chamadas. Para tal, configure o seu serviço de chamadas para adicionar uma chave de acesso OpenID Connect assinada pela Google como parte do pedido.
Configure a conta de serviço
Para configurar uma conta de serviço, configura o serviço de receção para aceitar pedidos do serviço de chamada, tornando a conta de serviço do serviço de chamada num principal no serviço de receção. Em seguida, concede à conta de serviço a função de invocador do Cloud Run
(roles/run.invoker
). Para realizar ambas as tarefas, siga as instruções no separador adequado:
IU da Play Console
Aceda à Google Cloud consola:
Selecione o serviço de receção.
Clique em Mostrar painel de informações no canto superior direito para mostrar o separador Autorizações.
Clique em Adicionar principal.
Introduza a identidade do serviço de chamadas. Normalmente, trata-se de um endereço de email, por predefinição
PROJECT_NUMBER-compute@developer.gserviceaccount.com
.Selecione a função
Cloud Run Invoker
no menu pendente Selecionar uma função.Clique em Guardar.
gcloud
Use o comando gcloud run services add-iam-policy-binding
:
gcloud run services add-iam-policy-binding RECEIVING_SERVICE \ --member='serviceAccount:CALLING_SERVICE_IDENTITY' \ --role='roles/run.invoker'
em que RECEIVING_SERVICE
é o nome do serviço de receção e CALLING_SERVICE_IDENTITY
é o endereço de email da conta de serviço, por predefinição PROJECT_NUMBER-compute@developer.gserviceaccount.com
.
Terraform
Para saber como aplicar ou remover uma configuração do Terraform, consulte os comandos básicos do Terraform.
Adicione o seguinte a um recursogoogle_cloud_run_v2_service
na sua configuração do Terraform:Substitua us-docker.pkg.dev/cloudrun/container/hello
por uma referência à imagem do contentor.
O código do Terraform seguinte torna o serviço inicial público.
O código Terraform seguinte cria um segundo serviço do Cloud Run destinado a ser privado.
Substitua us-docker.pkg.dev/cloudrun/container/hello
por uma referência à imagem do contentor.
O código Terraform seguinte torna o segundo serviço privado.
O seguinte código Terraform cria uma conta de serviço.
O seguinte código do Terraform permite que os serviços anexados à conta de serviço invoquem o serviço do Cloud Run privado inicial.
Adquira e configure o token de ID
Depois de conceder a função adequada à conta de serviço de chamadas, siga estes passos:
Obtenha um token de ID assinado pela Google através de um dos métodos descritos na secção seguinte. Defina a reivindicação de público-alvo (
aud
) para o URL do serviço de receção ou um público-alvo personalizado configurado. Se não estiver a usar um público-alvo personalizado, o valoraud
tem de permanecer como o URL do serviço, mesmo quando faz pedidos a uma etiqueta de tráfego específica.Adicione o token de ID obtido no passo anterior a um dos seguintes cabeçalhos no pedido ao serviço de receção:
- Um cabeçalho
Authorization: Bearer ID_TOKEN
. - Um cabeçalho
X-Serverless-Authorization: Bearer ID_TOKEN
. Pode usar este cabeçalho se a sua aplicação já usar o cabeçalhoAuthorization
para autorização personalizada. Isto remove a assinatura antes de transmitir o token ao contentor do utilizador.
- Um cabeçalho
Para outras formas de obter um token de ID que não estão descritas nesta página, consulte os Métodos para obter um token de ID.
Use as bibliotecas de autenticação
Uma forma de adquirir e configurar o processo de token de ID é usar as bibliotecas de autenticação.
Este código funciona em qualquer ambiente, mesmo fora do Google Cloud, onde as bibliotecas podem obter credenciais de autenticação para uma conta de serviço. Para usar este método,
transfira um ficheiro de chave da conta de serviço e
defina a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS
para o caminho do
ficheiro de chave da conta de serviço. Para mais informações, consulte o artigo sobre a chave da conta de serviço.
Este código não aceita credenciais de autenticação para uma conta de utilizador.
Node.js
Python
Ir
Java
Use o servidor de metadados
Se, por algum motivo, não conseguir usar as bibliotecas de autenticação, pode obter um token de ID do servidor de metadados do Compute enquanto o contentor estiver em execução no Cloud Run. Tenha em atenção que este método não funciona fora do Google Cloud, incluindo a partir do seu computador local.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
Onde AUDIENCE é o URL do serviço que está a invocar ou um público-alvo personalizado configurado.
A tabela seguinte resume as partes principais de um pedido de consulta de metadados:
Componentes | Descrição |
---|---|
URL raiz | Todos os valores de metadados são definidos como subcaminhos abaixo do seguinte URL raiz: http://metadata.google.internal/computeMetadata/v1 |
Cabeçalho do pedido | O seguinte cabeçalho tem de estar em cada pedido: Metadata-Flavor: Google Este cabeçalho indica que o pedido foi enviado com a intenção de obter valores de metadados, em vez de o fazer involuntariamente a partir de uma fonte insegura, e permite que o servidor de metadados devolva os dados que solicitou. Se não fornecer este cabeçalho, o servidor de metadados nega o seu pedido. |
Para ver um exemplo completo de uma aplicação que usa esta técnica de autenticação de serviço para serviço, siga o tutorial sobre como proteger serviços do Cloud Run.
Use a federação de identidades de cargas de trabalho a partir do exterior Google Cloud
Se o seu ambiente usar um fornecedor de identidade suportado pela federação de identidades de cargas de trabalho, pode usar o seguinte método para se autenticar de forma segura no seu serviço do Cloud Run a partir de fora do Google Cloud:
Configure a sua conta de serviço conforme descrito em Configure a conta de serviço nesta página.
Configure a federação de identidade da carga de trabalho para o seu fornecedor de identidade, conforme descrito no artigo Configurar a federação de identidade da carga de trabalho.
Siga as instruções em Conceder autorização a identidades externas para usar a identidade de uma conta de serviço.
Use a API REST para adquirir um token de curta duração, mas, em vez de chamar
generateAccessToken
para obter um token de acesso, chamegenerateIdToken
para receber um token de ID.Por exemplo, usando o cURL:
ID_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT:generateIdToken \ -H "Content-Type: text/json; charset=utf-8" \ -H "Authorization: Bearer $STS_TOKEN" \ -d @- <<EOF | jq -r .token { "audience": "SERVICE_URL" } EOF ) echo $ID_TOKEN
Onde
SERVICE_ACCOUNT
é o endereço de email da conta de serviço que o Workload Identity Pool está configurado para aceder, eSERVICE_URL
é o URL do serviço do Cloud Run que está a invocar. Este valor deve permanecer como o URL do serviço, mesmo quando fizer pedidos a uma etiqueta de tráfego específica.$STS_TOKEN
é o token do serviço de tokens de segurança que recebeu no passo anterior nas instruções da federação de identidades da carga de trabalho.
Pode incluir o token de ID do passo anterior no pedido ao serviço através de um cabeçalho Authorization: Bearer ID_TOKEN
ou um cabeçalho X-Serverless-Authorization: Bearer ID_TOKEN
. Se forem fornecidos ambos os cabeçalhos, apenas o cabeçalho X-Serverless-Authorization
é verificado.
Use uma chave de conta de serviço transferida de fora do Google Cloud
Se a Workload Identity Federation não for adequada para o seu ambiente, pode usar uma chave de conta de serviço transferida para fazer a autenticação a partir de fora doGoogle Cloud. Atualize o código do cliente para usar as bibliotecas de autenticação, conforme descrito anteriormente. Para mais informações, consulte o artigo sobre a chave da conta de serviço.
Pode adquirir um token de ID assinado pela Google através de um JWT autoassinado, mas este processo é bastante complicado e potencialmente propenso a erros. Os passos básicos são os seguintes:
Assine automaticamente um JWT de conta de serviço com a reivindicação
target_audience
definida para o URL do serviço de receção ou um público-alvo personalizado configurado. Se não usar domínios personalizados, o valortarget_audience
deve permanecer como o URL do serviço, mesmo quando fizer pedidos a uma etiqueta de tráfego específica.Troque o JWT autoassinado por um token de ID assinado pela Google, que deve ter a reivindicação
aud
definida para o URL anterior.Inclua o token de ID no pedido ao serviço através de um cabeçalho
Authorization: Bearer ID_TOKEN
ou um cabeçalhoX-Serverless-Authorization: Bearer ID_TOKEN
. Se ambos os cabeçalhos forem fornecidos, apenas o cabeçalhoX-Serverless-Authorization
é verificado.
Receba pedidos autenticados
No serviço privado de receção, pode analisar o cabeçalho de autorização para receber as informações enviadas pelo token Bearer.
Python
O que se segue?
- Saiba mais acerca da validação do token de ID