/google-cloud-solution-n-tier-serverless-web-app

Architectural Rules and Report Audit Checklist

To ensure secure, resilient, and cost-effective multi-tier cloud deployments, enforce the following 9 architectural guards across solution design reports (assets/output-template.md) and Infrastructure as Code (assets/main.tf). Understanding the engineering rationale behind each rule enables accurate architectural decisions across diverse workloads:

1. Ingress Bypass Defense (internal-and-cloud-load-balancing):
   • Rule: Configure Tier 1 Frontend ingress to INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER.
   • Why: If a public Cloud Run service uses default unrestricted ingress (all), external clients can send HTTP requests directly to the default *.run.app URL, completely bypassing the external Application Load Balancer, SSL termination policies, and Cloud Armor WAF screening rules. Restricting ingress to internal-and-cloud-load-balancing ensures public traffic can only reach the container after passing through edge inspection.
2. VPC-Internal Backend Ingress (INGRESS_TRAFFIC_INTERNAL_ONLY):
   • Rule: Configure internal application microservice tiers (T2..TN, e.g., backend_application) strictly to INGRESS_TRAFFIC_INTERNAL_ONLY.
   • Why: Internal business logic, data processing, and backend microservices should never be directly reachable from the public internet. Restricting ingress to VPC-internal ensures that these services reject any traffic originating outside the private network boundary, eliminating external attack surface.
3. Direct VPC Egress (vpc_access) & Cloud DNS (google_dns_managed_zone):
   • Rule: Attach vpc_access across compute tiers (egress = "ALL_TRAFFIC" when calling internal *.run.app URLs). When Tier 1 uses ALL_TRAFFIC egress, deploy a google_dns_managed_zone for run.app. bound to vpc_network with google_dns_record_set mapping *.run.app directly to Private Google Access VIPs (199.36.153.4/30 / 199.36.153.8/30).
   • Why: By default, public Google DNS resolves *.run.app hostnames to public IPv4 virtual IP addresses (216.58.x.x). Under ALL_TRAFFIC egress, packets sent from containers targeting 216.58.x.x traverse the VPC and hit default-deny (0.0.0.0/0) egress firewalls. Even when allowed outside the VPC, requests arriving from public VIPs are rejected by downstream VPC-internal (INGRESS_TRAFFIC_INTERNAL_ONLY) ingress guards with HTTP 403 or 404 errors. Implementing a private Cloud DNS zone maps these hostnames inside the VPC to internal Private Google Access endpoints (199.36.153.x), allowing traffic to cleanly traverse the private backbone and preserve internal VPC sender identity.
4. Least-Privilege Cloud NGFW Egress Firewalls & Sidecar Cert Exchange (443):
   • Rule: Enforce explicit Cloud NGFW global or regional network firewall policies (google_compute_network_firewall_policy, google_compute_network_firewall_policy_association, and google_compute_network_firewall_policy_rule) restricting outbound traffic precisely between tiers (deny 0.0.0.0/0, Frontend -> Backend 443/8080, and Backend -> Data Tier 5432/6379). For database egress (allow_backend_db_egress), permit TCP port 443 to Private Google Access VIPs (199.36.153.4/30, 199.36.153.8/30) in addition to TCP port 5432 (Cloud SQL PSC IP).
   • Why: Least-privilege egress policies prevent compromised containers from scanning internal networks or exfiltrating data to arbitrary external destinations. Authorizing TCP port 443 to PGA VIPs alongside port 5432 is essential because when Cloud Run initializes cloud_sql_instance volumes (IAM Auth), the sidecar container queries sqladmin.googleapis.com (port 443) and OAuth metadata endpoints across startup to exchange short-lived tokens for ephemeral client certificates; blocking this handshake under default-deny (deny 0.0.0.0/0) causes container initialization to crash.
