This repository provisions a highly secure, end-to-end encrypted infrastructure on Google Cloud Platform. It demonstrates advanced cross-project networking, zero-trust perimeter security, and a fully automated GitOps deployment lifecycle.
The architecture completely isolates the public-facing ingestion layer from the private compute backend using Google Cloud Private Service Connect (PSC). This eliminates the need for VPC Peering and prevents overlapping IP complexities.
- VPC A (The Consumer/Edge): Acts as a DMZ. Catches public internet traffic, terminates the initial TLS connection, and scrubs requests via Cloud Armor (WAF).
- Private Service Connect (The Bridge): A secure, unidirectional tunnel across Google's internal backbone linking VPC A to VPC B without exposing the backend to the public internet.
- VPC B (The Producer/Compute): A strictly private network hosting the GKE cluster. Contains an Internal TCP Load Balancer that passes traffic directly to GKE nodes.
- GKE & Ingress: Nginx is deployed with
hostNetwork: trueto bind directly to the node's port 443, re-encrypting and terminating TLS completely inside the internal boundary before routing to the Flask application.
- User Request: An external user sends an HTTPS
GETrequest to the Global External IP. - WAF Inspection: Cloud Armor evaluates the request at the edge, blocking malicious payloads (e.g., SQLi, XSS).
- External TLS Termination: The Global External HTTP(S) Load Balancer decrypts the traffic using an edge certificate.
- PSC Encapsulation: Traffic is routed to a Network Endpoint Group (NEG) and tunneled through Private Service Connect.
- Internal Routing: Traffic emerges in the Producer VPC via a Service Attachment and hits an Internal TCP Passthrough Load Balancer on port 443.
- Internal TLS Termination: The traffic hits Nginx Ingress on the GKE node, which uses an internal certificate to decrypt the traffic safely inside the cluster.
- Application Execution: Nginx proxies the plaintext request to the custom Flask API pod running on port 8080, which returns the payload.
The platform features a Horizontal Pod Autoscaler (HPA) designed to handle volatile traffic patterns through intensive CPU-bound workloads.
To demonstrate real-world elasticity, the Flask application includes a dedicated /hpa endpoint that performs heavy floating-point computations.
- Rapid Scale-Out: As demonstrated in the monitoring data, a sustained CPU spike triggers the HPA to scale the deployment from 1 to 5 pods in less than 60 seconds.
- Aggressive Scale-Down: To optimize cloud costs, a custom
behaviorpolicy is applied, forcing the cluster to scale back down to the baseline within 60 seconds of load cessation, rather than the Kubernetes default of 5 minutes. - The Test Command: To trigger a scale event, you can run the following loop in a terminal (Git Bash or Linux) to sustain high CPU utilization:
while true; do curl -k -s https://<YOUR_GLOBAL_IP>/hpa & sleep 1; done
Monitoring is strictly decoupled by network boundary and managed entirely via Terraform to ensure the observability layer shares the exact lifecycle as the compute infrastructure.
Tracks external ingress and WAF drop rates to monitor perimeter health.

Correlates Layer 3/Layer 4 bytes emerging from the PSC tunnel directly with Kubernetes Pod CPU utilization and live Pod counts (Uptime).

Infrastructure and Application deployments are cleanly separated in GitHub Actions.
infra-deploy.yml(Manual Trigger):- Job 1 (Producer): Deploys VPC B, NAT, GKE Cluster, PSC Service Attachment, and the Compute Monitoring Dashboard via Terraform.
- Job 2 (Consumer): Deploys VPC A, Global LB, Cloud Armor WAF, PSC NEG, and the Edge Monitoring Dashboard via Terraform.
deploy.yml(Manual Trigger):- Authenticates to Google Cloud.
- Builds the lightweight Flask Docker image from
app/Dockerfile. - Pushes the image to Google Artifact Registry.
- Applies Kubernetes manifests (
nginx-ingress.yaml,flask-app.yaml,hpa.yaml) to the GKE cluster.
To prevent ongoing cloud costs, this entire environment is strictly disposable and its destruction is fully automated via GitHub Actions.
infra-destroy.yml (Manual Trigger):
- Job 1 (Destroy Consumer): Tears down the Edge infrastructure first (Cloud Armor, Global LB, NEG). This safely detaches the Private Service Connect tunnel.
- Job 2 (Destroy Producer): Tears down the backend infrastructure (GKE, Artifact Registry, Service Attachment).
If executing locally without GitHub Actions, ensure you destroy the Consumer environment before the Producer to prevent hanging PSC attachments:
# 1. Destroy Consumer (Edge) first to detach the PSC tunnel
cd terraform/consumer && terraform destroy -auto-approve
# 2. Destroy Producer (Compute)
cd terraform/producer && terraform destroy -auto-approveWhile this repository provisions a cost-effective Zonal GKE Cluster to optimize for fast GitOps pipeline execution and minimal cloud spend, a true enterprise production rollout would expand on this foundation with the following enhancements:
- High Availability (Regional Cluster): Upgrading the GKE control plane to a Regional cluster spanning multiple compute zones (e.g.,
me-west1-a,me-west1-b,me-west1-c) to ensure the platform can survive isolated data center outages. - Elastic Compute (Cluster Autoscaler): The current architecture demonstrates the Horizontal Pod Autoscaler (HPA) scaling Pods based on CPU utilization within a fixed physical boundary. For true elasticity, enabling the Cluster Autoscaler (CA) would allow GKE to dynamically provision and destroy the underlying Compute Engine VMs across multiple zones whenever the HPA requests pods that exceed the current node capacity.



