Securing communications and boundary protection

Perimeter security

Cloud Next Generation Firewall (Cloud NGFW)

Cloud NGFW is the distributed, stateful firewall built into the VPC network. It enforces rules at the VM’s network interface, not at a choke point, so traffic between VMs in the same subnet can be filtered.

Policy types and evaluation order

Order: organization policy, folder policies, then VPC firewall rules and global network policies (the order between those two is configurable), then regional network policies. Within a policy, rules run by priority (lower number = higher priority, 0 to 65535). Rule actions are allow, deny and, in hierarchical policies, goto_next (delegate the decision to the next level). Every VPC also has implied rules at the lowest priority: deny all ingress and allow all egress. Rules are stateful, so return traffic is allowed.

Targets and match fields

• Targets: all instances, service accounts, network tags, or secure tags.
• Secure tags (resource-manager tags) are governed by IAM, so only authorised people can attach them. Network tags can be set by anyone with edit rights on the VM. Prefer service-account targets or secure tags in locked-down environments.
• Match on IP ranges, address groups, FQDNs, geolocation, and Google Threat Intelligence lists (Standard and Enterprise tiers).
• Firewall rules logging and Firewall Insights show hits and shadowed or unused rules.

Tiers: Essentials (stateful L3/L4 rules), Standard (adds FQDN, geolocation, threat intelligence), and Enterprise, which adds layer 7 inspection: an intrusion prevention service (IPS) that detects and can block threats, and TLS inspection.

Layer 7 inspection with Cloud NGFW Enterprise

1. Create a firewall endpoint (zonal, organisation-level) that runs the inspection engine.
2. Create a security profile (threat prevention, with per-severity actions) and a security profile group.
3. Associate the endpoint with the VPC, and write a firewall policy rule whose action is apply_security_profile_group. Matching traffic is sent to the endpoint for inspection.
4. For encrypted traffic, add a TLS inspection policy that uses a CA pool from Certificate Authority Service and a trust config. Clients must trust the CA.

Cloud NGFW Enterprise blocks, whereas Cloud IDS (see the operations notes) only detects.

Identity-Aware Proxy (IAP)

IAP puts an identity-and-context check in front of an app or admin protocol, so you stop relying on network location (a zero-trust model).

• IAP for web apps protects apps behind an external or internal Application Load Balancer, App Engine, Cloud Run or GKE. Users need roles/iap.httpsResourceAccessor. The app should verify the signed x-goog-iap-jwt-assertion header, and the backend must only be reachable through the load balancer, or IAP can be bypassed.
• IAP TCP forwarding gives SSH/RDP to VMs with no external IP and no VPN. Firewall must allow ingress from 35.235.240.0/20 (IAP’s range) to ports 22 or 3389. Users need roles/iap.tunnelResourceAccessor.
• Add access levels (device, location) from Access Context Manager for context-aware access.
• IAP also supports on-premises apps through IAP connectors.

Load balancers and TLS

• SSL policies set the minimum TLS version and cipher profile (COMPATIBLE, MODERN, RESTRICTED, CUSTOM) on target HTTPS and SSL proxies. Use RESTRICTED or a minimum of TLS 1.2 for compliance.
• Certificates: Google-managed (no private key handling), self-managed, or Certificate Manager. Mutual TLS (client certificate authentication) is supported on the Application LB using trust configs.
• Terminate TLS at the LB and use HTTPS to backends for end-to-end encryption.

Certificate Authority Service

CA Service is a managed private CA. You build CA pools containing root and subordinate CAs, set certificate templates and issuance policies, and keep CA keys in Cloud KMS or Cloud HSM. Two tiers: DevOps (high volume, short-lived certs) and Enterprise (long-lived, revocation lists). Uses: internal TLS, mTLS for service mesh, TLS inspection in Cloud NGFW and Secure Web Proxy, workload certificates for GKE.

Public and private IP addressing

• Prefer private IPs (RFC 1918) for everything that doesn’t need to be reachable from the internet. Prevent accidental external IPs with the org policy compute.vmExternalIpAccess.
• Give private VMs outbound access through Cloud NAT and Google API access through Private Google Access or Private Service Connect.
• Use IAP TCP forwarding or a bastion for administration, never public SSH.
• Reserve static external IPs only where required, and allow listing (for example on partner firewalls) is the usual reason.

Cloud Armor

Cloud Armor is the WAF and DDoS defence for traffic that passes through Google’s edge.

Remember: Cloud Armor sits in front of load balancers. Traffic that reaches a VM’s external IP directly bypasses it, so firewall the backends to accept only the LB and health check ranges. Actions are allow, deny(403|404|502), throttle, rate_based_ban, redirect.

Secure Web Proxy

Secure Web Proxy is a managed explicit forward proxy for outbound HTTP and HTTPS from workloads in a VPC. Use it to restrict egress to approved destinations.

• Deployed as a gateway in a region with a proxy-only subnet and an internal IP that clients use as their proxy.
• Policies hold rules written with URL lists, hostnames and CEL session or application matchers (source service account, secure tag, destination), with allow or deny.
• Can do TLS inspection using a CA Service pool, to inspect encrypted traffic and enforce URL-level rules.
• Contrast: Cloud NAT gives outbound reachability without filtering. Firewall FQDN rules filter at the hostname level on L3/L4. Secure Web Proxy gives URL path-level control and logging.

