Network Perimeter Controls with NGFW and IAP

Certificate Authority Service (CA Service) (opens in a new tab) is Google Cloud's managed private public key infrastructure (PKI) service for issuing, renewing, and revoking digital certificates inside an organization. Certificate Manager (opens in a new tab) works with CA Service to provision Google-managed certificates issued by a private certificate authority (CA) pool and deploy them to load balancers at the network perimeter. Together, the services provide automated Transport Layer Security (TLS) encryption and authentication for traffic flowing from internet clients to load balancers and from load balancers to internal services.

1.1Private PKI Hierarchy with Certificate Authority Service

Private PKI hierarchy with Certificate Authority Service is the chain of trust that lets workloads verify perimeter certificates. An administrator creates a root CA and subordinate CAs in CA Service, and workloads trust certificates because they chain back to that root. Certificate templates define what a certificate can contain, such as allowed domains, key usages, and validity periods, while issuance policies control which identities can request certificates and under what conditions. The hierarchy depends on continuous operations for compliance, including maintaining certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders so compromised or expired certificates can be revoked and validated.

1.2Google-Managed Certificates for Perimeter Load Balancers

Google-managed certificates for perimeter load balancers are TLS certificates whose lifecycle is handled by Certificate Manager using a CA Service pool as the issuer. Certificate Manager sends the certificate request to the CA Service pool, receives the signed certificate, and stores it as a Certificate Manager certificate resource. The certificate then flows from the certificate resource to a certificate map entry and to the target HTTPS proxy, which presents the certificate to clients during the TLS handshake.

This integration is supported for global perimeter entry points:

• Global external Application Load Balancer
• Classic Application Load Balancer
• Global external proxy Network Load Balancer
• Classic proxy Network Load Balancer

Cross-region and regional load balancers use separate regional or cross-region certificate workflows. Choose the global workflow when the target proxy serves global external traffic through one of the four load balancers above.

1.3Certificate Maps for Scale and Selection

A certificate map is the Certificate Manager resource that binds hostnames to certificates for a load balancer's target proxy. The target proxy references the map, and during the TLS handshake the load balancer selects the certificate whose map entry matches the client's requested hostname. Certificate maps are designed to scale, supporting thousands of certificate entries by default and capable of handling millions of certificates for large perimeters.

When a load balancer uses a certificate map, certificate map entries take precedence over other certificates, such as Compute Engine SSL certificates attached to the same proxy. If a client's hostname does not match any entry in the provisioned certificate map, the load balancer returns the primary certificate defined in the map. This fallback behavior makes the choice of primary certificate a perimeter decision, because unmatched clients will still complete a handshake with that certificate.

1.4Choosing Domain Authorization for Issuance

Choosing domain authorization for issuance is the decision about how to prove control of domains before a Google-managed certificate can be issued. Certificate Manager supports load balancer authorization and DNS authorization for this proof, and the choice controls setup work, network requirements, and wildcard support.

Choose load balancer authorization when the global load balancer is already serving public traffic on port 443 and you need the simplest issuance path. Choose DNS authorization when you need wildcard certificates, need to provision before cutover, or terminate TLS behind a content delivery network (CDN) or on a nonstandard port.

1.5Automating Renewal and Rotation Lifecycle

Automating renewal and rotation lifecycle is the process for replacing certificates without dropping perimeter traffic. Google-managed certificates issued by CA Service renew automatically through Certificate Manager, while self-managed certificates must be replaced manually before they expire. Automating replacement with Certificate Lifecycle Management tooling reduces errors and downtime from expired certificates.

Certificate maps orchestrate a seamless rotation of a self-managed certificate through an ordered workflow:

1. Monitor expiration: Cloud Monitoring tracks certificate expiry and sends alerts, with alerts recommended for certificates expiring in the next 15 to 30 days.
2. Generate request: The operator generates a certificate signing request (CSR) and private key to submit to the CA.
3. Submit and retrieve: The operator submits the CSR and private key to the CA and retrieves the new signed certificate.
4. Upload and rebind: The operator uploads the new certificate to Certificate Manager in the appropriate certificate map. If domain names match the about-to-expire certificate, use the UpdateCertificate method on the existing certificate resource. If the new certificate has different domain names, first use the CreateCertificateRequest method with the new privacy-enhanced mail (PEM) files, then use the UpdateCertificateMapEntry method to replace the old certificate reference with the new one in one API call without downtime.

