Cloud NGFW, IAP, Load Balancers and Certificate Authority Service

What it is

The network perimeter on Google Cloud is not one box at the edge. It is a set of controls: Cloud Next Generation Firewall (Cloud NGFW) rules on every VM interface, load balancers that terminate TLS at Google's edge, Identity-Aware Proxy (IAP) that checks identity before traffic reaches an app, and Certificate Authority Service for your own certificates.

How it works

Cloud NGFW tiers

Firewall rules and policies

Hierarchical policies are evaluated first, organization then folder, and their rules can allow, deny or goto_next to pass the decision down. Then the network's VPC firewall rules and network firewall policies are evaluated, and finally the implied rules: deny all ingress, allow all egress. Lower priority numbers win within a policy.

Target VMs by service account or secure tags, not network tags. Network tags can be changed by anyone who can edit the instance; secure tags are controlled with IAM.

gcloud compute network-firewall-policies rules create 1000 \
  --firewall-policy=prod-policy --global-firewall-policy \
  --direction=INGRESS --action=allow \
  --src-ip-ranges=35.235.240.0/20 --layer4-configs=tcp:22 \
  --enable-logging

Layer 7 inspection with Cloud NGFW Enterprise

Cloud NGFW Enterprise inspects packets for exploits, malware and command-and-control traffic. You create a firewall endpoint in a zone, associate it with the VPC network, create a security profile (threat prevention) inside a security profile group, and use a rule with the action apply_security_profile_group.

Matched traffic is sent to the endpoint and blocked or alerted on according to the profile. For encrypted traffic, TLS inspection with a CA from Certificate Authority Service lets the endpoint see inside the session.

Identity-Aware Proxy

IAP checks who the user is and, with access levels, from where, before any request reaches the app.

The backend should verify the signed header x-goog-iap-jwt-assertion, so requests that bypass IAP are rejected.

Load balancers

External Application Load Balancers terminate TLS at Google's edge, absorb many layer 3 and 4 attacks, and are where Cloud Armor attaches. Use SSL policies to set the minimum TLS version and a profile (COMPATIBLE, MODERN, RESTRICTED or CUSTOM), and Google-managed certificates through Certificate Manager. Backends then need only private IPs.

Certificate Authority Service

CA Service runs private certificate authorities that you control, organised in CA pools with root and subordinate CAs. Keys can be protected by Cloud HSM.

Use it for mTLS between services, internal load balancer certificates and TLS inspection by Cloud NGFW and Secure Web Proxy.

Private and public IP addressing

Keep VMs on internal addresses, put public entry points on load balancers, and reach the internet outbound through Cloud NAT.

A worked example

A web app runs on VMs with external IPs and SSH open to the world. The engineer removes the external IPs and adds an external Application Load Balancer with a RESTRICTED SSL policy and IAP. SSH is allowed only from the IAP range for the admin group.

A hierarchical policy on the organization denies inbound traffic from Threat Intelligence lists. Cloud NGFW Enterprise inspects east-west traffic in the production VPC.

How the exam asks about this

• "Administrators need SSH to VMs that have no external IP addresses, without a bastion host." IAP TCP forwarding with a firewall rule allowing 35.235.240.0/20 and the IAP-secured Tunnel User role.
• "Block known malicious traffic to every VPC in the organization, and project teams must not override it." A hierarchical firewall policy on the organization with deny rules.
• "Detect and block exploit attempts in traffic between VMs." Cloud NGFW Enterprise with a firewall endpoint and a threat prevention security profile.