Cloud DNS security

• DNSSEC signs public zones to prevent spoofing and cache poisoning. Enable it on the zone and add the DS record at the registrar.
• Private zones are visible only to chosen VPC networks. Use split-horizon (private and public zone of the same name) deliberately.
• DNS policies: inbound forwarding (on-premises resolvers query Cloud DNS through the VPC) and outbound/forwarding zones (VPC queries on-premises), plus response policies to override or block names (and force *.googleapis.com to restricted or private VIPs).
• DNS peering shares a zone between VPCs without full VPC peering.
• Turn on Cloud DNS logging to capture queries for detection of exfiltration and malware lookups.
• Guard against subdomain takeover: remove dangling CNAMEs to deleted services.

Continually monitoring and restricting APIs

• Enable only the APIs a project needs, and restrict with gcp.restrictServiceUsage (allowed list) so teams cannot turn on arbitrary services.
• VPC Service Controls restrict which Google APIs a perimeter exposes. API keys should have API restrictions and application restrictions (HTTP referrer, IP, app ID), and prefer short-lived OAuth or service accounts over keys.
• Use Cloud Asset Inventory and Security Command Center to detect newly enabled APIs, unrestricted keys and public endpoints. Review Admin Activity audit logs for EnableService.

Boundary segmentation

VPC design

• Custom-mode VPCs with planned subnets. Avoid auto mode and the default network (permissive default rules, same ranges in every project).
• VPC networks are global, subnets regional. Separate VPCs (or projects) for production, non-production and regulated workloads.
• VPC peering connects two VPCs privately. It is non-transitive, needs non-overlapping ranges, and doesn’t share firewall rules. You choose whether to export custom routes.
• Shared VPC has a host project that owns the network and service projects that attach resources. It centralises network and firewall control with the network team. Grant compute.networkUser on specific subnets to service project users, compute.xpnAdmin for the Shared VPC admin. Org policy compute.restrictSharedVpcSubnetworks and compute.restrictSharedVpcHostProjects constrain use.
• Choose Shared VPC when one team governs the network and peering when separate organizations or teams need to connect with full autonomy.

N-tier isolation

For web, app and data tiers: put each in its own subnet (or use identities as the boundary), use firewall rules by service account or secure tag (so rules follow the workload, not the IP), allow only the needed flow (web to app on one port, app to database on another), use internal load balancers between tiers, and keep the database with no external IP. Add Private Service Connect or private services access for managed databases. Encrypt in transit between tiers, using TLS or mTLS with CA Service.

VPC Service Controls

VPC Service Controls (VPC-SC) creates a service perimeter around Google-managed services and projects to stop data exfiltration through the APIs, even by someone with valid IAM credentials.

Key points:

• VPC-SC protects against stolen credentials, misconfigured IAM and insiders copying data to an outside project. It doesn’t replace IAM. Both must allow the call.
• It covers service APIs (BigQuery, Cloud Storage, Pub/Sub, and many more). It is not a packet firewall.
• To use it from on-premises or from VMs without internet, combine with restricted.googleapis.com (VIP range 199.36.153.4/30) so traffic can only reach VPC-SC-supported services.
• Violations are written to audit logs as VPC_SERVICE_CONTROLS policy violations with a unique ID. Use the VPC-SC violation troubleshooter with that ID to find the rule you need.
• Frequently needs exceptions for Cloud Build, logging sinks, Pub/Sub subscriptions to other projects, BigQuery data transfer, and Cloud KMS in another project.
• Use cases: keep BigQuery data from being copied out, isolate PCI or healthcare datasets, enforce that only on-premises and corporate IPs reach sensitive buckets.

Private connectivity

Between VPCs and projects

PSC comes in three forms: endpoints for Google APIs, endpoints/backends for published services (a producer creates a service attachment, consumers choose automatic or manual acceptance), and Private Service Connect interfaces.

Private access to Google APIs

Between data centre and Google Cloud

Classic VPN is being retired, so choose HA VPN. For compliance requiring both private path and encryption, answer HA VPN over Interconnect or MACsec on Dedicated Interconnect.

Cloud NAT

Cloud NAT gives outbound-only internet access to VMs, GKE nodes, Cloud Run and functions (via connectors) without external IPs. It is regional, configured on a Cloud Router, doesn’t allow unsolicited inbound connections, supports manual static IPs (for partner allow lists), and has NAT logging. Private NAT translates between private networks (overlapping ranges, hybrid).

Choosing the control

Common traps

• Network tags can be changed by anyone who can edit the VM. For security boundaries use service accounts or secure tags.
• Cloud Armor does nothing for traffic that goes straight to a VM IP.
• VPC peering does not carry transit traffic, and it doesn’t copy firewall rules.
• Interconnect is private but not encrypted by default.
• IAP TCP needs the 35.235.240.0/20 firewall rule, or it fails.
• VPC-SC blocks things you didn’t expect (cross-project Pub/Sub, KMS). Use dry-run first.
• Priority 0 is the highest firewall priority.