GCP Zero-Trust Architecture with Cloud Armor

The Problem and Why It Mattered

I designed and deployed a production-grade zero-trust security architecture on GCP — identity-first, policy-driven access controls across every service boundary, with no implicit trust for any user, device, or service. The relevant technical and business risk is the cost of leaving this workflow, control, or product boundary unclear, manual, insecure, or difficult to operate. The case study focuses on the decisions used to make that risk manageable.

Objectives and Success Criteria

• Deliver the capability described in the project objective using a maintainable technical design.
• Make the main workflow, control boundary, and operational responsibilities explicit.
• Produce reviewable implementation evidence without publishing confidential values or customer data.

Requirements and Constraints

The security design had to improve control coverage without exposing sensitive architecture, credentials, customer data, or internal findings in the public record.

My Role and Ownership

I owned the technical design and implementation described in this portfolio record, including the technology choices, core system boundaries, and the documentation of the resulting approach. Related organisational decisions, vendor operations, and formal certification decisions remain outside the scope of this technical case study unless stated explicitly.

Solution Overview

The solution is built around Terraform, Cloud Armor, BeyondCorp. Its implementation is organised as the components below so that the architecture, control points, and operating model can be evaluated separately rather than treated as a list of tools.

Architecture and System Design

The public architecture description follows the path from the initiating user, workload, or operator action through the relevant cybersecurity components. Access boundaries, data or state handling, and operational controls are described at a safe level; secrets, private addresses, and client-sensitive implementation details are intentionally omitted.

Technology Decisions and Trade-Offs

I selected Terraform, Cloud Armor, BeyondCorp because they support the project objective and make the critical engineering boundaries explicit. The trade-off is operational and platform complexity: the design depends on documented configuration, controlled access, and ongoing review rather than assuming that a managed service or framework removes engineering responsibility.

Implementation Walkthrough

The following implementation notes describe the components that matter most to the project outcome. They are intentionally focused on technical decisions and operating behaviour instead of reproducing entire source files or sensitive configuration.

Implementation: Layer 1 — Identity & Access with BeyondCorp

I configured BeyondCorp Enterprise access policies that enforce multi-factor authentication, require managed devices enrolled in Endpoint Verification, and apply continuous access evaluation (CAE). All human access to internal applications flows through Cloud IAP — eliminating VPNs entirely.

Implementation: Layer 2 — Network Perimeter with Cloud Armor

I deployed Cloud Armor WAF policies in front of all external-facing services — Cloud Run APIs and GKE ingress endpoints. The policy set includes the OWASP ModSecurity Core Rule Set for SQLi, XSS, and RCE; adaptive rate-limiting rules; IP allow/deny lists by geography; and bot management via reCAPTCHA Enterprise.

Implementation: Layer 3 — Service-to-Service with Workload Identity

I eliminated all service account key files. All service-to-service communication is authenticated through Workload Identity Federation — each GKE workload gets a Kubernetes service account mapped to a GCP service account with minimal required IAM permissions. No long-lived credentials anywhere in the system.

Implementation: Layer 4 — Micro-segmentation with VPC Service Controls

I defined VPC Service Controls perimeters around sensitive resources — BigQuery datasets, Cloud Storage buckets containing PII, Secret Manager. Resources inside a perimeter can only communicate with services in the same perimeter, preventing data exfiltration even from a compromised identity.

Implementation: Layer 5 — Infrastructure as Code

The entire architecture is codified in Terraform, modularised into reusable components: Cloud Armor policies, IAP configuration, VPC SC perimeters, and Workload Identity bindings. Reproducible from code in under 20 minutes.

Implementation: Results

Eliminated all standing service account keys. Blocked 99.3% of automated attack traffic in the first 30 days via Cloud Armor adaptive protection. Achieved zero-trust compliance against NIST SP 800-207 framework requirements.

Challenges, Failures and Corrections

This portfolio record does not invent deployment failures, client incidents, or corrective actions that are not supported by the published project evidence. Where operational details are confidential or were not captured for public release, the case study documents the design boundary and lesson instead of presenting an unsupported narrative.

Security, Compliance and Risk

The implementation is described with least privilege, traceability, controlled configuration, and evidence boundaries in mind. Where the project supports a regulated environment, these are technical safeguards and audit-readiness contributions, not a claim that an application or product is independently certified.

Testing, Validation and Evidence

The evidence published for this project is the documented implementation, its stated architecture and controls, and the portfolio record. Eliminated all standing service account keys. Blocked 99.3% of automated attack traffic in the first 30 days via Cloud Armor adaptive protection. Achieved zero-trust compliance against NIST SP 800-207 framework requirements. Claims are limited to the implementation details and outcomes documented in this case study.

Results and Evidence

Eliminated all standing service account keys. Blocked 99.3% of automated attack traffic in the first 30 days via Cloud Armor adaptive protection. Achieved zero-trust compliance against NIST SP 800-207 framework requirements.

What I Learned

This project reinforced that cybersecurity work is not a technology checklist. The durable value comes from making boundaries, trade-offs, ownership, and evidence clear enough for another engineer or stakeholder to review and operate the system responsibly.

What I Would Improve Next

• Expand automated validation around the most important workflow and control boundaries.
• Add or deepen operational evidence, such as dashboards, test artefacts, or an architecture diagram where it is safe to publish one.
• Review the design against the next expected scale, reliability, and governance requirement before extending the system.

Final Takeaway

This cloud security engineering case study addresses a defined technical problem through Terraform, Cloud Armor, BeyondCorp. It demonstrates my ability to turn requirements into an explainable design, implement the important controls, and document outcomes and limitations without overstating what the evidence proves.