The final rebind step is order-sensitive because traffic flows from clients to the target proxy to the certificate map entry. Completing the map entry update in one API call ensures the proxy never serves a gap where neither the old nor the new certificate is bound.

1.6Enforcing Least Privilege and Separation of Duties

Enforcing least privilege and separation of duties for PKI separates who runs the infrastructure from who can obtain certificates. When assigning permissions to manage certificates, grant the minimum permissions needed and avoid basic Identity and Access Management (IAM) roles. Instead, grant predefined or custom Certificate Manager and CA Service roles so certificate operators cannot alter CA policy and CA administrators cannot issue themselves certificates without oversight.

Separation of duties requires distinct identities for certificate administrators versus certificate issuers and requesters, typically implemented as separate administrator and requester groups at the top of the resource hierarchy. The administrators group is responsible for:

• Managing and maintaining certificate infrastructure such as CA provisioning
• Configuring certificate templates
• Managing certificate revocation lists and OCSP responders
• Implementing security policies for the CA

This split ensures the policy that defines trust, including templates, revocation, and CA security policy, is controlled by the administrators group, while day-to-day issuance flows through the requester path under least privilege.

Granular access with Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) and Identity-Aware Proxy (IAP) (opens in a new tab) combines distributed network enforcement with identity-based enforcement to build a zero-trust perimeter. Cloud NGFW filters traffic at the organization, folder, and Virtual Private Cloud (VPC) network levels based on network attributes and threat signals, while IAP authorizes each request to an application based on user, device, and location context. Together they replace implicit trust in network location with explicit verification at both the packet layer and the access layer.

2.1Layered Firewall Enforcement with Cloud NGFW

Layered firewall enforcement with Cloud NGFW is distributed, stateful filtering applied on each virtual machine (VM) instance regardless of its operating system or boot state. Rules are organized in hierarchical firewall policies at the organization and folder levels for central guardrails, plus global and regional network firewall policies and VPC firewall rules at the network level for workload-specific controls. Because enforcement is distributed to every VM, traffic between VMs in the same network is protected without routing all flows through a single chokepoint appliance.

Granularity comes from rule targets rather than from creating many networks. A rule can apply to VMs selected by IAM-governed Tags, service accounts, or network tags, so only VMs with the tag frontend can reach VMs with the tag backend, for example. Centralized administration uses Shared VPC (opens in a new tab), where the host project owns subnets and firewall policies and service projects attach workloads to approved subnets. To stay within per-VM rule programming limits, combine multiple ports or protocols into one complex rule definition instead of writing one rule per port.

2.2Designing Rules from Traffic Patterns and Application Requirements

Designing rules from traffic patterns and application requirements starts by separating north-south traffic from east-west traffic. North-south traffic flows between the internet or on-premises and workloads in Google Cloud, while east-west traffic flows between tiers or services inside Google Cloud, such as presentation to application to data. East-west inspection detects and blocks lateral movement if one tier is compromised, so three-tier designs place each tier in a separate VPC network or isolated segment and require firewall authorization for tier-to-tier flows.

Limit external exposure before writing allow rules. Assign external IP addresses only to resources that need internet access, use organizational policies to restrict which resources can receive external addresses, and let private-only VMs reach Google APIs through Private Service Connect or Private Google Access. For outbound internet access from private VMs, choose Secure Web Proxy when traffic is HTTP(S) and needs identity controls, and choose Cloud NAT otherwise. Use VPC Flow Logs, Firewall Rules Logging, and firewall policy rules logging to establish a baseline of normal behavior, verify that deny rules actually block, and tighten overly permissive rules.

2.3Threat Intelligence and Intrusion Prevention with Layer 7 Inspection

