Alexis Kestler
If you‘re running applications and infrastructure on Google Cloud Platform (GCP), configuring firewall rules properly is crucial for security. The default GCP firewall rules permit only basic connectivity, so custom rules are needed for most real-world scenarios.
In this detailed guide, I‘ll provide insights drawn from my experience as a GCP cloud architect on best practices for GCP firewall management. You‘ll learn all about creating, structuring, and deploying firewall rules to securely architect cloud environments. Let‘s get started!
Default Firewall Rules – A Good Baseline
Every new project in GCP starts with these default firewall rules already configured:
| Rule | Description |
| default-allow-icmp | Allows ping from any source |
| default-allow-internal | Allows traffic between instances in the network on any port |
| default-allow-rdp | Allows Remote Desktop connections to Windows servers from any source |
| default-allow-ssh | Allows SSH connections to Linux servers from any source |
As you can see, these rules permit basic troubleshooting and connectivity within the network. But most real-world applications will require additional controls for security.
On average, users create 20-50 custom firewall rules per project in addition to the defaults. The good news is that GCP firewalls are completely software-defined – no physical firewall appliances to deal with!
Firewall Rule Precedence and Priority
It‘s important to understand how precedence and priority affect the ordering of firewall rules in GCP:
- Lowest priority value first – Rules with lower priority numbers take effect before higher numbers
- Deny rules before allow – Deny rules are applied before allow rules at the same priority
- First match wins – The first rule that matches is applied, rest are ignored
So in general, you want to structure rules with:
- Most important denies at high priority (low value)
- Less important denies after
- Allows last
This ensures traffic will match your denies before any allows are considered.
Creating and Managing Firewall Rules in the GCP Console
The easiest way to configure firewall rules is through the GCP Console UI. Here are the options:
Name – Lowercase, no spaces (required)
Description – For your future reference (recommended)
Network – Default if only one VPC created
Priority – Start allow rules at 1000, denies earlier
Direction – Ingress or egress traffic
Action – Allow or deny matching traffic
Targets – All instances, specific tags, service accounts
Source filter – IP ranges, tags, service accounts
Protocols/ports – TCP/UDP protocols with specified ports
Let‘s look at some common use cases and how to implement them as firewall rules…
Allow SSH on a non-standard port
- Name:
allow-ssh-port-5000 - Direction:
Ingress - Action:
Allow - Targets:
All instances - Source ranges:
0.0.0.0/0 - Protocols/ports:
tcp:5000
This allows SSH on port 5000 from anywhere, overriding the default SSH rule.
Allow office IP range
- Name:
allow-office-https - Direction:
Ingress - Action:
Allow - Targets:
All instances - Source ranges:
A.B.C.D/24(office IP range) - Protocols/ports:
tcp:443
This permits access to HTTPS only from the office IP range.
Deny suspicious IP address
- Name:
deny-suspicious-ip - Direction:
Ingress - Action:
Deny - Priority:
500 - Source ranges:
X.X.X.X/32(suspicious IP)
High priority deny for a specific malicious IP address.
Best Practices for Structuring Firewall Rules
After creating many firewall rules for various projects, I‘ve developed some best practices:
- Maintain consistent naming conventions for easier management
- Leverage tags and service accounts over IP ranges when possible
- Start with default-deny, then allow specific IPs and ports only as needed
- Combine multiple ports in a single rule when the source and target match
- Place high priority denies early to override allows
- Document rules in a central registry along with business justification
- Regularly review and prune unnecessary rules to keep policy clean
Deploying Firewall Rules as Code
Once you have your firewall rules defined, you can manage them in source code for automated deployments.
For example, you can store rules in a YAML/JSON config file and utilize Terraform or Deployment Manager to provision them. This allows version control, collaboration, and infrastructure as code benefits.
I‘d recommend managing firewall rules in code once you have the initial policy fleshed out. It avoids errors that can occur when manually configuring rules in the Console.
Architecting Networks with Firewall Rules
Firewalls are crucial for segmenting environments into subnets with appropriate access controls. Some architectures that leverage firewall rules:
DMZ – Perimeter network exposed to internet, with tightened firewall rules between DMZ and private subnet. Useful for internet-facing workloads.
Multi-tier – App servers separated from databases with firewall rules allowing traffic only on required ports/protocols.
Microsegmentation – Granular firewall rules between services rather than broad internal network access.
Combining Google Cloud Armor and VPC Firewalls
Cloud Armor provides additional enterprise-grade firewall capabilities on GCP beyond the native VPC firewall. Key differences:
- Layer 7 filtering in Cloud Armor vs layer 3/4 in VPC firewall
- Built-in DDoS protection with Cloud Armor
- Identity-Aware Proxy integrates with IAM roles
- Cloud Armor has integration with load balancers
In general, I recommend using VPC firewall for north-south rules, and Cloud Armor for filtering east-west application traffic within VPCs. They complement each other nicely!
Closing Thoughts
I hope this guide has provided a comprehensive overview of configuring firewall rules on Google Cloud Platform. Properly architecting firewall policies is crucial for governing access and maintaining defense-in-depth.
Feel free to reach out if you have any other questions! I‘m always happy to discuss best practices for securing cloud environments.
