Se uma subscrição push usar autenticação, o serviço Pub/Sub assina um símbolo da Web JSON (JWT) e envia o JWT no cabeçalho de autorização do pedido push. O JWT inclui reivindicações e uma assinatura.
Os subscritores podem validar o JWT e verificar o seguinte:
- As reivindicações são precisas.
- O serviço Pub/Sub assinou as reivindicações.
Se os subscritores usarem uma firewall, não podem receber pedidos push. Para receber pedidos push, tem de desativar a firewall e validar o JWT.
Se um subscritor tiver uma firewall, pode receber um erro 403 permission denied
.
Antes de começar
- Saiba mais acerca das subscrições.
- Compreenda como funcionam as subscrições push.
- Crie uma subscrição push.
Formato JWT
O JWT é um JWT do OpenIDConnect que consiste num cabeçalho, num conjunto de reivindicações e numa assinatura. O serviço Pub/Sub codifica o JWT como uma string base64 com delimitadores de pontos.
Por exemplo, o seguinte cabeçalho de autorização inclui um JWT codificado:
"Authorization" : "Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjdkNjgwZDhjNzBkNDRlOTQ3MTMzY2JkNDk5ZWJjMWE2MWMzZDVh YmMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tIiwiYXpwIjoiMTEzNzc0M jY0NDYzMDM4MzIxOTY0IiwiZW1haWwiOiJnYWUtZ2NwQGFwcHNwb3QuZ3NlcnZpY2VhY2NvdW50LmNvb SIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJleHAiOjE1NTAxODU5MzUsImlhdCI6MTU1MDE4MjMzNSwia XNzIjoiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tIiwic3ViIjoiMTEzNzc0MjY0NDYzMDM4MzIxO TY0In0.QVjyqpmadTyDZmlX2u3jWd1kJ68YkdwsRZDo-QxSPbxjug4ucLBwAs2QePrcgZ6hhkvdc4UHY 4YF3fz9g7XHULNVIzX5xh02qXEH8dK6PgGndIWcZQzjSYfgO-q-R2oo2hNM5HBBsQN4ARtGK_acG-NGG WM3CQfahbEjZPAJe_B8M7HfIu_G5jOLZCw2EUcGo8BvEwGcLWB2WqEgRM0-xt5-UPzoa3-FpSPG7DHk7 z9zRUeq6eB__ldb-2o4RciJmjVwHgnYqn3VvlX9oVKEgXpNFhKuYA-mWh5o7BCwhujSMmFoBOh6mbIXF cyf5UiVqKjpqEbqPGo_AvKvIQ9VTQ"
O cabeçalho e o conjunto de reivindicações são strings JSON. Depois de descodificadas, assumem a seguinte forma:
{"alg":"RS256","kid":"7d680d8c70d44e947133cbd499ebc1a61c3d5abc","typ":"JWT"} { "aud":"https://example.com", "azp":"113774264463038321964", "email":"[email protected]", "sub":"113774264463038321964", "email_verified":true, "exp":1550185935, "iat":1550182335, "iss":"https://accounts.google.com" }
Os tokens anexados a pedidos enviados para pontos finais de envio push podem ter até uma hora.
Configure o Pub/Sub para a autenticação push
O exemplo seguinte mostra como definir a conta de serviço de autorização push para uma conta de serviço à sua escolha e como conceder a função iam.serviceAccountTokenCreator
ao service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
agente do serviço.
Consola
Aceda à página Subscrições do Pub/Sub.
Clique em Criar subscrição.
No campo ID da subscrição, introduza um nome.
Selecione um tópico.
Selecione Push como o Tipo de fornecimento.
Introduza um URL de ponto final.
Selecione Ativar autenticação.
Selecione uma conta de serviço.
Certifique-se de que o agente de serviço
service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
tem a funçãoiam.serviceAccountTokenCreator
no painel de controlo do IAM do seu projeto. Se a conta de serviço não tiver recebido a função, clique em Conceder no painel de controlo do IAM para o fazer.Opcional: introduza um público-alvo.
Clique em Criar.
gcloud
# Configure the push subscription gcloud pubsub subscriptions (create|update|modify-push-config) ${SUBSCRIPTION} \ --topic=${TOPIC} \ --push-endpoint=${PUSH_ENDPOINT_URI} \ --push-auth-service-account=${SERVICE_ACCOUNT_EMAIL} \ --push-auth-token-audience=${OPTIONAL_AUDIENCE_OVERRIDE} # Your service agent # `service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com` needs to have the # `iam.serviceAccountTokenCreator` role. PUBSUB_SERVICE_ACCOUNT="service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PUBSUB_SERVICE_ACCOUNT}"\ --role='roles/iam.serviceAccountTokenCreator'
Quando ativa a autenticação para uma subscrição push, pode ocorrer um erro permission denied
ou not authorized
.
Para resolver este problema, conceda ao principal que inicia a criação ou a atualização da subscrição a autorização iam.serviceAccounts.actAs
na conta de serviço. Para mais informações,
consulte Autenticação em
"Crie subscrições push".
Se usar uma subscrição push autenticada com uma aplicação do App Engine protegida com o Identity-Aware Proxy, tem de fornecer o ID de cliente do IAP como público-alvo do token de autorização push.
Para ativar a CNA na sua aplicação do App Engine, consulte o artigo
Ativar a CNA.
Para encontrar o ID de cliente da IAP, procure IAP-App-Engine-app
ID de cliente na página
Credenciais.
Reivindicações
O JWT pode ser usado para validar que as reivindicações, incluindo as reivindicações email
e aud
, são assinadas pela Google. Para mais informações sobre como as APIs OAuth 2.0 da Google podem ser usadas para autenticação e autorização, consulte o artigo
OpenID Connect.
Existem dois mecanismos que tornam estas reivindicações significativas. Primeiro,
o Pub/Sub requer que o utilizador ou a conta de serviço que faz a chamada
CreateSubscription, UpdateSubscription ou ModifyPushConfig tenha uma função
com a autorização iam.serviceAccounts.actAs
na conta de serviço de autenticação push. Um exemplo de uma função deste tipo é a função
roles/iam.serviceAccountUser
.
Em segundo lugar, o acesso aos certificados usados para assinar os tokens é rigorosamente controlado. Para criar o token, o Pub/Sub tem de chamar um serviço Google interno através de uma identidade de conta de serviço de assinatura separada, que é o agente de serviço service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com
.
Esta conta de serviço de assinatura tem de ter a autorização
iam.serviceAccounts.getOpenIdToken
ou uma função de criador de tokens de conta de serviço (roles/iam.serviceAccountTokenCreator
) na conta de serviço de autorização push (ou em qualquer recurso principal, como o projeto, da
conta de serviço de autorização push).
Valide tokens
A validação de tokens enviados pelo Pub/Sub para o ponto final de envio envolve o seguinte:
- Verificar a integridade do token através da validação da assinatura.
- Garantir que as reivindicações de email e público-alvo no token correspondem aos valores definidos na configuração da subscrição push.
O exemplo seguinte ilustra como autenticar um pedido push para uma aplicação do App Engine não protegida com o Identity-Aware Proxy. Se a sua aplicação do App Engine estiver protegida com a IAP, o cabeçalho do pedido HTTP que contém o JWT da IAP é x-goog-iap-jwt-assertion
e tem de ser validado em conformidade.
protocolo
Pedido:
GET https://oauth2.googleapis.com/tokeninfo?id_token={BEARER_TOKEN}
Resposta:
200 OK
{ "alg": "RS256", "aud": "example.com", "azp": "104176025330667568672", "email": "{SERVICE_ACCOUNT_NAME}@{YOUR_PROJECT_NAME}.iam.gserviceaccount.com", "email_verified": "true", "exp": "1555463097", "iat": "1555459497", "iss": "https://accounts.google.com", "kid": "3782d3f0bc89008d9d2c01730f765cfb19d3b70e", "sub": "104176025330667568672", "typ": "JWT" }
C#
Antes de experimentar este exemplo, siga as instruções de configuração do C# em Início rápido: usar bibliotecas de cliente. Para mais informações, consulte a documentação de referência da API C# do Pub/Sub.
Ir
Java
Node.js
Python
Ruby
Para obter informações sobre a variável de ambiente PUBSUB_VERIFICATION_TOKEN
usada
nos exemplos de código acima,
consulte o artigo Escrever e responder a mensagens do Pub/Sub.
Encontre exemplos adicionais de como validar o JWT de portador neste guia para o início de sessão com o Google para Websites. Uma vista geral mais ampla dos tokens OpenID está disponível no guia OpenID Connect, incluindo uma lista de bibliotecas de cliente que ajudam a validar JWTs.
Autenticação de outros Google Cloud serviços
As funções do Cloud Run e do App Engine autenticam as chamadas HTTP do Pub/Sub validando os tokens gerados pelo Pub/Sub. A única configuração que precisa é conceder as funções de IAM necessárias à conta do autor da chamada.
Consulte os seguintes guias e tutoriais para diferentes exemplos de utilização com estes serviços:
Cloud Run
- Acionamento a partir do envio do Pub/Sub:
A sua conta de serviço de autorização de envio tem de ter a função
roles/run.invoker
e estar associada a um serviço do Cloud Run para invocar um serviço do Cloud Run correspondente - Usar o Pub/Sub com o tutorial do Cloud Run
App Engine
Funções do Cloud Run
- Acionadores HTTP:
A conta de serviço de autorização push tem de ter a função
roles/cloudfunctions.invoker
para invocar uma função se pretender usar pedidos push do Pub/Sub como acionadores HTTP para a função - Acionadores do Google Cloud Pub/Sub: as funções e as autorizações do IAM são configuradas automaticamente se usar acionadores do Pub/Sub para invocar uma função