Firewall Rules Overview

Google Cloud Platform (GCP) firewall rules protects your virtual machine (VM) instances from unapproved connections, both inbound (ingress) and outbound (egress). You can create firewall rules to allow or deny specific connections based on a combination of IP addresses, ports, and protocol.

You can configure GCP firewalls through the Google Cloud Platform Console, gcloud command line tool, and REST API.

Firewall rules in GCP

Every VPC network also functions as a distributed firewall. While firewall rules are applied to the network as a whole, connections are allowed or denied at the instance level. You can think of the firewall as existing not only between your instances and other networks, but between individual instances within the same network.

GCP firewall rules are stateful in that if a connection is allowed, all subsequent traffic in that flow is also allowed in both directions. As such, GCP firewall rules cannot be used to allow traffic on a specific port in one direction, but deny the return traffic.

When you specify a rule, GCP assigns it to every instance in the network unless you restrict that assignment. This applies to Compute Engine VM instances, instances running Kubernetes Engine containers, and instances running App Engine Flex. You can restrict a rule so that it only applies to certain instances by using target tags or target service accounts. For example, if you want instances owned by a particular service account only to be reachable from the Internet, you can create a rule that allows ingress from the Internet, restrict the rule to only that service account. GCP then updates the firewall with that rule for those instances only.

If all firewall rules in a network are deleted, there is still an implied "Deny all" ingress rule and an implied "Allow all" egress rule for the network.

Firewall rule components

You can express your desired firewall configuration as a set of firewall rules. Conceptually, a firewall rule is composed of the following parameters, described in more detail in the following sections.

  • The direction of the rule. Inbound connections are matched against ingress rules only, and outbound connections are matched against egress rules only.
  • The source of the connection for ingress packets, or the destination of the connection for egress packets.
  • The protocol and port of the connection.
  • The action of the rule, which is to allow or deny packets that match the direction, protocol, port, and source or destination of the rule.
  • The priority of the rule, which governs the order in which rules are evaluated. The first matching rule is applied.
  • Rule assignment. By default, all rules are assigned to all instances, but you can assign certain rules to certain instances only.

Direction of the rule

A rule applies to one connection direction only, either inbound to instances (ingress rules) or outbound from instances (egress rules). The direction of the rule is from the point of view of the instance. A connection from VM1 to VM2 is an egress connection from the point of view of VM1 and an ingress connection from the point of view of VM2. Ingress rules block or allow connections from reaching the instances, and egress rules block or allow connections from leaving instances. If you do not specify a direction for the rule, then the rule is an ingress rule.

  • For the ingress direction, sources can be specified as part of the rule. In other words, the rule specifies from which source connections are blocked or allowed.
  • For the egress direction, destinations can be specified as part of the rule. In other words, the rule specifies to which destinations connections are blocked or allowed.

Sources or destinations for the rule

An ingress rule may be configured to affect connections coming from particular sources only. You can specify the source by IP addresses, source tags, or a source service account.

An egress rule may be configured to affect connections headed for particular destinations only. You can specify destinations with one or more ranges of IP addresses.

If sources or destinations are unspecified, then the rule applies to all sources or destinations.

Protocols and ports

Any rule can be restricted to apply to specific protocols only or specific combinations of protocols and ports only. For example, a rule that blocks traffic from a certain IP address, but which doesn't specify a protocol or port, blocks traffic from all protocols and ports from that IP address. A rule that blocks tcp:80 traffic from that IP address will block only TCP traffic on port 80 from that address.

The protocol can be specified as a well-known protocol string (tcp, udp, icmp, esp, ah, sctp) or as the IP protocol number. If no protocols are specified, the rule applies to all protocols.

Action of the rule

A rule can either allow or deny connections that match the rest of the rule.

  • allow rules allow connections matching the specified conditions to arrive or leave instances, depending on the direction of the rule.
  • deny rules deny connections matching the specified conditions from arriving at or leaving instances, depending on the direction of the rule.

You cannot specify both allow and deny in the same firewall rule. However, you can specify multiple overlapping or conflicting allow and deny firewall rules. If two rules conflict, then the rule with the highest priority is used. If both rules have the same priority, then the deny rule is used.

Priority order for firewall rules

Two rules may conflict, such as a case when one rule denies certain connections from all instances but a second rule allows those connections for a certain subset of instances. Relative priority determines the precedence of the rules. In this case, the rule allowing the connections for the subset of instances should have a higher priority than the other rule so that the limited allow rule is evaluated first. If the global deny rule had higher priority, then it would be evaluated first and the selective allow rule would never be evaluated, blocking connections that should be permitted.

