Building Zero Trust Architecture Across AWS, Azure, and GCP

Introduction to Multi-Cloud Zero Trust

Multi-cloud zero trust architecture represents a fundamental shift in how organizations secure workloads distributed across AWS, Azure, and GCP. As enterprises increasingly adopt multi-cloud strategies to avoid vendor lock-in and leverage best-of-breed services, the traditional perimeter-based security model collapses. In its place, a multi-cloud zero trust architecture enforces the principle of "never trust, always verify" at every layer of the technology stack, regardless of which cloud provider hosts the resource.

The challenge is significant: each cloud provider implements security primitives differently. AWS relies on IAM policies with JSON-based documents, Azure leverages Azure Active Directory and role-based access control (RBAC), and GCP uses its own IAM system with organization-level policies. Building a cohesive zero trust security framework across all three requires deep understanding of each platform's capabilities and careful architectural planning.

In this guide, we will walk through the complete architecture for implementing zero trust across all three major cloud providers. We will cover identity federation, microsegmentation strategies, conditional access policies, and infrastructure-as-code implementations using Terraform. The patterns described here are drawn from real-world deployments at Citadel Cloud Management, where we have architected multi-cloud security baselines for enterprises managing hundreds of workloads across cloud boundaries.

Before diving into implementation details, it is critical to understand that zero trust is not a single product or technology. It is an architectural approach that requires coordinating identity providers, network controls, workload security, data protection, and continuous monitoring into a unified security posture. The NIST SP 800-207 publication provides the foundational framework that guides our approach.

Understanding the NIST 800-207 Zero Trust Framework

The NIST Special Publication 800-207 defines zero trust as a set of cybersecurity paradigms that move defenses from static, network-based perimeters to focusing on users, assets, and resources. The framework establishes several core tenets that directly map to multi-cloud implementation patterns.

Core Tenets of Zero Trust

NIST 800-207 outlines seven fundamental tenets. All data sources and computing services are considered resources. All communication is secured regardless of network location. Access to individual enterprise resources is granted on a per-session basis. Access to resources is determined by dynamic policy, including the observable state of client identity, application, and the requesting asset. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve its security posture.

Policy Decision Point and Policy Enforcement Point

At the heart of the NIST zero trust architecture sits the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). In a multi-cloud context, the PDP serves as the centralized brain that evaluates access requests against organizational policies, while PEPs are distributed across each cloud provider to enforce decisions at the point of access. This separation is crucial because it allows organizations to maintain a single source of truth for access policies while respecting each cloud provider's native enforcement mechanisms.

For AWS, the PEP manifests through IAM policies, Security Groups, and AWS Organizations Service Control Policies (SCPs). Azure uses Conditional Access policies, Network Security Groups (NSGs), and Azure Policy. GCP implements enforcement through IAM allow/deny policies, VPC Firewall rules, and Organization Policy Constraints. The PDP can be implemented using a centralized identity provider such as Azure AD, Okta, or Ping Identity that federates trust across all three clouds.

Identity-Based Access and IAM Federation

Identity-based access is the cornerstone of any zero trust implementation. In a multi-cloud environment, IAM federation creates a unified identity plane that allows users and services to authenticate once and access resources across AWS, Azure, and GCP with consistent policy enforcement.

Centralized Identity Provider Architecture

The recommended approach is to establish a single authoritative identity provider (IdP) that serves as the root of trust. Azure Active Directory (now Microsoft Entra ID) is commonly chosen due to its mature federation capabilities, but Okta and Ping Identity are equally viable. The IdP federates with each cloud provider using standard protocols:

For AWS, SAML 2.0 federation connects the IdP to AWS IAM Identity Center (formerly AWS SSO), which provisions temporary credentials with role-based access. For Azure, the IdP natively integrates with Azure AD, supporting conditional access policies that evaluate device compliance, location, and risk level before granting access. For GCP, Workload Identity Federation allows external identities to impersonate GCP service accounts without storing long-lived keys, a significant security improvement over traditional service account key distribution.

Service-to-Service Identity

Zero trust extends beyond human users to workload identities. Each microservice, container, and serverless function must have a verifiable identity. AWS uses IAM roles for EC2, ECS task roles, and Lambda execution roles. Azure provides Managed Identities. GCP offers Workload Identity for GKE and service account impersonation. The challenge is creating a consistent identity framework across these heterogeneous systems.