Threat intelligence and intrusion prevention with Layer 7 inspection adds application-layer scanning to Layer 3 and Layer 4 firewall policy rules. The service depends on Google-managed zonal firewall endpoints that use packet-intercept technology to transparently receive matched traffic and scan it with threat-prevention technologies powered by Palo Alto Networks. Supported threat signature categories are anti-spyware, vulnerability protection, and antivirus, and Cloud NGFW Enterprise capabilities that enable this inspection are available only through firewall policies, not through legacy VPC firewall rules.

Inspection follows an ordered sequence where each step depends on the previous step:

1. Firewall policy rule match: Firewall policy rules in hierarchical or global network firewall policies are applied to traffic to and from VM instances or Google Kubernetes Engine (GKE) clusters.
2. Intercept and redirect: Matched traffic is intercepted and its packets are sent from the workload path to the firewall endpoint in the same zone for Layer 7 inspection.
3. Signature scan: The firewall endpoint scans the packets against the configured threat signatures and threat-intelligence feeds referenced by the policy.
4. Preventive action: If a threat is detected, the firewall endpoint applies the action defined in the associated security profile, such as block or alert, to that packet.

Two policy objects control that behavior. A security profile of type threat-prevention defines overrides for specific threat scenarios and can be created at the organization or project level. A security profile group bundles profiles for use by firewall rules and can contain a maximum of one security profile per threat-prevention type per group. Firewall policy rules then reference the security profile group to enable detection and prevention for the selected traffic, so the rule selects which traffic to inspect and the group defines how threats are handled.

2.4Context-Aware Access with Identity-Aware Proxy

Context-aware access with Identity-Aware Proxy is the access-control layer that shifts enforcement from the network perimeter to individual users and devices. IAP authenticates every user and device before granting access to an application or VM, validates context such as user role, device posture, and location, and then grants least-privilege access to only the necessary resource. No request is trusted because it comes from inside the VPC network, which implements the assume-breach mindset of continuous verification.

IAP policies integrate with network controls rather than replacing them. A firewall rule must still allow traffic from IAP to reach the protected VMs, while the IAP policy decides who can use that path under what conditions. Identity strength comes from federation with a single identity provider (IdP), single sign-on (SSO) for users, and multi-factor authentication (MFA) for privileged accounts, including hardware keys. Workload identity uses service accounts with least privilege and Workload Identity Federation for GKE or external workloads, plus just-in-time privileged access and separation of duties to avoid overprovisioning.

2.5Choosing Perimeter Controls by Traffic and Trust Boundary

Choosing perimeter controls by traffic and trust boundary means matching each control to the boundary it protects and the signal it evaluates. Cloud NGFW, IAP, VPC Service Controls, and Google Cloud Armor divide perimeter work by network, identity, data, and edge signals rather than overlapping each other.

Traffic flows from the client to the edge control first, then to the identity control, then to the network control. A request arriving through a load balancer is first evaluated by Cloud Armor security policies at the edge, then authenticated and authorized by IAP based on identity and context, then filtered by Cloud NGFW rules on the destination VM based on network attributes and threat verdict. Sensitive data flows are additionally contained because VPC Service Controls blocks movement of data across the service perimeter boundary even when network and identity checks pass.

Secure application delivery with load balancers means placing the correct load balancer at the correct boundary and then enforcing inspection before traffic reaches backends. Global external Application Load Balancers (opens in a new tab) and global external proxy Network Load Balancers (TCP/SSL) terminate internet traffic at the edge, while regional external passthrough Network Load Balancers (TCP/UDP) and regional internal Application Load Balancers control regional and internal flows. Google Cloud Armor (Cloud Armor) (opens in a new tab) attaches to backend services to allow, deny, rate-limit, or redirect at the edge, and Cloud Next Generation Firewall controls traffic to internal Envoy proxies.

3.1Select Global or Regional Load Balancers for Secure Delivery

Select global or regional load balancers for secure delivery based on traffic type and where enforcement must occur. Global external Application Load Balancers, including classic Application Load Balancers, handle HTTP, HTTPS, HTTP/2, and optionally QUIC for Layer 7 routing and filtering. Global external proxy Network Load Balancers and classic proxy Network Load Balancers handle TCP and SSL proxy traffic without full Layer 7 inspection, while regional external passthrough Network Load Balancers handle TCP and UDP and regional internal Application Load Balancers handle internal HTTP(S) inside a VPC.