Priority may be any integer value from 0 through 65535, both inclusive. When unspecified, a priority value of 1000 is given. A lower priority "number" indicates higher priority, so a rule with a priority of 1 has a higher priority than, and is evaluated before, a rule with a priority of 2. If a connection matches conflicting rules with same priority, the deny policy takes precedence.

See Default firewall rules for a list of default rules and their priorities.

Rule assignment

By default, every rule is assigned every instance in the network. So, if a rule allows inbound connections on a particular port, every instance in the network will be able to receive connections on that port. You can restrict the assignment of rules using target tags or target service accounts. A rule that is limited by target tag or target service account only applies to instances with that tag or service account.

For example, suppose you have a rule that blocks all Internet connections from reaching instances in your network, but you wanted certain instances to be able to receive connections. You could allow connections from the Internet to reach a specific group of instances using one of the following methods:

  • Using tags: You can assign the instances a tag, then specify the same tag in the allow firewall rule.
  • Using service accounts: You can create the instances using a specific service account, then specify that service account in the allow firewall rule.

In both cases, the allow ingress rule is applied to the designated instances only. Connections coming to those instances would be allowed by the rule. Connections coming to other instances would be denied because they don't have the specific allow rule.

Service accounts can be used with any type of rule: ingress, egress, allow, deny, etc.

Rule assignment and service accounts

You can assign firewall rules to instances based on the IAM service account that owns the instance. If you have instances that are owned by a particular service account, you can specify that service account when you create the rule. GCP then assigns that rule to instances with that service account only. GCP also assigns that firewall rule to any new instances created with that service account, regardless of whether the new instances were created manually or automatically,

Not every service account in your org can be used to create instances and firewall rules in a project. You can use the service accounts in the project where you are creating the rules, and you can use service accounts from linked Shared VPC projects. You cannot create firewall rules based on service accounts from linked VPC Network Peering projects.

If you have the correct permissions, you can create any new virtual machine instances to run as the service account. You can also assign or change a service account for an existing instance. Assigning or changing the service account requires stopping and resuming the VM instance. See Changing the service account for an instance for details.

Service accounts vs. tags

Recommendation: If you need control and restrictions over application of firewalls rules in granular groups of VM instances, configure firewall rules based on service accounts, not tags.

While both tags and service accounts can be used as VM instance grouping mechanisms for firewall rules, they have different use cases.

  • A service account is the identity an instance is running with. An instance can have only one service account. A tag is an attribute; each instance can have many tags.
  • Use of service accounts is restricted by IAM permissions. A user has to be explicitly granted permissions to start instances with a particular service account. Instance tags, on the other hand, can be changed by a user who can edit the instance. Anyone who can start an instance can assign arbitrary tags to it.
  • Changing a service account for an instance requires stopping and restarting the instance. Changing tags is just applying metadata and it is a much lighter operation.

Firewall rules can be defined with service accounts or with tags but not with both. Specifically, source tags and target tags can't be used in combination with source service accounts and target service accounts in the same firewall rule. If a firewall rule uses source or target tags, then neither source nor target service accounts can be used in that same firewall rule, and vice versa.

Tags are a very flexible mechanism, but the use of a given tag is not restricted in any way. Instance admins can apply any tags to their VM instances, either at or after creation time. In doing so, Instance admins are able to apply or remove firewall rules that a Security admin might have defined, or they can add or remove their instances from the set of rules governed by a particular source tag.

Service accounts can be used as an authenticated mechanism to group and templatized instances based on the application identity (service account), so that firewall rules can be applied. An Instance admin requires a specific IAM permission on the service account in order to be able to create instances with that service account.

Recommendation: If you need control and restrictions over application of firewalls rules in granular groups of VM instances, configure firewall rules based on service accounts, not tags.

Specifications

  • Only IPv4 addresses are supported in a firewall rule.
  • TCP packet fragments other than the first fragment will not match a TCP port rule because the firewall does not reassemble the packet before checking the firewall rule. Only the first fragment, which contains the TCP header, can match the firewall rule.
  • GCP firewall cannot log as an action. It can only accept or reject a connection. GCP does not collect statistics per rule at this time.
  • Firewall rules are specific to a network. They cannot be shared between networks.

GCP firewall rule summary table

The following table summarizes firewall behavior. The phrase “all traffic” as used here refers to all traffic of the specified protocol and specified ports or port ranges (if any).

GCP firewall rule Direction GCP firewall rule order GCP firewall rule conditions GCP firewall rule applied to GCP firewall action
  Priority Protocol Port Source Destination GCP Virtual Network Target Tag OR Target Service Account Allow OR deny
Ingress

Optional
(default: 1000)
Mandatory Optional
(Default: All ports)
Optional
Src IP CIDR OR
SourceTags OR
Source Service Account
(Default: 0.0.0.0/0)
NOT ALLOWED Mandatory Optional
(Default:
no target tag OR target service account)
Mandatory
ALLOW
OR
DENY
Egress