SPIFFE (Secure Production Identity Framework For Everyone) and its implementation SPIRE provide a cloud-agnostic solution for workload identity. By deploying SPIRE agents across all three clouds, you establish a universal identity layer where each workload receives a cryptographically verifiable SVID (SPIFFE Verifiable Identity Document) that is valid across cloud boundaries. Our multi-cloud-landing-zone repository includes reference configurations for SPIRE deployment across AWS, Azure, and GCP.

Microsegmentation Across Cloud Providers

Microsegmentation creates fine-grained security zones that limit lateral movement within and between cloud environments. Unlike traditional network segmentation that relies on subnets and VLANs, microsegmentation operates at the workload level, applying security policies to individual virtual machines, containers, and serverless functions.

Network-Level Microsegmentation

Each cloud provider offers native tools for network-level microsegmentation. AWS Security Groups act as stateful firewalls at the instance level, while Network ACLs provide stateless rules at the subnet level. Azure Network Security Groups (NSGs) can be applied to both subnets and individual network interfaces, with Application Security Groups (ASGs) enabling logical grouping. GCP VPC Firewall rules support both ingress and egress filtering with tag-based targeting.

The key architectural decision is whether to use cloud-native tools exclusively or overlay a third-party microsegmentation platform like Illumio, Guardicore, or Calico Enterprise. Cloud-native tools are simpler to manage but create consistency challenges across providers. Third-party solutions provide a unified policy model but add operational complexity and cost. For most organizations, we recommend a hybrid approach: use cloud-native tools for infrastructure-layer segmentation and deploy a service mesh (Istio, Linkerd) for application-layer microsegmentation.

Our terraform-azure-hub-spoke-network module implements a hub-and-spoke topology with built-in microsegmentation using NSGs and Azure Firewall, providing a reference architecture for Azure-side network zero trust. Similarly, the terraform-gcp-vpc-network module configures GCP VPC networks with hierarchical firewall policies.

Application-Layer Microsegmentation with Service Mesh

Service mesh technology enables microsegmentation at the application layer by encrypting all service-to-service communication with mutual TLS (mTLS) and enforcing authorization policies based on workload identity rather than network location. This is the purest expression of zero trust: every request is authenticated and authorized regardless of its source network.

Istio's AuthorizationPolicy resource allows you to define which services can communicate with which other services, based on their SPIFFE identities, HTTP methods, paths, and even request headers. When deployed consistently across EKS, AKS, and GKE clusters, Istio creates a uniform security plane that transcends cloud boundaries.

Terraform Implementation: Cross-Cloud IAM Federation

Infrastructure-as-code is non-negotiable for multi-cloud zero trust. Manual configuration across three cloud providers is error-prone and unauditable. The following Terraform configuration demonstrates how to establish IAM federation from Azure AD to both AWS and GCP, creating a unified identity plane for zero trust access control.

# Cross-Cloud IAM Federation with Azure AD as Central IdP
# Repository: https://github.com/kogunlowo123/terraform-aws-security-baseline

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azuread = {
      source  = "hashicorp/azuread"
      version = "~> 2.47"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

# --- Azure AD: Central Identity Provider ---
resource "azuread_application" "aws_federation" {
  display_name = "AWS-ZeroTrust-Federation"
  identifier_uris = ["https://signin.aws.amazon.com/saml"]

  web {
    redirect_uris = ["https://signin.aws.amazon.com/saml"]
  }
}

resource "azuread_service_principal" "aws_federation" {
  client_id = azuread_application.aws_federation.client_id
}

resource "azuread_application" "gcp_federation" {
  display_name = "GCP-ZeroTrust-Federation"
  identifier_uris = ["https://accounts.google.com"]

  web {
    redirect_uris = ["https://accounts.google.com/o/saml2/acs"]
  }
}

# --- AWS: SAML Provider + Zero Trust IAM Roles ---
resource "aws_iam_saml_provider" "azure_ad" {
  name                   = "AzureAD-ZeroTrust"
  saml_metadata_document = file("${path.module}/metadata/azure-ad-metadata.xml")
}

resource "aws_iam_role" "zero_trust_admin" {
  name = "ZeroTrustAdmin"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_saml_provider.azure_ad.arn
      }
      Action = "sts:AssumeRoleWithSAML"
      Condition = {
        StringEquals = {
          "SAML:aud" = "https://signin.aws.amazon.com/saml"
        }
        # Zero Trust: Enforce MFA from IdP
        StringLike = {
          "SAML:authnContextClassRef" = [
            "urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract"
          ]
        }
      }
    }]
  })

  max_session_duration = 3600  # 1 hour max session
}

