Un pare-feu détermine quel trafic réseau est autorisé à passer et quel trafic est refusé. Les pare-feu peuvent s'appliquer au trafic entrant (entrée), au trafic sortant (sortie) ou aux deux. Pour App Engine, le pare-feu App Engine ne s'applique qu'au trafic entrant acheminé vers votre application ou votre service.
Présentation
Le pare-feu App Engine est vérifié pour tous les types de requêtes adressées à votre application, y compris :
- Le trafic Web standard est acheminé vers l'adresse
appspot.comou le domaine personnalisé de l'application. - Requêtes provenant de Cloud Load Balancing
- Trafic provenant de sources internes telles que les machines virtuelles (VM) Compute Engine et Cloud Tasks.
Si votre application est configurée pour utiliser d'autres services ou produits de mise en réseau, vous devrez peut-être créer des règles pour contrôler le trafic entrant à la fois dans le pare-feu App Engine et dans les paramètres de pare-feu ou de sécurité d'autres produits. Ce guide couvre le comportement général du pare-feu App Engine et fournit des informations sur ces cas d'utilisation spécifiques.
Règles de pare-feu App Engine
Vous pouvez configurer des règles de pare-feu App Engine à l'aide de Google Cloud Console, de Google Cloud CLI ou de l'API Admin en spécifiant des règles qui autorisent ou bloquent les plages d'adresses IP spécifiées.
Par défaut, toute requête qui ne correspond pas à une règle est autorisée à accéder à votre application. Si vous devez bloquer toutes les requêtes qui ne correspondent pas à une règle spécifique (à l'exception des requêtes des services internes autorisées par défaut), remplacez l'action de la règle default par deny.
Fonctionnalité de pare-feu
Dans l'environnement standard App Engine, le pare-feu App Engine peut autoriser un certain trafic interne à contourner le pare-feu. Cela signifie que si vous définissez la règle default sur deny, les requêtes de certains services destinés à l'environnement standard App Engine ne sont pas bloquées. Ce sont tous des types de trafic demandés dans la configuration de l'application ou envoyés à partir de la même application. Les requêtes qui contournent les règles de pare-feu de cette manière incluent :
- Requêtes de préchauffage
- Tâches Cloud Scheduler utilisant le protocole HTTP App Engine (y compris le service Cron d'App Engine)
- Tâches App Engine dans Cloud Tasks (y compris les files d'attente de tâches App Engine)
Pour les applications qui utilisent l'environnement standard App Engine et les services fournis avec les environnements d'exécution de première génération, les notifications de l'ancienne API Mail contournent également le pare-feu.
Autoriser les requêtes entrantes de vos services
Le tableau suivant répertorie les plages d'adresses IP et le comportement du pare-feu App Engine pour les services courants. La plage d'adresses IP que vous utilisez varie selon que les requêtes entrantes sont transmises à une version qui s'exécute dans l'environnement standard ou flexible d'App Engine.
| Service | Plage d'adresses IP pour les requêtes envoyées à l'environnement standard App Engine | Plage d'adresses IP pour les requêtes envoyées à l'environnement flexible App Engine |
|---|---|---|
| Cron App Engine | 0.1.0.1/32 ou 0.1.0.2/32, contourne la règle de pare-feu par défaut si elle est définie sur "Refuser" | 0.1.0.1/32 ou 0.1.0.2/32 |
| Instances Compute Engine utilisant Cloud NAT pour les connexions sortantes | Adresse(s) IP Cloud NAT configurée(s) | Adresse(s) IP Cloud NAT configurée(s) |
| Instances Compute Engine avec des adresses IP externes | Adresse IP externe de l'instance | Adresse IP externe de l'instance |
| Instances Compute Engine sans adresse IP externe | 0.0.0.0/32 | 0.0.0.0/32 |
| Tâches Cloud Scheduler utilisant des tâches HTTP App Engine et App Engine dans Cloud Tasks (y compris les files d'attente de tâches App Engine) | 0.1.0.2/32, contourne la règle de pare-feu par défaut si elle est définie sur "Refuser" | 0.1.0.2/32 |
| Cloud Storage ou Blobstore | 0.1.0.30/32 | Non applicable |
| URL Fetch | 0.1.0.40/32 | 0.1.0.40/32 |
| Requêtes de préchauffage | 0.1.0.2/32, contourne la règle de pare-feu par défaut si elle est définie sur "Refuser" | Non applicable |
Selon votre cas d'utilisation, ces instructions supplémentaires peuvent s'appliquer lors de la configuration des règles de pare-feu App Engine :
- Les requêtes provenant de tâches Cron App Engine nouvellement créées ou mises à jour et envoyées à l'environnement standard ou flexible App Engine proviennent de
0.1.0.2. Pour les tâches Cron créées avec des versions anciennes de gcloud (antérieures à la version 326.0.0), les requêtes Cron proviennent de0.1.0.1. Pour en savoir plus sur l'identification des requêtes du service Cron d'App Engine, consultez la page Valider des requêtes Cron. - Si votre application interagit avec Cloud Load Balancing ou est connectée à un réseau VPC, consultez la section Interagir avec d'autres produits ou services ci-dessous.
Exemple d'environnement standard App Engine
Votre application s'exécutant dans l'environnement standard comporte deux services : frontend_service et backend_service. frontend_service utilise Cloud Tasks avec le protocole HTTP d'App Engine pour envoyer des messages à backend_service. Étant donné que la règle de pare-feu default autorise les requêtes Cloud Tasks, même si elle est configurée sur deny, vous n'avez pas besoin de créer une règle de pare-feu pour Cloud Tasks.
Toutefois, si vous souhaitez limiter l'accès à votre application et bloquer explicitement les requêtes Cloud Tasks, vous devez créer une règle de pare-feu deny pour la plage d'adresses IP 0.1.0.2/32.
Exemple d'environnement flexible App Engine
Votre application s'exécutant dans l'environnement flexible comporte deux services : frontend_service et backend_service, et dispose d'un pare-feu configuré pour refuser le trafic par défaut. frontend_service utilise Cloud Tasks avec le protocole HTTP d'App Engine pour envoyer des messages à backend_service. Étant donné que la règle de pare-feu default refuse les requêtes Cloud Tasks, vous devez créer une règle de pare-feu allow pour 0.1.0.2/32.
Interaction avec d'autres produits ou services
Cloud Load Balancing
Si vous utilisez Cloud Load Balancing et des NEG sans serveur, tenez compte des points suivants :
- L'équilibreur de charge n'interfère pas avec les règles de pare-feu App Engine et n'interagit pas avec elles. Les règles de pare-feu App Engine ne sont évaluées que lorsqu'un NEG sans serveur dirige le trafic vers App Engine.
Nous vous recommandons d'utiliser des contrôles d'entrée afin que votre application ne reçoive que les requêtes envoyées par l'équilibreur de charge (et par le VPC le cas échéant). Sinon, les utilisateurs peuvent se servir de l'URL App Engine de votre application pour contourner l'équilibreur de charge, les règles de sécurité Google Cloud Armor, les certificats SSL et les clés privées qui sont transmises via l'équilibreur de charge.
Si vos contrôles d'entrée sont définis pour recevoir le trafic
internal-and-cloud-load-balancing, conservez la règle de pare-feu App Engine par défaut telle quelle (allow) et utilisez les règles du pare-feu d'application Web Google Cloud Armor (WAF).
Empêcher l'accès au contenu mis en cache
Le pare-feu App Engine repose sur des mécanismes qui mettent en cache le contenu (tels que des serveurs proxy et des navigateurs Web). Lorsque du contenu est mis en cache, il est diffusé publiquement à partir de l'URL concernée jusqu'à son expiration. Il est possible d'y accéder même après la création d'autres règles de pare-feu.
Pour savoir comment modifier le délai d'expiration par défaut du contenu statique ou empêcher la mise en cache du contenu statique, consultez Expiration du cache.Pour empêcher la mise en cache du contenu dynamique de sortie du code de votre application, utilisez les en-têtes de réponse HTTP Cache-Control et Expires. Pour en savoir plus sur ces en-têtes HTTP, y compris sur le contrôle de la mise en cache, consultez Éviter la mise en cache.
Étapes suivantes
Suivez les instructions de la page Créer des pare-feu pour apprendre à configurer des règles de pare-feu App Engine.