Optional
(default: 1000)
Mandatory Optional
(Default: All ports)
NOT ALLOWED Optional
Dst IP CIDR
(Default: 0.0.0.0/0)
Mandatory Optional
(Default:
no target tag OR target service account)
Mandatory
ALLOW
OR
DENY

The use of tags and service accounts is mutually exclusive.

  • If either source tags or target tags are used in a firewall rule, neither a source service account nor a target service account can be used in the same firewall rule.
  • If either a source service account or a target service account is used in a firewall rule, neither source tags nor target tags can be used in the same firewall rule.
  • Only one service account can be configured as a source service account per firewall rule.
  • Only one service account can be configured as target service account per firewall rule.

Default firewall rules

Every VPC network comes with an implied "allow egress" firewall rule and an implied "deny ingress" firewall rule. These rules exist, but do not appear in firewall rule listings. In addition, the default network that is automatically created with every project has additional rules.

Pre-configured rules have a very low priority. Rules you create will take precedence over these rules unless you explicitly give your rules a low priority as well.

All networks, whether a project's default network or a manually created network, have the following implied rules. These rules cannot be changed or deleted, but rules with a higher priority can override them.

  • A default "allow egress" rule.
    Allows all egress connections. Rule has a priority of 65535.
  • A default "deny ingress" rule.
    Deny all ingress connection. Rule has a priority of 65535

In addition, a project's default network is created with the following default firewall rules. These rules can be deleted if necessary.

  • default-allow-internal
    Allows ingress network connections of any protocol and port between VM instances on the network. Rule has a priority of 65534.
  • default-allow-ssh
    Allows ingress TCP connections from any source to any instance on the network over port 22. Rule has a priority of 65534.
  • default-allow-icmp
    Allows ingress ICMP traffic from any source to any instance on the network. Rule has a priority of 65534.
  • default-allow-rdp
    Allows ingress remote desktop protocol traffic to TCP port 3389. Rule has a priority of 65534.

If you want these rules to exist in VPC networks that you create, you must configure them yourself.

GCP firewall use cases

Egress cases

Egress firewall rules control outgoing connections originated inside your GCP network. Egress allow rules allow outbound connections that match specific protocol, ports, and IP addresses. Egress deny rules prevent instances from initiating connections that match non-permitted port, protocol, and IP range combinations.

For egress firewall rules, destinations to which a rule applies may be specified using IP CIDR ranges.

You can use destination ranges to protect from undesired connections initiated by a VM instance towards an external destination (e.g., certain IP addresses in the Internet) or towards specific GCP CIDR ranges (e.g., towards a specific subnet).

Egress connections from a VM instance to an internal or external address

This diagrams illustrate a VM connecting to an external address and a VM connecting to another VM in the same network.

Egress from VM instance (click to enlarge)
Egress from VM instance (click to enlarge)

Egress connections from a VM instance can be controlled as follows.

Conditions: Matching outbound connection are constructed using:

  • Destination CIDR ranges
  • Protocols
  • Ports

Action:

  • allow: permit the matching egress connection
  • deny: block the matching egress connection

Ingress cases

Ingress firewall rules protect against incoming connections to the instance from any source. Ingress allow rules allow specific protocol, ports and IP addresses to connect in. The firewall prevents instances from receiving connections on non-permitted ports or protocols. Rules can be restricted to only affect particular sources by any of the following:

  • Source CIDR ranges
  • Source service account on instances
  • Source tags on VM instances (resolve to instance primary internal IP address)

Source CIDR ranges can be used to protect from undesired connections coming to an instance either from external networks or from GCP IP CIDR ranges. In addition, Source Tags can be used to protect from undesired connections coming from specific VM instances that are tagged with a matching tag.

Secure ingress connections

This diagrams illustrate a VM receiving a connection from an external address and another VM receiving a connection from a VM in the same network.

Ingress from external address to VM instance (click to enlarge)
Ingress to VM instance (click to enlarge)

Conditions: Matching inbound connections are constructed using:

  • Source CIDR ranges
  • Protocols
  • Ports
  • Source service account on instances
  • SourceTags on instances (Only for VM-VM connections. Tag resolves to VM primary IP)

Action:

  • allow: permit the matching ingress connection
  • deny: block the matching ingress connection

Connection limits

GCP uses a connection tracking table to support stateful firewall filtering. The maximum number of connections in the table depends on the instance type. Current maximum connections are as follows:

  • 130000 per instance for instances with shared-core machine types
  • 130000 per CPU for instances with 1 to 8 CPUs
  • 130000*8 (1040000) per instance for instances with >8 CPUs

What's next