resource "aws_iam_role_policy" "zero_trust_boundary" {
  name = "ZeroTrustPermissionsBoundary"
  role = aws_iam_role.zero_trust_admin.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "ec2:Describe*",
          "s3:GetObject",
          "s3:ListBucket",
          "logs:GetLogEvents",
          "cloudwatch:GetMetricData"
        ]
        Resource = "*"
        Condition = {
          IpAddress = {
            "aws:SourceIp" = var.allowed_cidr_blocks
          }
          Bool = {
            "aws:MultiFactorAuthPresent" = "true"
          }
        }
      },
      {
        Effect   = "Deny"
        Action   = "*"
        Resource = "*"
        Condition = {
          NotIpAddress = {
            "aws:SourceIp" = var.allowed_cidr_blocks
          }
        }
      }
    ]
  })
}

# --- GCP: Workload Identity Federation ---
resource "google_iam_workload_identity_pool" "azure_ad_pool" {
  project                   = var.gcp_project_id
  workload_identity_pool_id = "azure-ad-zero-trust"
  display_name              = "Azure AD Zero Trust Pool"
  description               = "Federated identity pool for Azure AD zero trust access"
}

resource "google_iam_workload_identity_pool_provider" "azure_ad_provider" {
  project                            = var.gcp_project_id
  workload_identity_pool_id          = google_iam_workload_identity_pool.azure_ad_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "azure-ad-oidc"
  display_name                       = "Azure AD OIDC"

  attribute_mapping = {
    "google.subject"       = "assertion.sub"
    "attribute.tenant_id"  = "assertion.tid"
    "attribute.groups"     = "assertion.groups"
  }

  attribute_condition = "assertion.tid == '${var.azure_tenant_id}'"

  oidc {
    issuer_uri = "https://login.microsoftonline.com/${var.azure_tenant_id}/v2.0"
  }
}

resource "google_service_account" "zero_trust_sa" {
  project      = var.gcp_project_id
  account_id   = "zero-trust-federated"
  display_name = "Zero Trust Federated Service Account"
}

resource "google_service_account_iam_binding" "workload_identity_binding" {
  service_account_id = google_service_account.zero_trust_sa.name
  role               = "roles/iam.workloadIdentityUser"

  members = [
    "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.azure_ad_pool.name}/attribute.groups/ZeroTrustAdmins"
  ]
}

# --- Variables ---
variable "allowed_cidr_blocks" {
  type        = list(string)
  description = "Allowed CIDR blocks for zero trust access"
}

variable "gcp_project_id" {
  type        = string
  description = "GCP project ID for workload identity"
}

variable "azure_tenant_id" {
  type        = string
  description = "Azure AD tenant ID"
}

This configuration establishes Azure AD as the central identity provider, creates SAML federation with AWS, and sets up Workload Identity Federation with GCP. Notice the zero trust principles embedded throughout: session duration limits, MFA enforcement via SAML assertions, IP-based conditional access, and explicit deny rules. The complete module with additional security controls is available in our terraform-aws-security-baseline repository.

AWS vs Azure vs GCP Zero Trust Capabilities Comparison

Understanding the native zero trust capabilities of each cloud provider is essential for designing a cohesive multi-cloud architecture. The following comparison table maps key zero trust capabilities across all three platforms.

Azure leads in unified conditional access with its deeply integrated Entra ID (Azure AD) platform, which natively supports device compliance, sign-in risk, and location-based policies. GCP's BeyondCorp Enterprise is the most mature context-aware access platform, born from Google's internal zero trust implementation. AWS excels in granular IAM policy conditions and has rapidly expanded its zero trust portfolio with Verified Access and VPC Lattice.

Cloud Security Posture Management

Continuous monitoring and validation of your security posture is a core zero trust requirement. Each cloud provider offers native CSPM (Cloud Security Posture Management) tools, but in a multi-cloud environment, you need a unified view across all platforms.

Unified CSPM Strategy