In Premium Tier, traffic to an external load balancer enters the Google point of presence (PoP) closest to the user and is then carried over Google's global network to the closest backend with capacity. In Standard Tier, traffic enters Google's network through peering, ISP, or transit networks in the region where resources are deployed. This difference determines latency, blast radius, and where Cloud Armor can scrub traffic before it consumes backend resources or enters a VPC.

Supported backends to a protected backend service include instance groups, all network endpoint group (NEG) types supported by the load balancer, and Cloud Storage buckets. For hybrid or multicloud architectures the backends must be internet NEGs or hybrid NEGs, and serverless NEGs are protected only when traffic is routed through a load balancer first. The backend service must use a load balancing scheme of EXTERNAL, EXTERNAL_MANAGED, or INTERNAL_MANAGED and a protocol of HTTP, HTTPS, HTTP/2, UDP, TCP, SSL, or UNSPECIFIED to accept a Cloud Armor policy.

3.2Enforce Cloud Armor Security Policies at the Network Edge

Enforce Cloud Armor security policies at the network edge with ordered collections of rules applied to requests destined for a protected resource. Each rule contains a match condition on Layer 3 through Layer 7 attributes, such as client IP address or CIDR range, geography, autonomous system number (ASN), URL path, request method, headers, and body, plus an action to take when the condition matches. Rules are evaluated in configured priority order and the highest-priority matching rule takes effect.

Cloud Armor security policies (opens in a new tab) enable allow, deny, throttle, rate-based ban, and redirect actions at the Google Cloud edge, as close as possible to the traffic source. Blocking, throttling, or redirecting at the edge prevents unwelcome traffic from consuming backend capacity or entering VPC networks. This edge enforcement applies to:

• All external Application Load Balancers, including classic Application Load Balancers
• Regional internal Application Load Balancers
• Global external proxy Network Load Balancers (TCP/SSL) and classic proxy Network Load Balancers (TCP/SSL)
• Regional external passthrough Network Load Balancers (TCP/UDP)
• External protocol forwarding and virtual machines (VMs) with external IPv4 addresses or external IPv6 ranges on a network interface

A backend service can have two service-level policies at the same time, but it cannot have two backend security policies or two edge security policies simultaneously. If multiple forwarding rules point to one protected backend service, the policy enforces for traffic arriving at every forwarding rule IP address. A policy associated with any backend service cannot be deleted, although a backend service with an associated policy can itself be deleted.

3.3Choose Backend, Edge, and Network Edge Security Policies

Choose backend, edge, and network edge security policies by where traffic is intercepted and what they can protect. Backend security policies filter requests destined for backend services behind Application Load Balancers and proxy Network Load Balancers. Edge security policies filter before cached content is served and are deployed upstream of where Cloud CDN cache resides, near the outermost perimeter. Network edge security policies protect regional passthrough paths, protocol forwarding, and VMs with public IPs.

Backend and edge policies can coexist on the same backend service to provide outer cache filtering plus inner origin filtering. An edge policy cannot be used as a backend policy. When a global external proxy Network Load Balancer or classic proxy Network Load Balancer enforces a deny action, the denial applies only to new connection requests by terminating the TCP connection, and any configured deny status code is ignored.

3.4Harden Backends and Manage Traffic Flows Across the Perimeter

Harden backends and manage traffic flows across the perimeter by controlling how the load balancer proxy reaches application capacity after edge filtering. Traffic flows from the client to the forwarding rule IP address, then through Cloud Armor evaluation at the edge, then over Google's network to the backend service, and finally to instance groups, NEGs, or buckets selected by capacity and locality. Backend security policies with GKE and the default ingress controller follow the same flow, with the policy attached to the backend service that fronts the GKE NEGs.

Capacity and protocol controls shape that flow without replacing filtering. Cloud Load Balancing supports application capacity optimization for globally distributed backends, selection of load balancer product by traffic type, and optional QUIC on load balancers that use Cloud Armor in Premium Tier or Standard Tier. A default throttling policy can be configured to throttle traffic over a user-specified threshold on global external, classic, regional external, regional internal, and global external proxy and classic proxy load balancers. Together, edge allow and deny decisions plus backend capacity, protocol, and health-check reachability determine which requests consume origin resources.

