Security in cloud networking is not just about blocking bad actors. It is about managing complexity at scale. In a small project with five VMs, you write a few firewall rules and move on. But when you have a hundred VPCs across fifty projects, managed by twenty teams, with compliance auditors asking for evidence—the simple approach collapses. Google Cloud addresses this with a layered security model that starts at the organization level and trickles down to the individual packet.
The foundation of all network security in Google Cloud is the firewall rule. But the modern exam expects you to understand not just the rules themselves, but the hierarchy in which they are evaluated, the identity mechanisms that control their targets, and the organizational policies that prevent misconfiguration in the first place.
The Evolution: From VPC Rules to Hierarchical Policies
Classic VPC Firewall Rules
These live inside a specific VPC. You write rules like “Allow TCP 80 from 0.0.0.0/0 to instances tagged web-server.” They are simple, effective, and completely localized. If you have ten VPCs, you manage ten separate sets of rules.
Hierarchical Firewall Policies
These live at the Organization or Folder level. A single policy at the Org level cascades down to every VPC in every project underneath it.
- Power: You set a rule at the Org level—”Deny SSH from all external IPs”—and it applies to every VM in the company. Developers cannot override it.
- Delegation with
goto_next: Not every rule needs to be absolute. You can set a rule togoto_next, which means “I’m okay with this traffic, but I defer the final decision to the VPC-level rules.”
Evaluation Order
- Organization-level Hierarchical Policy.
- Folder-level Hierarchical Policy.
- VPC Network Firewall Rules (allow/deny).
If a hierarchical policy sets “Deny” at the Org level, no VPC rule can override it. If it sets “goto_next,” the VPC rules get the final say.
The Identity Shift: Service Accounts vs. Network Tags
Classic firewalls use Network Tags as targets—you tag a VM as web-server and write rules against that tag. The problem? Any user with compute.instances.setTags permission (which includes the broad Editor role) can change the tags. If the firewall blocks them, they simply add an allow-all tag to their VM.
Service Account-based rules solve this. Instead of targeting a tag, you target the identity of the VM:
- Rule: “Allow TCP 443 from any source to VMs running as
[email protected].” - To change a VM’s Service Account, you need
iam.serviceAccounts.actAspermission, which is far more restricted than tag editing.
For the exam, always prefer Service Account-based firewall rules over Network Tags when the requirement mentions “strict security” or “preventing unauthorized rule bypass.”
Identity-Aware Proxy (IAP): The Bastion Killer
The traditional way to access a VM without a public IP was to deploy a “bastion host”—a hardened jump box with a public IP that you SSH into, then pivot to your private VMs. This creates a single point of attack and requires patching another machine.
IAP eliminates the bastion entirely. You connect to Google’s IAP endpoint via your browser or gcloud, Google authenticates you (including MFA and Context-Aware Access checks), and then Google creates an encrypted tunnel from its own IP range (35.235.240.0/20) to your private VM.
- Your VM needs no public IP.
- Your firewall only needs to allow TCP 22 from
35.235.240.0/20. - Every session is logged with the authenticated user’s identity.
Organization Policy Constraints
Beyond firewalls, the Organization Policy Service lets you set guardrails that prevent misconfigurations before they happen:
constraints/compute.vmExternalIpAccess: Deny All. No one in the entire organization can create a VM with a public IP, regardless of their IAM permissions.constraints/compute.restrictVpnPeerIPs: Only allow VPN peering to approved partner IP addresses.constraints/compute.restrictSharedVpcSubnetworks: Control which subnets in a Shared VPC can be consumed by which service projects.
This is “Security by Default.” Instead of reacting to violations, you prevent them structurally.
Putting it Together: A Pro-Engineer View
Imagine you are the security architect for a financial services company with forty projects. You create a Hierarchical Firewall Policy at the Organization level that denies all SSH from external IPs and denies all ICMP. You use goto_next for HTTPS traffic, letting individual project teams decide their own HTTPS rules. All firewall targets use Service Accounts, not tags. You deploy IAP for all administrative access—no bastion hosts, no public IPs. And you set Organization Policies that physically prevent any developer from attaching an external IP to a VM. The result? A network where security is not a checklist but an architectural guarantee.
