VPC Firewall Rules and Policies

Introduction to VPC Firewall Rules and Policies

In Google Cloud, the network is defined by software, and security is enforced at the individual VM level, not just at the perimeter. VPC Firewall Rules are distributed virtual firewalls that control traffic to and from Compute Engine instances.

For a Professional Cloud Security Engineer (PSE), mastering firewalls is about moving beyond simple IP-based rules. It involves understanding Hierarchical Firewall Policies for organization-wide governance, using Service Accounts for dynamic micro-segmentation, and leveraging Firewall Insights to optimize your security posture.

白話文解釋（Plain English Explanation）

1. The Room-Level Security (VPC Firewall)

Traditional firewalls are like the front door of a building. Once you're inside, you can go anywhere. Google Cloud firewalls are like having a security guard at the door of every single room (VM). Even if someone breaks into the lobby (VPC), they still have to pass the guard at each specific room to move laterally.

2. The Universal Building Code (Hierarchical Policy)

Imagine a city where every building owner sets their own fire rules. This is like project-level firewalls. Now imagine the city government (Org/Folder level) mandates that "No building can have a flamethrower." This is a Hierarchical Firewall Policy. It applies to everyone in the city, and individual building owners cannot override it to be less secure.

3. The Badge System (Service Accounts vs. Tags)

Network Tags are like sticking a "Developer" label on your shirt. Anyone can put on a label. Service Accounts are like an official company ID badge. To get the badge, you must be vetted (IAM). The firewall checks your badge, not your label, making it much harder to spoof your identity and bypass security.

Ingress and Egress Rule Logic

VPC firewalls are stateful. If an ingress (incoming) request is allowed, the egress (outgoing) response is automatically allowed, regardless of egress rules.

• Ingress Rules: Control traffic entering the VM. (Default: Deny all).
• Egress Rules: Control traffic leaving the VM. (Default: Allow all).

Targets: Network Tags vs. Service Accounts

This is a critical PSE concept.

Network Tags

• Simple strings (e.g., web-server, db-server).
• Any user with compute.instanceAdmin can change tags on a VM.
• Risk: A developer could tag a DB server as a "web-server" to gain unauthorized network access.

Service Accounts

• Uses the identity of the VM (e.g., [email protected]).
• Requires iam.serviceAccountUser permission to assign.
• Security: Provides much stronger "Identity-based" micro-segmentation. If a VM's identity is verified, the firewall rule is more trustworthy.

Hierarchical Firewall Policies

Hierarchical policies allow you to enforce rules at the Organization or Folder level.

• Evaluation Order: Org-level rules → Folder-level rules → Project-level (VPC) rules.
• Actions: ALLOW, DENY, and GOTO_NEXT.
• GOTO_NEXT: This is unique to hierarchical policies. It allows a packet to pass the Org level and be evaluated by the Folder or Project level.

Firewall Rule Logging and Auditing

Logging is essential for troubleshooting and compliance.

• Firewall Logging: Can be enabled per rule. It captures source IP, destination IP, port, and protocol.
• Sampling: You can sample logs (e.g., only log 10% of traffic) to save on storage costs.
• Metadata: Logs include the VM name and project ID, making it easy to identify the source of suspicious traffic.

Prioritization and Rule Evaluation Order

Firewall rules have a Priority (0 to 65535).

• Lower number = Higher priority. (e.g., Priority 1000 wins over Priority 2000).
• If multiple rules match, the highest priority rule is applied.
• If priorities are equal, the "Deny" rule usually takes precedence in hierarchical policies, but for VPC rules, it's the first match.

Global Network Firewall Policies

Unlike standard VPC rules that are local to a specific VPC, Global Network Firewall Policies allow you to define a batch of rules and associate them with multiple VPCs in different regions or even different projects (in a Shared VPC environment).

Shared VPC Firewall Management

In a Shared VPC setup:

• The Host Project admin manages the firewall rules.
• Service Project admins cannot create firewall rules that apply to the shared subnets.
• This ensures that the central security team maintains control over the network boundary.

Identifying Orphaned or Redundant Rules

Over time, firewall rules become cluttered.

• Firewall Insights: A tool that analyzes your firewall rules and identifies:
  • Shadowed Rules: Rules that will never be triggered because a higher-priority rule matches the same traffic.
  • Overly Permissive Rules: Rules that allow too much traffic (e.g., 0.0.0.0/0 on all ports).
  • Unused Rules: Rules that haven't seen any traffic in the last 30 days.

Migrating from Tags to Service Account Targets

To improve security, you should migrate existing tag-based rules.

1. Identify the Service Account used by the VMs currently using the Tag.
2. Create a new Firewall Rule using the Service Account as the target.
3. Set the new rule to a higher priority (lower number).
4. Monitor logs to ensure traffic is hitting the new rule.
5. Delete the old tag-based rule.

CLI Commands for Firewalls

Creating an Ingress Rule (Service Account)

gcloud compute firewall-rules create allow-app-to-db \
    --network=my-vpc \
    --action=ALLOW \
    --direction=INGRESS \
    --priority=1000 \
    --source-service-accounts=app-srv@my-project.iam.gserviceaccount.com \
    --target-service-accounts=db-srv@my-project.iam.gserviceaccount.com \
    --rules=tcp:5432

Listing Hierarchical Policies

gcloud compute firewall-policies list --organization=123456789

Security Best Practices for PSE

1. Implicit Deny All: Always start with a default "Deny All" egress rule for high-security environments.
2. Least Privilege: Open only specific ports (e.g., tcp:443) rather than "All protocols."
3. Use Service Accounts: Avoid Network Tags in production.
4. Audit Logs: Enable logging for all "Deny" rules to detect port scanning and reconnaissance.
5. Hierarchical Guardrails: Use Org-level policies to block high-risk ports (RDP, SSH, Telnet) from the internet.

Troubleshooting Scenarios

Scenario: VM can't connect to a DB despite an "Allow" rule

Diagnosis: Check for an Egress rule on the source VM. Even if Ingress is allowed on the DB, the source VM must be allowed to send traffic out on that port. Also, check the priority of any existing "Deny" rules. Fix: Add an egress rule for the source VM or increase the priority of the allow rule.

Scenario: Hierarchical Policy is blocking traffic in a Dev project

Diagnosis: The Org-level policy has a DENY rule that matches the traffic. Project-level rules cannot override an Org-level DENY. Fix: Change the Org-level rule to GOTO_NEXT for the specific IP range or port, allowing the Dev project to manage its own rules for that traffic.

PSE Exam Scenarios

Scenario 1: Preventing Lateral Movement

"How can you ensure that compromised web servers cannot access the administrative ports of database servers, even if they are in the same subnet?" Answer: Use firewall rules with Service Account targets. Assign the web servers to sa-web and the DB servers to sa-db. Create a rule allowing only specific DB ports (e.g., 3306) from sa-web to sa-db, and rely on the default "Deny" for all other ports.

Scenario 2: Centralized Compliance

"Your CISO requires that no developer can ever open port 21 (FTP) to the internet in any project. What is the most robust way to enforce this?" Answer: Create a Hierarchical Firewall Policy at the Organization level with a DENY rule for ingress on port 21 from 0.0.0.0/0.

Summary Checklist

• Explain the difference between Ingress and Egress rules.
• Contrast Network Tags with Service Accounts as firewall targets.
• Describe the evaluation order of Hierarchical Firewall Policies.
• Identify the function of GOTO_NEXT in hierarchical policies.
• Understand how to use Firewall Insights to optimize rules.