3.5Protect Internal Traffic with Cloud NGFW Firewall Policies

Protect internal traffic with Cloud NGFW firewall policies (opens in a new tab) that provide access control for managed Envoy proxies used by internal Application Load Balancers and internal proxy Network Load Balancers. Those proxies run in a proxy-only subnet and sit between internal clients and backends, so two firewall layers matter: rules that allow the proxies to connect to backend VMs when backends are instance groups or GCE_VM_IP_PORT zonal NEGs, and optional rules that control which clients can reach the forwarding rules, which is especially useful with regional internet NEGs or Private Service Connect NEGs.

Unlike VM targets, ingress to managed Envoy proxies is allowed when no firewall rules apply, so restriction requires an explicit deny baseline plus higher-priority allows. To restrict access, create ingress rules with --target-type=INTERNAL_MANAGED_LB in a policy associated with the VPC network that contains the forwarding rule:

1. Create the policy in scope: Create a regional network firewall policy in the same region as the load balancer, or a global network firewall policy for cross-region coverage.
2. Associate the policy: Associate the policy with the VPC network where the forwarding rule exists to activate its rules on that network.
3. Deny by default: Create a lower-priority ingress deny rule with --src-ip-ranges=0.0.0.0/0 to establish a deny-all baseline for the proxies.
4. Allow approved sources: Create higher-priority ingress allow rules whose --src-ip-ranges include approved client addresses and Google health-check probe ranges so only intended traffic and health checks reach the forwarding rules.

3.6Layer DDoS and Web Application Defenses

Layer DDoS and web application defenses by combining always-on network protection with user-configured application rules. Cloud Armor provides always-on protection from Layer 3 and Layer 4 volumetric and network protocol-based distributed denial-of-service (DDoS) attacks with automated inline mitigation, allowing only well-formed requests through the load balancing proxies. Protection from Layer 7 threats, including HTTP floods, requires a user-configured security policy with proactive rules, including custom rules-language conditions and web application firewall (WAF) coverage. That layered split means network floods are mitigated by default while application abuse must be explicitly defined.

Application-layer controls build on that base with continuously updated intelligence. Preconfigured WAF rules compile dozens of signatures from open source industry standards based on the OWASP ModSecurity Core Rule Set (CRS), with support for CRS 4.22, 3.3, and 3.0 and a recommendation not to use below 4.22, and signatures can be tuned to disable noisy detections. Managed rules use automatically updated threat signatures to cover new CVEs and zero-day patterns, Google Threat Intelligence matches feeds such as Tor exit nodes through evaluateThreatIntelligence(), Adaptive Protection analyzes backend traffic patterns to detect and suggest or auto-apply mitigations for Layer 7 DDoS, and advanced network DDoS protection adds monitoring, alerting, targeted mitigation, and telemetry for passthrough load balancers, protocol forwarding, and public VMs. Complementary layers such as Cloud Intrusion Detection System, Cloud NGFW intrusion prevention system (IPS), firewall Threat Intelligence, and Apigee as an API facade with rate limiting and quotas extend inspection from the edge through the VPC and API tier.

Key Facts

• Certificate Manager provisions Google-managed certificates issued by a Certificate Authority Service pool and binds them to a load balancer target proxy through certificate map entries that match client hostnames.
• Cloud Next Generation Firewall enforces distributed stateful rules on every VM and enables Layer 7 intrusion prevention only when a firewall policy rule references a security profile group.
• Identity-Aware Proxy authenticates every user and device and authorizes access based on user identity, device posture, and location, while a firewall rule must still allow the IAP traffic path to protected VMs.
• Google Cloud Armor evaluates ordered security policy rules at the edge, where a backend service can hold one backend policy plus one edge policy but never two backend policies.
• Internal Application Load Balancer Envoy proxies in a proxy-only subnet allow ingress by default, so restriction requires an explicit deny-all rule plus higher-priority allows for approved sources and health checks.