Como proteger serviços de back-end

Além de autenticar solicitações de usuários finais no gateway implantado, é importante proteger o acesso entre o gateway de API e seus serviços de back-end. Para impedir o acesso público aos serviços gerenciados de back-end (Cloud Run, funções do Cloud Run, App Engine etc.):

  • Permitir somente o acesso autenticado ao seu serviço de back-end.
  • Conceda as permissões necessárias à conta de serviço associada à configuração da API do gateway para que ele seja autorizado a invocar o back-end.

Nesta página, descrevemos as etapas necessárias para proteger o serviço de back-end e os papéis e as permissões necessárias para que a conta de serviço do gateway acesse esses serviços.

Cloud Run

Todos os serviços totalmente gerenciados do Cloud Run são implantados de modo privado por padrão, o que significa que eles não podem ser acessados sem o fornecimento de credenciais de autenticação na solicitação.

Os serviços do Cloud Run são protegidos pelo IAM. Por padrão, os serviços do Cloud Run podem ser chamados por qualquer papel que contenha a permissão run.routes.invoke.

É possível configurar o IAM nos serviços do Cloud Run (totalmente gerenciado) para conceder acesso a outros usuários.

Para o gateway de API, o acesso aos serviços do Cloud Run é ativado ao conceder à conta de serviço do gateway os papéis e as permissões apropriados: o papel roles/run.invoker ou um papel que contenha a permissão run.routes.invoke.

É possível controlar o acesso de um gateway a um serviço individual com o IAM no nível de serviço ou para todos os serviços em um projeto com o IAM no nível do projeto.

Se a solicitação de um gateway para o serviço do Cloud Run for rejeitada, verifique se a conta de serviço do gateway é concedida ao roles/run.invoker e se a conta de serviço do gateway tem a permissão run.routes.invoke. Saiba mais sobre os papéis e permissões do invocador na referência do IAM do Cloud Run.

Cloud Run functions

Para serviços de back-end das funções do Cloud Run, o Identity and Access Management (IAM) é usado para controlar a capacidade de visualizar, criar, atualizar e excluir funções. O IAM aplica a autenticação de autores de chamadas aos serviços do Cloud Run functions, como o gateway de API, concedendo papéis.

A concessão de papéis e permissões com o IAM permite o controle sobre dois conjuntos de ações:

  • Operações do desenvolvedor: criação, atualização e exclusão de funções, bem como gerenciamento de acesso a funções.
  • Invocação de função: faz com que uma função seja executada.

A concessão da capacidade de invocar funções é diferente para funções HTTP e funções em segundo plano.

Para permitir que o gateway de API chame o serviço de back-end das funções do Cloud Run, conceda à conta de serviço do gateway o papel roles/cloudfunctions.invoker ou qualquer papel que contenha a permissão cloudfunctions.functions.invoke.

É possível controlar o acesso de um gateway a uma função individual com o IAM no nível de serviço ou todas as funções em um projeto com o IAM no nível do projeto.

Se as solicitações de um gateway para o serviço do Cloud Run functions forem rejeitadas, verifique se a conta de serviço do gateway recebeu o papel roles/cloudfunctions.invoker e se a conta de serviço do gateway tem a permissão cloudfunctions.functions.invoke. Saiba mais sobre os papéis e permissões do invocador na referência do IAM do Cloud Functions.

App Engine

Para proteger seu aplicativo do App Engine, use o Identity-Aware Proxy (IAP) para garantir que as solicitações sejam autenticadas.

Siga as etapas para Ativar o IAP para o projeto em que o serviço de back-end do App Engine está implantado. Ativar o IAP garante que o acesso ao aplicativo de back-end do App Engine seja seguro.

Para ativar o gateway de API para chamar o serviço de back-end do App Engine, siga as etapas em Como configurar o acesso ao IAP para conceder à conta de serviço associada ao gateway o papel IAP-secured Web App User. Além disso, conceda à conta de serviço um papel que contenha as seguintes permissões:

  • appengine.applications.update
  • clientauthconfig.clients.create
  • clientauthconfig.clients.getWithSecret

Outras Google Cloud APIs

Google Cloud As APIs, como aiplatform.googleapis.com ou bigquery.googleapis.com, exigem um token de acesso e rejeitam o token de ID que o gateway de API envia para outros back-ends. Se um gateway pode chamar essas APIs depende do modo de streaming:

  • Gateways de streaming: um gateway com um effectiveStreamingMode de EFFECTIVE_STREAMING_MODE_ENABLED é autenticado com um token de acesso para a conta de serviço do gateway em cada back-end cujo host termina em .googleapis.com ou .vertexai.goog. O token de acesso tem apenas o escopo https://www.googleapis.com/auth/cloud-platform. Portanto, o gateway não pode chamar métodos de API que exigem um escopo OAuth diferente.

    Outros back-ends no mesmo gateway ainda recebem um token de ID. Um back-end com disable_auth (OpenAPI 2.0) ou disableAuth (OpenAPI 3.x) definido não recebe token. Os campos jwt_audience (OpenAPI 2.0) e jwtAudience (OpenAPI 3.x) não têm efeito nesses back-ends.

    Conceda à conta de serviço do gateway o papel do IAM exigido pela API de destino, como o papel de Usuário da Agent Platform (roles/aiplatform.user) para a Gemini Enterprise Agent Platform (aiplatform.googleapis.com). Um gateway de streaming que ainda não envia tokens de acesso começará a fazer isso na próxima atualização do gateway de API. Para mudar imediatamente, atualize para uma nova configuração de API.

  • Outros gateways: um gateway com um effectiveStreamingMode de EFFECTIVE_STREAMING_MODE_DISABLED não é compatível com a chamada de APIs do Google Cloud, e as chamadas podem falhar com um código de resposta 401.