Controlling Access with Firewalls

A firewall provides identity-agnostic access control for your App Engine
app. The App Engine firewall allows you to define up to 1000 individual
rules that either allow or restrict a range of IP addresses and subnets.

To configure a firewall, you need to define rules that specify a priority value,
the range of IP addresses to either allow or deny, and an optional description.

Structuring 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.

Before you begin

Before you can create a firewall 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

If you want to use the gcloud tool or Admin API, you must first
install and configure that tooling:

Download, install, and then initialize the Google Cloud SDK to use the
gcloud tool:

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.

The default expiration time for cached content is 10 minutes. For information about configuring the expiration
time, see
Static cache expiration.

To prevent your content from being cached, use the Cache-Control and Expires
HTTP response headers. For more information about these HTTP headers, including
how to control caching, see Avoiding caching.

For static content, you can configure your standard environment app to set
HTTP response headers. For information about configuring HTTP response headers
in your app's configuration file, see
How Requests are Handled and the app.yaml reference.

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 to deny.

Task Queues traffic will be allowed by the firewall, even
when the default rule is set to deny.

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 and
10.0.0.1

Requests from 0.1.0.40 or 10.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.

10.0.0.1 - A rule to allow the service-to-service communication for
the URL Fetch requests in backend_flex.

In backend_flex only allow the requests where the
X-Appengine-Inbound-AppId header is equal to the ID of backend_std.

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.
Simlarly, allowing requests from 0.1.0.40 or 10.0.0.1 will allow any
App Engine app to make URL Fetch requests to your app.

Creating firewall rules

Use one of the following methods to create a firewall rule. Repeat
these steps for each additional rule:

Console

Use the Firewall rules page in Cloud Console to create a
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 to 2147483646.
Priority 1 is the first rule evaluated. Priority
2147483647 is the last rule evaluated and is
reserved for the `default` rule.

Important: After a rule is created, you cannot edit the
priority value. You must delete and then recreate a rule to
change the value of a rule's priority.

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 to
deny respond to requests with a
403 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.

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.

PRIORITY is an integer between 1 and
2147483646 that defines the rule's importance
and order for which the rule is evaluated. Priority 1
is the first rule evaluated. Priority 2147483647 is
the last rule evaluated and is reserved for the `default` rule.
Important: After a rule is created, you cannot edit the
priority value. You must delete and then recreate a rule to
change the value of a rule's priority.

ALLOW_OR_DENY specifies whether to allow or deny access
for requests that match the rule. Valid values are
allow or deny. Rules set to
allow forward the request to the app.
Rules set to deny respond to
requests with a 403 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.

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:

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.

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 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.