5. Firewall Policy Logging for Network Auditing:
   • Rule: Enable enable_logging = var.enable_monitoring on Cloud NGFW network firewall policy rules.
   • Why: Capturing connection metadata (source/destination IP, port, protocol, and allow/deny decisions) produces verifiable audit trails for security operations, SIEM integration, and troubleshooting zero-trust network policies during incident response.
6. Cloud CDN Edge Caching (enable_cdn):
   • Rule: Enable enable_cdn = true on the global Application Load Balancer backend service (google_compute_backend_service). For European or regional data residency compliance using a regional Application Load Balancer (google_compute_region_backend_service), omit CDN, provision an explicit regional proxy-only subnet (purpose = "REGIONAL_MANAGED_PROXY"), specify network on the regional forwarding rule (google_compute_forwarding_rule), and explain the residency trade-off.
   • Why: Caching static assets at Google's edge points-of-presence (PoPs) significantly reduces latency for end users, lowers serverless container invocation frequency, and replaces higher Cloud Run data egress costs with lower Cloud CDN edge delivery rates.
7. Private Service Connect (psc_enabled = true) & Private Redis (PSA):
   • Rule: Disable public IPs (ipv4_enabled = false) on Cloud SQL instances and connect via Private Service Connect (psc_enabled = true, google_compute_forwarding_rule). Connect Memorystore for Redis via Private Services Access (connect_mode = "PRIVATE_SERVICE_ACCESS" over authorized_network).
   • Why: Exposing relational databases or in-memory caches on public IPv4 addresses introduces unnecessary vulnerability to brute-force and DDoS attacks. Private Service Connect provisions localized endpoints directly inside the consumer VPC without /16 CIDR peering requirements or transitive routing risks, ensuring data storage remains 100% private.
8. Cloud SQL Auth Proxy & IAM Database Auth (DB_SOCKET_PATH):
   • Rule: Mount the built-in Cloud SQL Auth Proxy sidecar via cloud_sql_instance volumes (/cloudsql/project:region:instance Unix domain socket) and enable IAM-based database authentication (cloudsql.iam_authentication = on, roles/cloudsql.client). When configuring database connection strings in application drivers, advise using DB_SOCKET_PATH (/cloudsql/... Unix socket) over direct TCP (DB_PSC_ENDPOINT).
   • Why: Hardcoded database passwords risk credential leakage, require operational maintenance for frequent password rotation, and lack granular identity auditing. The built-in Auth Proxy sidecar handles transparent short-lived OAuth token exchange (cloudsql.iam_authentication), automatic rotation, and mutual TLS encryption natively over Unix sockets without adding rotation logic or custom token handlers inside application code.
9. Organization API Perimeter (enable_vpc_sc):
   • Rule: Provide configuration variables (enable_vpc_sc = true) and documentation for wrapping run.googleapis.com, sqladmin.googleapis.com, and secretmanager.googleapis.com within an Organization-level VPC Service Controls (VPC-SC) service perimeter.
   • Why: While network firewalls secure data-plane traffic (TCP 5432), they do not restrict API management planes (sqladmin.googleapis.com). A VPC-SC service perimeter prevents cross-project data exfiltration—such as an attacker exporting database backups (sqladmin.instances.export) to an unauthorized external Cloud Storage bucket—even if legitimate IAM administrative credentials are used.

Modular IaC Alignment and Best Practices

• Building Block Modules (assets/main.tf): Base Tier 1 parameters precisely on Section 5.1 ("Tier 1 presentation tier: frontend reverse proxy") in assets/main.tf and Tiers 2..N on Section 5.2 ("Tier 2 application tier: private backend application") in assets/main.tf, ensuring appropriate roles/run.invoker bindings are granted directly between calling service account identities.
• Terraform Best Practices (general-style-structure): Adhere to Google Cloud HCL style guidelines including typed variables (type, description), unit-named numbers (memory_size_gb), positive boolean switches (enable_cdn), explicit outputs, and stateful deletion protection (deletion_protection = true).