La Cloud Function func_display doit invoquer func_query ; assurez-vous que func_query n'accepte que les appels de func_display et suivez les meilleures pratiques de Google. Que devez-vous faire ?

La bonne approche consiste à utiliser l'authentification basée sur les jetons d'identité OIDC, ce qui est une pratique recommandée par Google pour les invocations de Cloud Functions. En exigeant une authentification pour funcquery et en attribuant un compte de service unique à funcdisplay avec le rôle Cloud Functions Invoker pour funcquery, vous garantissez que seule funcdisplay peut l'invoquer. funcdisplay génère un jeton d'identité signé par Google, prouvant son identité, et funcquery le valide. Les autres options sont incorrectes car : La première option utilise un jeton auto-généré, ce qui est moins sécurisé et ne suit pas les meilleures pratiques de Google pour l'authentification entre services. La troisième option tente de restreindre le trafic via des règles de pare-feu VPC, mais les Cloud Functions sont des services sans serveur et ne résident pas directement dans un VPC de manière à pouvoir être ciblées par des règles de pare-feu d'entrée spécifiques à une autre fonction. De plus, cela ne garantit pas l'identité de l'appelant. La quatrième option a les mêmes lacunes que la troisième concernant les règles de pare-feu et l'identité. L'utilisation du même compte de service pour les deux fonctions ne restreindrait pas l'invocation à funcdisplay uniquement.