Now that you've learned how to launch Compute Engine VM instances and connect to them via SSH, it's time to focus on one of the most critical aspects of cloud security: controlling network access to your servers. In our previous lesson, you successfully launched instances and connected to them, but you may have noticed that GCP automatically assigned your instances to the default VPC network, which comes with a set of pre-configured firewall rules. While this setup gets you started quickly, it's not ideal for production environments, where you need precise control over who can access your servers and how.

Firewall rules in GCP act as virtual gatekeepers for your VM instances, controlling inbound and outbound traffic at the VPC network level. Think of them as security guards at the entrance to a building — they check every network request against a set of rules and only allow traffic that matches your specifications. Unlike traditional firewalls that might be configured on each server, GCP firewall rules are managed centrally and apply to all resources within a VPC network.

The power of GCP firewall rules lies in their flexibility and precision. You can create different rules for different types of servers — one for web servers that need to accept HTTP traffic from anywhere, another for database servers that should only accept connections from your application servers, and yet another for administrative access that only allows SSH from your specific IP address. You control which VM instances a rule applies to by assigning network tags to your instances and specifying those tags in your firewall rules.

By the end of this lesson, you'll understand how to create custom firewall rules that implement the principle of least privilege — giving each server exactly the network access it needs and nothing more. You'll build both restrictive rules for sensitive servers and more permissive ones for public-facing services, then launch instances that use these carefully crafted security configurations.

GCP firewall rules operate on a simple but powerful concept: they define rules that specify which traffic is allowed to reach your VM instances. Each rule consists of several components that work together to create precise access controls. Understanding these components is essential for building effective security configurations.

Every firewall rule in GCP specifies a direction (ingress or egress), a protocol (such as TCP or UDP), a port or port range, a source (for ingress) or destination (for egress), and a target (which VM instances the rule applies to, specified by network tags). The protocol determines the type of network communication — TCP for most web traffic and SSH connections, UDP for DNS queries and some streaming applications, or ICMP for ping requests. The port or port range specifies which network ports the rule applies to, such as port 22 for SSH, port 80 for HTTP, or port 443 for HTTPS.

The source specification is where GCP firewall rules become particularly powerful. You can allow traffic from specific IP addresses, ranges of IP addresses using CIDR notation, or even from other VPC networks. When you specify 0.0.0.0/0 as the source, you're allowing traffic from anywhere on the internet. When you specify a single IP address followed by /32, like 203.0.113.1/32, you're allowing traffic only from that specific address.

Before creating firewall rules that restrict access to your specific location, you need to determine your public IP address and identify your VPC network. Your public IP address is what your internet service provider assigns to your connection, and it's what GCP sees when you make requests from your computer. The VPC network provides the network context within which your firewall rules will operate.

Your public IP address can change depending on your internet connection. If you're on a home network, your ISP might assign you a different IP address each time you connect. If you're on a corporate network, you might share a public IP address with other users. Understanding your current public IP is essential for creating effective security rules.

You can retrieve your public IP address using a simple shell command:

The curl command with the -s flag (silent mode) queries a public API that returns your IP address, and the $() syntax captures the output into a variable. If the API is unavailable, you can use alternative services:

In GCP, every project comes with a default VPC network, which you can use for your initial experiments. You can list your available networks using the gcloud command-line tool:

The output will look something like this:

For most initial use cases, you can use the default network. When creating firewall rules, you'll specify this network.

Administrative access to your servers should be as restrictive as possible while still being functional. In GCP, you can create a firewall rule that allows SSH access only from your specific IP address and apply it to VM instances using a network tag.

Here's how you can create such a rule using the gcloud command-line tool:

• --network=default specifies the VPC network.
• --direction=INGRESS means the rule applies to incoming traffic.
• --rules=tcp:22 allows TCP traffic on port 22 (SSH).
• --source-ranges=${MY_IP}/32 restricts access to your specific IP address.
• --target-tags=${TAG} means the rule applies only to VM instances with the ssh-admin tag.

When you launch a VM instance, you will assign the ssh-admin network tag to it. Only those instances will be accessible via SSH from your IP.

This approach provides excellent security for administrative access. Even if someone discovers your instance's public IP address, they cannot connect via SSH unless they're connecting from your specific IP address. This significantly reduces the attack surface and protects against brute-force SSH attacks from random internet locations.

Web servers have different security requirements than administrative servers. They need to accept connections from users anywhere on the internet while still maintaining appropriate security controls. In GCP, you can create firewall rules that allow HTTP and HTTPS traffic from anywhere, and apply them to VM instances using a network tag.

Important: While web traffic (HTTP/HTTPS) should be accessible from anywhere, SSH access should follow the principle of least privilege. The example below shows SSH allowed from anywhere for demonstration purposes only. In production environments, use one of these secure alternatives:

• IP-restricted SSH: Use your specific IP address (${MY_IP}/32) like in the admin server example
• OS Login: Enable OS Login to manage SSH access through IAM without firewall rules
• Identity-Aware Proxy (IAP) TCP forwarding: Use IAP to connect without exposing SSH ports to the internet at all

Here's how you can create these rules using the gcloud command-line tool:

A superior approach for SSH access eliminates the need for public SSH firewall rules entirely. IAP TCP forwarding allows you to connect to instances through Google's infrastructure without exposing SSH ports:

The source range 35.235.240.0/20 represents Google's IAP IP range, which is used when you connect through IAP. This approach provides strong security without requiring you to manage IP allowlists or VPNs.

Once you've created your custom firewall rules, you need to launch VM instances with the appropriate network tags so that the rules apply to them.

You can launch a VM instance with a specific network tag using the gcloud command-line tool:

• The --tags flag assigns one or more network tags to the instance.
• The firewall rules you created earlier will apply to instances with the matching tags.

After the instance is created, you can view its external IP address using:

The output will show the instance name, zone, and external IP address, which you can use to connect to the instance.

Understanding how to create and apply firewall rules is just the beginning. In real-world applications, you'll want to follow several best practices to maintain strong security while ensuring your applications remain functional and manageable.

The principle of least privilege should guide all your firewall rule decisions. Start with the most restrictive rules possible and only open additional access when specifically needed. For example, if your application only needs HTTP access, don't also open HTTPS unless you're actually using SSL certificates. If your database only needs to accept connections from your application servers, don't allow connections from the entire internet.

Consider using multiple network tags for complex applications. You might have one tag for web server access, another for database access, and a third for administrative access. You can assign multiple tags to a single instance, and the rules for all tags will be combined. This approach makes it easier to manage permissions and reuse security configurations across different types of servers.

Regular review and maintenance of firewall rules are essential. As your infrastructure evolves, you may find that certain rules are no longer needed or that new rules are required. Periodically audit your firewall rules to ensure they still match your current requirements and remove any unnecessary access.

Documentation becomes crucial as your firewall rule collection grows. Use descriptive names and detailed descriptions for your firewall rules, and maintain documentation about which applications and servers use each rule. This information will be invaluable when troubleshooting connectivity issues or planning infrastructure changes.

Testing your firewall rule configurations is important before deploying to production. Create test instances with your firewall rules and verify that the intended traffic is allowed while unwanted traffic is blocked. This testing can prevent both security vulnerabilities and connectivity problems in your production environment.