Google Cloud Platform (GCP)
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.
Firewall rules in GCP
Every VPC network also functions as a distributed firewall. While firewall rules are applied to the network as a whole, the 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.
When you specify a rule, GCP assigns it to every instance in the network unless you restrict that assignment. 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.
directionof the rule. Inbound connections are matched again
ingressrules only, and outbound connections are matched against
sourceof the connection for
ingresspackets, or the
destinationof the connection for
portof the connection.
actionof the rule, which is to allow or deny packets that match the direction, protocol, port, and source or destination of the rule.
priorityof 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
- 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
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.
allowrules allow connections matching the specified conditions to arrive or leave instances, depending on the
directionof the rule.
denyrules deny connections matching the specified conditions from arriving at or leaving instances, depending on the
directionof the rule.
You cannot specify both
deny in the same firewall
rule. However, you can specify multiple overlapping or conflicting
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
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
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
inclusive. When unspecified, a priority value of
1000 is given. A lower
priority "number" indicates higher priority, so a rule with a priority of
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.
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
- Using service accounts: You can create the instances using a specific
service account, then specify that service account in the
In both cases, the
allow 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
Rule assignment and service accounts
Firewall rules can be assigned to instances based on IAM service accounts. For instances, service accounts authenticate applications running on your virtual machine instances to other GCP services. In other words, the service account is the identity of the application running on the instance.
When you autoscale applications, you can create and manage groups of instances with a given service account using instance templates. You can use this mechanism to automatically create new instances with the correct service account.
You can create firewall rules based on the service accounts in the project where you are creating the rules. In addition, you can use service accounts from linked Shared VPC projects. You cannot use service accounts from linked VPC Network Peering projects.
In general, 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
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 may 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.
- 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|
(Default: All ports)
Src IP CIDR OR
Source Service Account
no target tag OR target service account)
(Default: All ports)
Dst IP CIDR
no target tag OR target service account)
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 or a target service account can be used in the same firewall rule.
- If either a source service account or target service accounts are 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
- A default "deny ingress" rule.
Deny all ingress connection. Rule has a priority of
In addition, a project's
default network is created with the following
default firewall rules. These rules can be deleted if necessary.
Allows ingress network connections of any protocol and port between VM instances on the network. Rule has a priority of
Allows ingress TCP connections from any source to any instance on the network over port 22. Rule has a priority of
Allows ingress ICMP traffic from any source to any instance on the network. Rule has a priority of
Allows ingress remote desktop protocol traffic to TCP port 3389. Rule has a priority of
If you want these rules to exist in VPC networks that you create, you must configure them yourself.
GCP firewall use 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 connections from a VM instance can be controlled as follows.
Conditions: Matching outbound connection are constructed using:
- Destination CIDR ranges
allow: permit the matching egress connection
deny: block the matching egress connection
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 either of the following:
- Source CIDR ranges
- 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.
Conditions: Matching inbound connections are constructed using:
- Source CIDR ranges
- SourceTags on instances (Only for VM-VM connections. Tag resolves to VM primary IP)
allow: permit the matching ingress connection
deny: block the matching ingress connection
- 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
- See Using Firewall Rules for instructions on creating and working with firewall rules