A firewall determines which network traffic is allowed to pass and which traffic is rejected. In App Engine, you can create a firewall with up to 1000 prioritized individual rules that either allow or restrict a range of IP addresses and subnets. Your app will only respond to requests that are allowed by the firewall.
Before you begin
Before you can create App Engine firewall rules for your app, you must have one of the following App Engine IAM roles, which include the necessary privileges for creating or modifying firewall rules:
- App Engine Admin
- Editor
- Owner
Creating firewall rules
Use one of the following methods to create a firewall rule. Repeat these steps for each additional rule:
Use the Firewall rules page in Cloud Console to create a firewall rule:
-
Go to the Create a firewall rule page in Cloud Console:
-
Specify the details of the firewall rule:
-
In Priority, enter an integer to specify the relative
importance of the rule and define the order of when the rule is
evaluated.
Valid values are
1
to2147483646
. Priority1
is the first rule evaluated. Priority2147483647
is the last rule evaluated and is reserved for the `default` rule. -
In Action on match, specify whether to allow or deny
access for requests that match the rule. Rules set to
allow
forward the request to the app. Rules set todeny
respond to requests with a403 Forbidden
error. - In IP range, define the range of IP addresses that apply to the rule. The IP address range must be defined in CIDR notation, can include subnet masks, and support both IPv4 and IPv6.
- Optional: In Description, include a description of the rule that is no longer than 100 characters.
-
In Priority, enter an integer to specify the relative
importance of the rule and define the order of when the rule is
evaluated.
- Click Save to create the rule.
-
Test the rule to ensure that the priority and action provide the
expected behavior:
- Click Test IP address.
- Enter the IP address that you want to validate and then click Test to ensure that the corresponding rule gets correctly evaluated.
Run the following gcloud
app firewall-rules
commands to create a firewall rule:
-
Run the following command to create a firewall rule:
gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
where:-
PRIORITY is an integer between
1
and2147483646
that defines the rule's importance and order for which the rule is evaluated. Priority1
is the first rule evaluated. Priority2147483647
is the last rule evaluated and is reserved for the `default` rule. -
ALLOW_OR_DENY specifies whether to allow or deny access
for requests that match the rule. Valid values are
allow
ordeny
. Rules set toallow
forward the request to the app. Rules set todeny
respond to requests with a403 Forbidden
error. - IP_RANGE defines the range of IP addresses that apply to the rule. The IP range must be defined in CIDR notation, can include subnet masks, and support both IPv4 and IPv6.
- DESCRIPTION is an optional description of the rule that is no longer than 100 characters.
-
PRIORITY is an integer between
-
Run the following command to test your rule and ensure that the
priority and action provide the expected behavior:
gcloud app firewall-rules test-ip IP_ADDRESS
where IP_ADDRESS is the IP address that you want to test against your firewall. -
Run the following command to view a list of the existing rules:
gcloud app firewall-rules list
-
Run the following command to delete an existing rule:
gcloud app firewall-rules delete PRIORITY
where PRIORITY is the priority value of the rule that you want to delete.
- Examples:
-
Use the following examples to help you create your firewall:
-
Add a rule that allows an IPv6 address and subnet mask, and then test that rule to ensure it gets evaluated prior to your other rules:
gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778
-
Add a rule to deny an IPv4 address and subnet mask, and then test that rule to ensure that it gets appropriately evaluated:
gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny gcloud app firewall-rules test-ip 74.125.0.8
-
Update and then test the default rule to ensure that it restricts all IP addresses that don't match any other rules:
gcloud app firewall-rules update default --action deny gcloud app firewall-rules test-ip 123.456.7.89
-
To programmatically create firewall rules for your App Engine
app, you can use the
apps.firewall.ingressRules
methods in the
Admin API.
To test a firewall rule and ensure that the priority and action
provide the expected behavior, you can use the
apps.firewall.ingressRules.list
method and specify
the IP address that you want to test within the
matchingAddress
parameter.
Understanding App Engine firewall rules
An App Engine firewall consists of an ordered list of rules that can allow or deny access from the specified IP address or range to your app. The rule applies to all resources of the App Engine application.
The firewall rules are ordered by importance, which you define as a numerical
value in each rule's priority. You must specify a unique priority value for
each rule as it defines the importance relative to the other rules in the
firewall. The values for a rule's priority scale from the most important value
of 1
up to the least important at value 2147483647
.
Each firewall includes a default
rule that is automatically created with the
2147483647
priority and applies to the entire IP range of your app.
The default
rule is always evaluated after all the other rules
in the firewall and applied to all requests across all IP addresses.
The firewall evaluates the highest priority rule first.
All the remaining rules in the firewall are sequentially evaluated until a rule
matches the IP range of that request. When a matching rule is found, the
connection is either allowed or denied, and all the remaining rules in the
firewall are then skipped. If none of the manually defined rules in the firewall
match the request, the default
rule is evaluated.
For example, if you create a rule with priority 1
it is always evaluated
first. If an incoming request matches the rule with priority 1
, only that
rule is evaluated and all the other rules in the firewall are skipped, including
the default
rule.
The example firewall below shows how a rule's priority can change the behavior of your firewall.
App Engine firewalls and Cloud Load Balancing
If you use Cloud Load Balancing and serverless NEGS, note the following:
- The load balancer does not interfere or interact with App Engine firewall rules. The App Engine rules are not evaluated until a serverless NEG directs traffic to App Engine.
- We recommend that you use ingress controls so that your app only receives requests sent from the load balancer (and the VPC if you use it). Otherwise, users can use your app's App Engine URL to bypass the load balancer, Google Cloud Armor security policies, SSL certificates, and private keys that are passed through the load balancer.
Example firewall
In this example, a company has set up a firewall to grant access to the engineering team and internal corporate network to their in-development app. The firewall rules have been created with large gaps between each priority to allow for growth.
Priority | Action | IP range | Description |
---|---|---|---|
1000 | Deny | 192.0.2.1 | Denies access to a DoS attacker. |
2000 | Allow | 198.51.100.2 | Allows access to an engineer in the satellite office. |
3000 | Deny | 198.51.100.0/24 | Denies access to all non-engineering buildings. |
5000 | Allow | 203.0.113.0/24 | Allows access to the main building's network. |
2147483647 | Deny | * | Default Action |
After the firewall is created, assume that the following requests are directed at the sample app and note the app's response:
- Request from 198.51.100.2 matches rule with priority 2000 and is allowed.
- Request from 198.51.100.100 matches rule with priority 3000 and gets denied.
- Request from 203.0.113.54 matches rule with priority 5000 and is allowed.
- Request from 45.123.35.242 matches the default rule and gets denied.
Resolving conflicting rules
For example, assume that two of the priorities in the company's firewall are swapped. If the rules for priorities 2000 and 3000 are swapped, notice the unintended behavior.
Priority | Action | IP range | Description |
---|---|---|---|
1000 | Deny | 192.0.2.1 | Denies access to a DoS attacker. |
2000 | Deny | 198.51.100.0/24 | Denies access to all non-engineering buildings. |
3000 | Allow | 198.51.100.2 | Allows access to an engineer in the satellite office. |
5000 | Allow | 203.0.113.0/24 | Allows access to the main building's network. |
2147483647 | Deny | * | Default Action |
The engineer in the satellite office will not be able to access the company's
app as the rule's new priority means it will never be evaluated. The engineer's
IP address 198.51.100.2
matches the rule that denies all non-engineers in the
range 198.51.100.0/24
before the rule that allows access to the engineer's
IP address.
To fix this, you must set the priority of the rule that allows access to
198.51.100.2
to be higher than the rule that denies access for the IP range
198.51.100.0/24
.
Allowing requests from your services
You should consider the following points when creating rules:
- By default, any request that does not match a rule is allowed access to your
app. If you want to block all requests that do not match a specific rule, you
must set the
default
rule todeny
. - Task Queues traffic will be allowed by the firewall, even
when the
default
rule is set todeny
. Cron traffic will be allowed in the standard environment. To validate incoming cron requests are coming from App Engine apps, see Validating cron requests.
In the flexible environment, you have to explicitly allow cron traffic. For more information on creating firewall rules in the App Engine flexible environment, see Creating Firewalls.
To control the access of requests from other App Engine apps or services, you might need to create rules to accommodate the IP addresses that are used for service-to-service communication. If your app communicates with other apps or services in App Engine, you must consider how to handle requests from the following IP addresses:
- Requests from the URL Fetch service:
0.1.0.40
- Requests received in the standard environment:
0.1.0.40
- Requests received in the flexible environment:
0.1.0.40
and10.0.0.1
- Requests from
0.1.0.40
or10.0.0.1
can come from any App Engine app. - You can use the
X-Appengine-Inbound-AppId
header to determine the originating app ID.
- Requests received in the standard environment:
- Requests from the Blobstore or Cloud Storage:
0.1.0.30
- Requests received only in the standard environment:
- App deployment requests:
10.1.0.41
- App deployment requests:
- Requests from Compute Engine instances with Private Google Access
enabled:
0.0.0.0
- Requests from
0.0.0.0
will come from any Compute Engine instance with Private Google Access enabled.
- Requests from
Example
Your app has a backend service running in the standard environment (
backend_std
). The service uses the URL Fetch service to communicate withbackend_flex
.You need to create two firewall rules to allow requests and in
backend_flex
you have to read theX-Appengine-Inbound-AppId
header to make sure it corresponds to the app ID ofbackend_std
:0.1.0.40
- A rule to allowbackend_flex
to receive URL Fetch requests frombackend_std
.10.0.0.1
- A rule to allow the service-to-service communication for the URL Fetch requests inbackend_flex
.- In
backend_flex
only allow the requests where theX-Appengine-Inbound-AppId
header is equal to the ID ofbackend_std
.
- Requests from the URL Fetch service:
Preventing access to cached content
The App Engine firewall sits behind mechanisms that cache content, for example web proxies and browsers. When content is cached, that content is served publicly from the specific URL until it expires and can be accessed even after creating new firewall rules.
To prevent your content from being cached, use theCache-Control
and Expires
HTTP response headers. For more information about these HTTP headers, including
how to control caching, see
Avoiding caching.
What's next
To ensure that you've securely configured your app and set the appropriate levels of access, review Access Control.