AWS Security Hub aggregates findings from GuardDuty, Inspector, Macie, and third-party tools into a single dashboard with automated compliance checks against CIS benchmarks and AWS Foundational Security Best Practices. Microsoft Defender for Cloud extends across Azure, AWS, and GCP, making it a natural choice for multi-cloud CSPM. GCP Security Command Center provides asset inventory, vulnerability findings, and threat detection for GCP resources.

For true multi-cloud visibility, consider deploying Microsoft Defender for Cloud as your unified CSPM platform, as it natively supports AWS and GCP in addition to Azure. Alternatively, third-party solutions like Prisma Cloud, Wiz, or Orca Security provide comprehensive multi-cloud CSPM with consistent policy enforcement and centralized reporting.

The Microsoft Zero Trust documentation provides detailed guidance on implementing zero trust across Microsoft's ecosystem and extending it to multi-cloud environments.

Conditional Access Policies for Zero Trust

Conditional access is where zero trust moves from theory to practice. Rather than granting blanket access based on network location, conditional access evaluates multiple signals before allowing access to resources.

Signal-Based Access Decisions

A mature zero trust implementation evaluates the following signals for every access request: user identity and authentication strength, device health and compliance status, network location and IP reputation, resource sensitivity classification, time of access and behavioral anomalies, and the specific action being requested.

In Azure, Conditional Access policies natively support all these signals through integration with Entra ID, Intune, and Microsoft Defender. In AWS, you can approximate conditional access through IAM policy conditions, but the signal richness is more limited. GCP's Access Context Manager allows you to define access levels based on IP address, device attributes, and other context, which can be applied to resources through IAM Conditions and BeyondCorp Enterprise.

Step-Up Authentication

Zero trust demands appropriate authentication strength for the sensitivity of the resource being accessed. Viewing a public dashboard might require only single-factor authentication, while modifying production infrastructure should demand hardware-token MFA and device compliance verification. Implementing step-up authentication across clouds requires careful coordination between the IdP and each cloud's access control mechanisms.

Best Practices for Multi-Cloud Zero Trust Architecture

Based on deploying zero trust architectures across dozens of enterprise multi-cloud environments, the following best practices have proven critical for success:

1. Establish a single authoritative identity provider. Federate all cloud providers to one IdP (Azure AD, Okta, or Ping) to ensure consistent identity verification and policy enforcement. Avoid maintaining separate identity silos in each cloud.
2. Implement least-privilege access with just-in-time (JIT) elevation. No standing privileges for production environments. Use AWS IAM Identity Center permission sets, Azure PIM (Privileged Identity Management), and GCP IAM Conditions with time-bound access grants.
3. Deploy infrastructure-as-code for all security controls. Every security group, IAM policy, firewall rule, and conditional access policy must be codified in Terraform or equivalent IaC. This ensures auditability, repeatability, and drift detection.
4. Enable microsegmentation at both network and application layers. Use cloud-native network controls (Security Groups, NSGs, VPC Firewalls) for infrastructure segmentation and service mesh (Istio, Linkerd) for application-layer mTLS and authorization.
5. Encrypt all data in transit and at rest with customer-managed keys. Use AWS KMS, Azure Key Vault, and GCP Cloud KMS with hardware security modules. Enforce TLS 1.2+ for all communication, including internal service-to-service traffic.
6. Implement continuous security posture monitoring. Deploy CSPM tools that provide unified visibility across all cloud providers. Automate remediation of critical findings and integrate with SIEM for correlation and alerting.
7. Adopt policy-as-code with OPA (Open Policy Agent). Use OPA Gatekeeper for Kubernetes policy enforcement, Conftest for IaC validation, and OPA-based authorization services for application-level access control across all clouds.
8. Establish network connectivity with zero trust principles. Use transit gateways, VPN, or dedicated interconnects for cross-cloud communication, but treat all traffic as untrusted. Encrypt inter-cloud traffic with IPSec or WireGuard overlays.
9. Implement comprehensive logging and audit trails. Centralize AWS CloudTrail, Azure Activity Logs, and GCP Audit Logs into a unified SIEM. Ensure log immutability with write-once storage and monitor for privilege escalation attempts.
10. Test zero trust controls regularly with adversarial simulations. Conduct red team exercises that specifically target cross-cloud trust boundaries. Verify that lateral movement between clouds is prevented by your microsegmentation and identity controls.