Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Un firewall determina qué tráfico de red se acepta y qué tráfico se rechaza. Los firewalls se pueden aplicar al tráfico entrante (entrada), el tráfico saliente (salida) o ambos. En App Engine, el firewall de App Engine solo se aplica al tráfico entrante enrutado a tu aplicación o servicio.
Descripción general
El firewall de App Engine se verifica en todos los tipos de solicitudes de tu aplicación, incluidas las siguientes:
El tráfico web normal se enruta a la dirección appspot.com de la aplicación o al dominio personalizado.
Tráfico de fuentes internas como las máquinas virtuales (VM) de Compute Engine y Cloud Tasks.
En los casos en los que tu app esté configurada para usar otros servicios o productos de red, es posible que debas crear reglas a fin de controlar el tráfico entrante en el firewall de App Engine y en la configuración de firewall o seguridad de otros productos. En esta guía, se aborda el comportamiento general del firewall de App Engine y detalles sobre esos casos de uso especiales.
Reglas de firewall de App Engine
Puedes configurar reglas de firewall de App Engine con la consola de Google Cloud, Google Cloud CLI o la API de Admin si especificas reglas que permiten o bloquean rangos de IP especificados.
De forma predeterminada, cualquier solicitud que no coincida con una regla tendrá acceso a tu app. Si necesitas bloquear todas las solicitudes que no coinciden con una regla específica (sin incluir las solicitudes de servicios internos permitidos de forma predeterminada), cambia la acción default de la regla a deny.
Función del firewall
En el entorno estándar de App Engine, el firewall de App Engine puede permitir que determinado tráfico interno omita el firewall. Esto significa que si configuras la regla default en deny, no se bloquean las solicitudes de ciertos servicios destinados al entorno estándar de App Engine. Todos son tipos de tráfico solicitados en la configuración de la app o enviados desde la misma app. Las solicitudes que omiten las reglas de firewall de esta manera incluyen las siguientes:
Para las aplicaciones que usan el entorno estándar de App Engine y los servicios integrados a los entornos de ejecución de la primera generación, las notificaciones de la API de correo heredada también omiten el firewall.
Permite solicitudes entrantes de tus servicios
En la siguiente tabla, se enumeran los rangos de IP y el comportamiento del firewall de App Engine para servicios comunes. El rango de IP que uses depende de si las solicitudes entrantes se entregan a una versión que se ejecuta en el entorno estándar de App Engine o en un entorno flexible.
Servicio
Rango de IP para las solicitudes enviadas al entorno estándar de App Engine
Rango de IP para las solicitudes enviadas al entorno flexible de App Engine
Cloud Storage o Blobstore
0.1.0.30/32
No aplicable
Trabajos de Cloud Scheduler que usan tareas HTTP de App Engine y App Engine en Cloud Tasks (incluidas las listas de tareas en cola de App Engine)
0.1.0.2/32, omite la regla de firewall predeterminada si está configurada para denegar
0.1.0.2/32
Cron de App Engine
0.1.0.1/32 o 0.1.0.2/32, omite la regla de firewall predeterminada si está configurada para denegar
Según tu caso de uso, estas instrucciones adicionales podrían aplicarse cuando configuras las reglas de firewall de App Engine:
Las solicitudes de trabajos cron de App Engine recién creados o actualizados, que se enviaron al entorno estándar o flexible de App Engine provienen de 0.1.0.2. En el caso de los trabajos cron creados con versiones anteriores de gcloud (antes de 326.0.0), las solicitudes provienen de 0.1.0.1. Para obtener más información sobre cómo identificar solicitudes del servicio cron de App Engine, consulta Valida solicitudes cron.
La app que se ejecuta en el entorno estándar tiene dos servicios: frontend_service y backend_service. frontend_service usa Cloud Tasks con HTTP de App Engine para enviar mensajes a backend_service. Debido a que la regla de firewall default permite las solicitudes de Cloud Tasks incluso si se configura en deny, no necesitas crear una regla de firewall para Cloud Tasks.
Sin embargo, si deseas restringir el acceso a tu app y bloquear explícitamente las solicitudes de Cloud Tasks, deberías crear una regla de firewall deny para el rango de IP 0.1.0.2/32.
Ejemplo de entorno flexible de App Engine
La app que se ejecuta en el entorno flexible tiene dos servicios: frontend_service y backend_service, y tiene un firewall configurado para denegar el tráfico de forma predeterminada. frontend_service usa Cloud Tasks con HTTP de App Engine para enviar mensajes a backend_service. Dado que la regla de firewall default rechaza las solicitudes de Cloud Tasks, debes crear una regla de firewall allow para 0.1.0.2/32.
El balanceador de cargas no interfiere ni interactúa con las reglas de firewall de App Engine. Las reglas de App Engine no se evalúan hasta que un NEG sin servidores dirige el tráfico a App Engine.
Te recomendamos usar controles de entrada para que la app solo reciba solicitudes enviadas desde el balanceador de cargas (y la VPC, si la usas). De lo contrario, los usuarios pueden usar la URL de App Engine de tu app para omitir el balanceador de cargas, las políticas de seguridad de Google Cloud Armor, los certificados SSL y las claves privadas que se pasan a través del balanceador de cargas.
El firewall de App Engine se sitúa detrás de los mecanismos que almacenan contenido en caché, como proxies web y navegadores. Cuando el contenido se almacena en caché, se entrega de forma pública desde la URL específica hasta que vence, y se puede acceder a él incluso después de haber creado reglas de firewall nuevas.
Si deseas obtener información para cambiar el tiempo de vencimiento predeterminado del contenido estático o evitar que este se almacene en caché, consulta Vencimiento de la caché.
Para evitar que la salida del contenido dinámico del código de la app se almacene en caché, usa los encabezados de respuesta HTTP Cache-Control y Expires. Para obtener más información sobre estos encabezados HTTP y sobre cómo controlar el almacenamiento en caché, consulta Evita el almacenamiento en caché.
¿Qué sigue?
Sigue las instrucciones en Crea firewalls si deseas obtener información para configurar las reglas de firewall de App Engine.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-04-21 (UTC)"],[[["\u003cp\u003eThe App Engine firewall controls incoming traffic to your app, allowing or blocking requests based on specified IP ranges.\u003c/p\u003e\n"],["\u003cp\u003eBy default, requests not matching any defined rule are allowed, but this can be changed to deny access unless specifically allowed.\u003c/p\u003e\n"],["\u003cp\u003eCertain internal traffic, like warmup requests and Cloud Tasks, can bypass the firewall rules even when the default action is set to deny in the App Engine standard environment.\u003c/p\u003e\n"],["\u003cp\u003eWhen using Cloud Load Balancing, the App Engine firewall does not interact with the load balancer, and it is recommended to use ingress controls to ensure that requests only come through the load balancer.\u003c/p\u003e\n"],["\u003cp\u003eCached content may still be accessible publicly, even after new firewall rules are put in place, so control the cache behavior of static and dynamic content using Cache-Control and Expires headers.\u003c/p\u003e\n"]]],[],null,["# Understanding the App Engine firewall\n\nA **firewall** determines which network traffic is allowed to pass and which\ntraffic is rejected. Firewalls can apply to incoming traffic (ingress), outgoing\ntraffic (egress), or both. For App Engine, the App Engine firewall only\napplies to incoming traffic routed to your app or service.\n\nOverview\n--------\n\nThe App Engine firewall is checked for all types of\nrequests to your app, including:\n\n- Regular web traffic routed to the app's `appspot.com` address or custom domain.\n- Requests that arrive from [Cloud Load Balancing](/load-balancing).\n- Traffic from internal sources such as Compute Engine virtual machines (VMs) and Cloud Tasks.\n\nIn cases where your app is configured to use other networking services or\nproducts, you might need to create rules for controlling incoming traffic in\nboth the App Engine firewall and the firewall or security settings of other\nproducts. This guide covers the general behavior of the App Engine firewall,\nand details about those special use cases.\n\nApp Engine firewall rules\n-------------------------\n\nYou can [configure App Engine firewall rules](/appengine/docs/legacy/standard/python/creating-firewalls)\nusing the Google Cloud console, the Google Cloud CLI, or the Admin\nAPI by specifying rules that allow or block specified IP ranges.\n\nBy default, any request that does not match a rule is allowed access to your\napp. If you need to block all requests that do not match a specific rule\n(excluding requests from internal services allowed by default), change the\n`default` rule's action to `deny`.\n\n### Firewall feature\n\nIn the App Engine standard environment, the App Engine firewall can allow certain internal\ntraffic to bypass the firewall. This means that if you set the `default` rule to\n`deny`, requests from certain services destined for the App Engine standard environment do not\nget blocked. These are all types of traffic requested in the app's own\nconfiguration, or sent from the same app. Requests that bypass firewall rules in\nthis way include:\n\n- [Warmup requests](/appengine/docs/legacy/standard/python/configuring-warmup-requests)\n- Cloud Scheduler jobs using [App Engine HTTP](/scheduler/docs/creating#creating_jobs) (including [App Engine Cron](/appengine/docs/legacy/standard/python/config/cron)\n\n \u003cbr /\u003e\n\n - [App Engine tasks in Cloud Tasks](/tasks/docs/creating-appengine-tasks) (including App Engine Task Queues)\n\n For apps that use the App Engine standard environment and services bundled with the [first\n generation runtimes](/appengine/docs/standard/runtimes), notifications from the\n legacy Mail API also bypass the firewall.\n\n Allowing incoming requests from your services\n ---------------------------------------------\n\n The following table lists the IP ranges and App Engine firewall behavior for\n common services. The IP range you use depends on whether the incoming requests\n are delivered to a version that runs on the App Engine standard environment or\n flexible environment.\n\n Depending on your use case, these additional instructions might apply when\n configuring App Engine firewall rules:\n - Requests from newly created or updated App Engine Cron jobs sent to either the App Engine standard or flexible environment come from `0.1.0.2`. For Cron jobs created with older gcloud versions (earlier than 326.0.0), Cron requests will come from `0.1.0.1`. To learn more about how to identify requests from the App Engine Cron service, see [Validating cron requests](/appengine/docs/legacy/standard/python/scheduling-jobs-with-cron-yaml#validating_cron_requests).\n - If your app interacts with Cloud Load Balancing or is connected to a VPC network, see the [Interaction with other products or services](#interaction_with_other_products_or_services) section below.\n\n | **Caution:** Creating a rule for IP `0.0.0.0` will apply to **all** Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from `0.1.0.40` will allow **any** App Engine app to make URL Fetch requests to your app.\n\n ### App Engine standard example\n\n Your app running in the standard environment has two services: `frontend_service`\n and `backend_service`. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule allows Cloud Tasks requests even if configured to `deny`, you do not need to create\n a firewall rule for Cloud Tasks.\n\n However, if you wanted to restrict access to your app and explicitly block\n Cloud Tasks requests, you would create a `deny` firewall rule for IP range `0.1.0.2/32`.\n\n ### App Engine flexible example\n\n Your app running in the flexible environment has two services:\n `frontend_service` and `backend_service`, and has a firewall configured to deny\n traffic by default. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule denies Cloud Tasks requests, you would need to create an\n `allow` firewall rule for `0.1.0.2/32`.\n\n Interaction with other products or services\n -------------------------------------------\n\n ### Cloud Load Balancing\n\n If you use [Cloud Load Balancing and serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts), note the following:\n - The load balancer does not interfere or interact with App Engine firewall rules. The App Engine firewall rules are not evaluated until a serverless NEG directs traffic to App Engine.\n\n \u003c!-- --\u003e\n\n - We recommend that you [use ingress controls](/appengine/docs/standard/application-security#ingress_controls)\n so that your app only receives requests sent from the load balancer\n (and the VPC if you use it). Otherwise, users can use your app's\n App Engine URL to bypass the load balancer, Cloud Armor\n security policies, SSL certificates, and private keys that are passed through\n the load balancer.\n\n - If your [ingress controls](/appengine/docs/legacy/standard/python/application-security#ingress_controls) are set to receive `internal-and-cloud-load-balancing` traffic, leave the default App Engine firewall rule as is (`allow`), and use [Google Cloud Armor web application firewall (WAF) rules](/armor/docs/rule-tuning).\n\n Preventing access to cached content\n -----------------------------------\n\n The App Engine firewall sits behind mechanisms that cache content, for example\n web proxies and browsers. When content is cached, that content is served\n publicly from the specific URL until it expires and can be accessed even after\n creating new firewall rules.\n For information about changing the default expiration time for static content or preventing static content from being cached, see [Cache expiration](/appengine/docs/legacy/standard/python/how-requests-are-handled#static_cache_expiration).\n\n \u003cbr /\u003e\n\n To prevent dynamic content output from your app's code from being cached, use\n the `Cache-Control` and `Expires` HTTP response headers. For more information about\n these HTTP headers, including how to control caching, see\n [Avoiding caching](https://wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching).\n\n\n What's next\n -----------\n\n Follow the instructions in [Creating\n Firewalls](/appengine/docs/legacy/standard/python/creating-firewalls) to\n learn how to configure App Engine firewall rules."]]
