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.
Dans certaines circonstances, l'environnement flexible App Engine peut configurer automatiquement des règles de pare-feu au niveau du cloud privé virtuel (VPC). Toutefois, notez que le pare-feu VPC n'interagit pas avec le pare-feu App Engine.
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 |
|---|---|---|
| Cloud Storage ou Blobstore | 0.1.0.30/32 | Non applicable |
| 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 |
| 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 |
| URL Fetch | 0.1.0.40/32 | 0.1.0.40/32 |
| Instances Compute Engine avec l'accès privé à Google activé | 0.0.0.0/32 | 0.0.0.0/32 |
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).
Pare-feu VPC
Les pare-feu App Engine sont configurés et appliqués indépendamment des pare-feu basés sur le VPC. Les règles de pare-feu VPC s'appliquent aux ressources exécutées sur le réseau VPC, telles que les machines virtuelles Compute Engine, tandis que les règles de pare-feu App Engine s'appliquent aux requêtes entrantes adressées à votre application ou à votre service.
Si des règles de pare-feu basées sur le VPC (telles que des règles de pare-feu VPC ou des règles de pare-feu hiérarchiques) sont configurées dans votre environnement réseau, alors les pare-feu au niveau du VPC ainsi que les pare-feu App Engine doivent autoriser la plage d'adresses IP d'une requête entrante pour que l'application App Engine la reçoive.
Pour les pare-feu au niveau du VPC, les règles de pare-feu hiérarchiques sont évaluées avant les règles de pare-feu VPC et suivent une séquence pendant l'évaluation du pare-feu VPC. Les requêtes autorisées par le pare-feu au niveau du VPC et par le pare-feu App Engine sont reçues par votre application ou service App Engine. Si le pare-feu VPC refuse les requêtes provenant de la même plage d'adresses IP que le pare-feu App Engine accepte, l'accès n'est pas autorisé pour votre application App Engine.
VPC partagé
L'environnement flexible App Engine peut créer des pare-feu, selon que votre application est configurée pour utiliser un réseau VPC via un VPC partagé.
Si votre application de l'environnement flexible App Engine utilise un VPC partagé, l'environnement flexible App Engine ne crée pas automatiquement de règles de pare-feu. Si vous devez contrôler l'accès et autoriser le trafic sur le réseau VPC, vous pouvez créer des règles de pare-feu sur le réseau VPC partagé.
De plus, pour autoriser les requêtes provenant d'une source de trafic, vous devez autoriser la même plage d'adresses IP dans le pare-feu VPC et le pare-feu App Engine. Si la plage d'adresses IP n'est pas spécifiée aux deux emplacements (pare-feu VPC et pare-feu App Engine), elle n'est pas autorisée à accéder à votre application ou service App Engine.
Si votre application d'environnement flexible App Engine n'est pas configurée pour utiliser un VPC partagé, l'environnement flexible App Engine crée jusqu'à deux règles de pare-feu VPC masquées, selon que votre application utilise la division vérifications d'état (par défaut) ou vérifications d'état héritées. Ces règles de pare-feu masquées autorisent le trafic diffusé et le trafic de vérification d'état vers l'environnement flexible :
- Nom du réseau : réseau spécifié dans
app.yamlou réseau par défaut si aucun réseau n'est configuré. - Tag cible :
instance_tagsspécifié dans le fichierapp.yaml. Par défaut, si aucun tag cible n'est fourni, l'environnement flexible App Engine génère un tag unique qui n'affecte que les instances de cette version de l'environnement flexible spécifique. La règle de pare-feu cible ce tag. - Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Plages d'adresses IP sources :
35.191.0.0/16et130.211.0.0/22 - Protocoles et ports :
- tcp :
8443(pour les vérifications d'état héritées) ou10402(pour les vérifications d'état fractionnées)
- tcp :
- Priorité :
1000
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 empêcher la mise en cache de votre contenu, 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 la section Avoiding caching (Éviter la mise en cache).
Étape suivante
Suivez les instructions de la page Créer des pare-feu pour apprendre à configurer des règles de pare-feu App Engine.