Multi-cloud environments offer flexibility and resilience, but they also introduce complex security challenges. In "Operation Broken Bridge," I deployed a full-stack application across AWS and GCP, then conducted a forensic after-action report to identify configuration errors, networking gaps, and security posture improvements.
Mission Overview: The Architecture
The objective was to establish a secure communication bridge between a GCP compute instance (frontend) and an AWS RDS database (backend). The architecture required precise networking configuration, secret management, and identity controls.
🌐 GCP Frontend
- • Compute Engine (e2-micro VM)
- • Python Flask Application (Port 5000)
- • Firewall Rule: Allow Personal IP (129.2.89.37/32)
- • Virtual Environment (venv) for dependencies
☁️ AWS Backend
- • RDS PostgreSQL Instance
- • CloudFormation Deployment (us-east-1)
- • Security Group: Allow GCP VM Public IP (Port 5432)
- • Static Credentials (Initial Setup)
After Action Report: What Went Well
Several critical phases of the deployment were executed successfully on the first attempt, demonstrating proficiency in cloud orchestration.
- Phase I & II Completion: Initial reconnaissance and AWS CloudFormation backend deployment in
us-east-1were executed smoothly. - GCP Deployment & Firewall: The e2-micro VM deployment and firewall configuration to allow personal IP access to Port 5000 were quickly resolved, validating application connectivity.
- Application Environment Setup: Successfully using Python Virtual Environment (
venv) to install dependencies without affecting the host OS was a clean deployment practice.
The Challenge: The "Broken Bridge"
Despite successful infrastructure deployment, the mission encountered a critical configuration error that halted connectivity between the frontend and backend.
⚠️ The Environment Variable Mismatch
The most significant time sink was a mismatch between the common convention (DB_PASSWORD) used in the .env file I created and the application's required variable name (DB_PASS).
This caused an authentication failure that presented as a "Connection Timed Out" error, delaying the diagnosis of the actual network issue. This highlights the importance of validating application requirements before infrastructure deployment.
Networking Fix: Bridging the Gap
Beyond the application configuration, the network link required precise security group tuning. The AWS Security Group's Inbound Rules had to be adjusted to allow traffic from the GCP VM's Public IP on port 5432 (PostgreSQL).
This specific task—the Phase IV "Bridge Engineering" fix—was the critical point in the architecture and should have been validated immediately after resource creation.
Security Posture Assessment
Following the successful deployment, I conducted a security audit to identify vulnerabilities in the multi-cloud environment. The assessment focused on three key domains: Secrets Management, Network Architecture, and Identity.
| Security Domain | Current Posture (Vulnerability) | Proposed Enhancement |
|---|---|---|
| Secrets Management |
High Risk Static, unencrypted password stored in a .env file on the VM's disk.
|
Zero Trust Store password in AWS Secrets Manager. GCP VM Service Account federated with AWS IAM to retrieve short-lived passwords at runtime. |
| Network Architecture |
Exposed GCP VM dashboard (Port 5000) and AWS RDS Security Group publicly accessible via whitelisted IPs. |
Private Implement Zero-Trust via Private IPs and IAP. GCP VM in private subnet (no public IP). Access via GCP Identity-Aware Proxy. |
| Identity (DB Access) |
Static Connection uses traditional, long-lived username and password. |
IAM Auth Implement IAM Database Authentication. GCP VM assumes federated role, authenticates with short-lived IAM token, eliminating static DB_PASS. |
Lessons Learned & Future Improvements
1. Source Code Pre-Review
Before creating the .env file, I would explicitly examine the application source code to confirm exact environment variable names (DB_HOST, DB_PASS, etc.) to prevent single-character configuration errors.
2. Strict Networking Focus
I would make the network link fix—the AWS Security Group inbound rules—the first thing I do after initial AWS deployment. This is the critical point in the "Broken Bridge" architecture.
3. Automate Deployment
To minimize human error, I would utilize the VM's Startup Script capability in GCP to automate the entire Phase III deployment (installing dependencies, configuring .env, running the app).
Conclusion
Operation Broken Bridge demonstrated the complexities of multi-cloud security. While the infrastructure was successfully deployed, the experience highlighted critical gaps in secrets management and network exposure. Moving from static credentials to federated IAM roles and from public IPs to Identity-Aware Proxy are essential steps for production-grade security.
📚 Educational Context
This operation was completed as part of ENPM665: Cloud Security at the University of Maryland. The mission scenario was created for educational purposes to develop practical skills in multi-cloud deployment, network security, and security posture assessment.