Sécuriser les services de backend

En plus d'authentifier les requêtes des utilisateurs finaux auprès de votre passerelle déployée, il est important de sécuriser l'accès entre API Gateway et vos services de backend. Vous pouvez empêcher l'accès public à vos services gérés de backend (Cloud Run, Cloud Run Functions, App Engine, etc.) en procédant comme suit :

  • Autorisez uniquement l'accès authentifié à votre service de backend.
  • Accorder les autorisations nécessaires au compte de service associé à la configuration d'API de votre passerelle afin que celle-ci soit autorisée à appeler le backend.

Cette page décrit les étapes requises pour sécuriser votre service de backend, ainsi que les rôles et les autorisations dont le compte de service de votre passerelle a besoin pour accéder à ces services.

Cloud Run

Tous les services Cloud Run entièrement gérés sont déployés en mode privé par défaut, ce qui signifie qu'ils ne sont accessibles qu'à la condition de fournir des identifiants d'authentification dans la requête.

Les services Cloud Run sont sécurisés par IAM. Par défaut, les services Cloud Run peuvent être appelés par n'importe quel rôle contenant l'autorisation run.routes.invoke.

Vous pouvez configurer IAM sur les services Cloud Run (entièrement gérés) pour accorder l'accès à d'autres utilisateurs.

Pour API Gateway, l'accès aux services Cloud Run est activé en accordant au compte de service de la passerelle les rôles et autorisations appropriés : le rôle roles/run.invoker ou un rôle contenant l'autorisation run.routes.invoke.

Vous pouvez contrôler l'accès d'une passerelle à un service individuel avec le rôle IAM au niveau du service ou à tous les services d'un projet avec le rôle IAM au niveau du projet.

Si une requête de la passerelle vers votre service Cloud Run est refusée, assurez-vous que le compte de service de la passerelle dispose du rôle roles/run.invoker et de l'autorisation run.routes.invoke. Pour en savoir plus sur les rôles et les autorisations d'appelant, consultez la documentation de référence sur IAM Cloud Run.

Fonctions Cloud Run

Pour les services de backend Cloud Run Functions, Identity and Access Management (IAM) permet de contrôler l'affichage, la création, la mise à jour et la suppression des fonctions. IAM applique l'authentification des appelants aux services Cloud Run Functions, tels qu'API Gateway, en accordant des rôles.

L'attribution de rôles et d'autorisations avec IAM vous permet de contrôler deux ensembles d'actions :

  • Opérations des développeurs : création, mise à jour et suppression de fonctions, ainsi que gestion de l'accès aux fonctions.
  • Appel de fonction : entraîne l'exécution d'une fonction.

Accorder la possibilité d'appeler une fonction diffère pour les fonctions HTTP et les fonctions d'arrière-plan.

Pour permettre à API Gateway d'appeler votre service de backend Cloud Run Functions, attribuez au compte de service de la passerelle le rôle roles/cloudfunctions.invoker ou tout rôle contenant l'autorisation cloudfunctions.functions.invoke.

Vous pouvez contrôler l'accès d'une passerelle à une fonction individuelle avec le rôle IAM au niveau du service ou à toutes les fonctions d'un projet avec le rôle IAM au niveau du projet.

Si les requêtes d'une passerelle vers votre service de fonctions Cloud Run sont refusées, assurez-vous que le compte de service de la passerelle dispose du rôle roles/cloudfunctions.invoker et que le compte de service de la passerelle dispose de l'autorisation cloudfunctions.functions.invoke. Pour en savoir plus sur les rôles et les autorisations d'appelant, consultez la documentation de référence sur IAM pour Cloud Functions.

App Engine

Pour sécuriser votre application App Engine, vous devez utiliser Identity-Aware Proxy (IAP) afin de vous assurer que les requêtes sont authentifiées.

Suivez la procédure pour activer IAP pour le projet dans lequel votre service de backend App Engine est déployé. L'activation d'IAP garantit que l'accès à votre application de backend App Engine est sécurisé.

Pour permettre à API Gateway d'appeler votre service de backend App Engine, suivez la procédure décrite dans Configurer l'accès à IAP pour attribuer le rôle IAP-secured Web App User au compte de service associé à votre passerelle. En outre, attribuez au compte de service un rôle contenant les autorisations suivantes :

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

Autres API Google Cloud

Google Cloud Les API, telles que aiplatform.googleapis.com ou bigquery.googleapis.com, nécessitent un jeton d'accès et rejettent le jeton d'ID qu'API Gateway envoie à d'autres backends. La possibilité pour une passerelle d'appeler ces API dépend de son mode de streaming :

  • Passerelles de streaming : une passerelle avec un effectiveStreamingMode de EFFECTIVE_STREAMING_MODE_ENABLED s'authentifie avec un jeton d'accès pour le compte de service de la passerelle auprès de chaque backend dont l'hôte se termine par .googleapis.com ou .vertexai.goog. Le jeton d'accès ne dispose que du champ d'application https://www.googleapis.com/auth/cloud-platform. La passerelle ne peut donc pas appeler de méthodes d'API nécessitant un champ d'application OAuth différent.

    Les autres backends de la même passerelle reçoivent toujours un jeton d'ID. Un backend avec disable_auth (OpenAPI 2.0) ou disableAuth (OpenAPI 3.x) ne reçoit aucun jeton. Les champs jwt_audience (OpenAPI 2.0) et jwtAudience (OpenAPI 3.x) n'ont aucun effet sur ces backends.

    Attribuez au compte de service de la passerelle le rôle IAM requis par l'API cible, par exemple le rôle Utilisateur Agent Platform (roles/aiplatform.user) pour Gemini Enterprise Agent Platform (aiplatform.googleapis.com). Une passerelle de streaming qui n'envoie pas encore de jetons d'accès commence à le faire lors du prochain déploiement d'une mise à jour de la passerelle par API Gateway. Pour la changer immédiatement, mettez-la à jour vers une nouvelle configuration d'API.

  • Autres passerelles : une passerelle avec un effectiveStreamingMode de EFFECTIVE_STREAMING_MODE_DISABLED n'est pas compatible avec l'appel des API Google Cloud, et les appels peuvent échouer avec un code de réponse 401.