Questions fréquentes et dépannage

Cet article contient des questions fréquentes à propos d'Identity-Aware Proxy (IAP).

Quelles applications puis-je sécuriser avec IAP ?

IAP peut être utilisé avec :

• les applications dans les environnements standard et flexible App Engine ;
• Les instances Compute Engine avec des services de backend d'équilibrage de charge HTTP(S)
• les conteneurs Google Kubernetes Engine.
• Applications Cloud Run avec des services de backend d'équilibrage de charge HTTP(S)

IAP n'est pas compatible avec Cloud CDN pour le moment.

Pourquoi y a-t-il un symbole "#" à la fin de mon URL après la connexion à mon application ?

Dans certains navigateurs et dans certaines conditions, un symbole # peut s'ajouter à l'URL après l'authentification. Ceci est normal et ne pose aucun problème lors de la connexion.

Pourquoi mes requêtes échouent-elles et renvoient-elles un code d'état 405 Method Not Allowed (Méthode non autorisée) ?

Cela peut être dû au fait que les cookies ne sont pas joints à vos requêtes. Par défaut, les méthodes JavaScript ne joignent pas les cookies aux requêtes.

La manière d'inclure les cookies varie d'une méthode de requête à l'autre. Par exemple, pour les requêtes envoyées avec un objet XMLHttpRequest, la propriété withCredentials doit être définie sur true, alors que pour les requêtes envoyées avec l'API Fetch, l'option credentials doit être définie sur include ou same-origin.

Pour en savoir plus sur la gestion des erreurs qui ne se produisent qu'après un certain temps, consultez la page Gérer les sessions IAP.

Pourquoi ai-je reçu un code d'état HTTP 401 Unauthorized (Non autorisé) au lieu d'un code d'état HTTP 302 Redirect (Redirection) ?

IAP répond par un code d'état 302 Redirect lorsqu'un client est configuré pour gérer les redirections. Pour indiquer que votre client peut gérer les redirections, assurez-vous que HTTP Accept="text/html,*/*" figure dans l'en-tête des requêtes.

Pourquoi les requêtes POST ne déclenchent-elles pas de redirections ?

Pour que des redirections soient déclenchées, assurez-vous que les appels à IAP ne sont pas des requêtes POST. Les navigateurs n'effectuent pas de redirections en réponse aux requêtes POST. Pour cette raison, IAP répond par un code d'état 401 Unauthorized au lieu d'un code d'état 302 Redirect.

Si vous avez besoin d'IAP pour diffuser des requêtes POST, assurez-vous que le jeton d'ID ou les cookies valides sont transmis dans l'en-tête des requêtes.

Incluez le jeton d'ID dans un en-tête Authorization: Bearer pour envoyer une requête authentifiée à la ressource sécurisée par IAP. Pour obtenir des cookies valides, actualisez la session.

Puis-je utiliser IAP si j'ai désactivé l'API ?

Oui. L'accès aux ressources sécurisées avec IAP fonctionne même si l'API est désactivée, mais vous ne pouvez pas modifier les autorisations IAM.

Comment puis-je empêcher les utilisateurs disposant du rôle "Propriétaire" d'utiliser IAP pour TCP ?

Tout d'abord, évitez autant que possible d'utiliser le rôle "Propriétaire" (roles/owner). Ce rôle accorde de larges autorisations sur l'ensemble de Google Cloud. L'attribution de rôles et d'autorisations plus précis peut accroître la sécurité de votre projet. Pour en savoir plus, consultez les bonnes pratiques de IAM.

Si vous ne parvenez pas à réduire l'utilisation du rôle "Propriétaire", vous pouvez bloquer IAP pour TCP à l'aide de règles de pare-feu.

Quel domaine utilise IAP pour TCP ?

L'IAP utilise les domaines suivants, qui appartiennent à Google:

• tunnel.cloudproxy.app
• mtls.tunnel.cloudproxy.app si l'accès basé sur les certificats est activé.

Si vous vous connectez via un serveur proxy ou un pare-feu, assurez-vous qu'ils autorisent le trafic vers ces domaines et qu'ils ne bloquent pas l'utilisation de connexions WebSocket.

Si vous bloquez le trafic vers ces domaines, vous ne pourrez pas utiliser IAP pour TCP. Vous pouvez recevoir plusieurs messages d'erreur différents.

Si vous utilisez gcloud, le message d'erreur peut être :

Error while connecting [[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

Si vous utilisez SSH à partir du navigateur, le message d'erreur est :

Cloud Identity-Aware Proxy Failed

Aucun code n'est associé à cette erreur.

Pourquoi l'erreur Server Error s'affiche-t-elle ?

Si le message d'erreur suivant s'affiche, il est possible que votre pare-feu bloque les adresses IP 130.211.0.0/22 et 35.191.0.0/16:

Error: Server Error
The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds.

Si les adresses IP 130.211.0.0/22 et 35.191.0.0/16 de l'équilibreur de charge ne peuvent pas atteindre votre backend, vos applications risquent de ne pas être accessibles. Pour en savoir plus, consultez Configurer un équilibreur de charge HTTPS externe.

Si vous utilisez IAP pour TCP pour vous connecter à une VM spécifique, la VM doit accepter les connexions provenant d'adresses de la plage 35.235.240.0/20.

Pourquoi des erreurs internes du serveur s'affichent-elles de manière intermittente ?

Un message d'erreur au format suivant indique une défaillance interne:

An internal server error occurred while authorizing your request. Error code X

Les erreurs internes avec les codes d'erreur 1, 30, 62, 63, 64 ou 703 indiquent des échecs du backend. Un faible taux de ces erreurs de backend indique souvent un problème temporaire. Les clients doivent relancer la requête à l'aide d'un intervalle exponentiel entre les tentatives.

Comment résoudre les erreurs liées au dépassement du quota (code d'erreur 429) ?

Le code d'erreur 429 indique que le trafic vers l'application est limité par l'IAP. L'IAP applique une limite de 360 000 requêtes par minute et par projet. Si plusieurs applications sont hébergées dans un même projet, les quotas s'appliquent au nombre total de requêtes reçues par toutes les applications protégées par l'IAP Play Store du projet.

Si vous rencontrez des erreurs de quota dépassé par IAP, voici quelques techniques que vous pouvez appliquer pour atténuer le problème. * Nous vous déconseillons d'effectuer des tests de charge dans des instances de production. Si l'augmentation de la charge est due à des tests de charge, nous vous recommandons de trouver d'autres chemins réseau vers votre application qui n'appellent pas l'API IAP.

• Si votre application reçoit un trafic élevé de service à service, nous vous recommandons d'implémenter un intervalle exponentiel entre les tentatives côté client pour gérer correctement les erreurs 429.

• Si plusieurs applications à fort trafic se trouvent dans le même projet, envisagez de déplacer certaines d'entre elles vers un autre projet.

• Si l'application est conçue en tant qu'API au lieu d'une application Web, envisagez d'utiliser des solutions de passerelle API telles qu'Apigee.

• Si la croissance organique est à l'origine du trafic élevé, contactez l'assistance Google Cloud pour demander une augmentation de la limite de quota.

Codes d'erreur

Le tableau suivant répertorie les codes d'erreur et les messages courants qui s'affichent lors de la configuration et de l'utilisation d'IAP.

Si vous ne parvenez pas à résoudre votre problème ou si votre erreur ne figure pas sur cette page, contactez le Cloud Customer Care. Indiquez la description de l'erreur et la réponse que vous obtenez à partir d'un appel GET à l'API. Assurez-vous de supprimer votre code secret du client de la réponse.