Zero Trust in the Cloud — BeyondCorp, Azure AD Conditional Access & BeyondProd Guide

In this tutorial, you'll learn about Zero Trust in the Cloud. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Zero Trust architecture in the cloud replaces perimeter-based security with identity-centric access controls, verifying every request regardless of where it originates using models like Google BeyondCorp, Azure AD Conditional Access, and AWS Verified Access.

What You Will Learn

How Zero Trust principles apply to cloud environments, how BeyondCorp and Azure AD Conditional Access work, and how to implement micro-segmentation and just-in-time access across Multi-Cloud.

Why It Matters

The traditional perimeter is dead. Users work from anywhere. Applications run in multiple clouds. Zero Trust assumes no network is trusted and verifies every access request based on identity, device health, and context.

Real-World Use

DodaTech employees access internal applications through AWS Verified Access. Every request is authenticated against Azure AD, checked for device Compliance, and authorized based on the user's role and location. No VPN required.

Zero Trust Pillars

flowchart TD
  ZTA[Zero Trust Architecture] --> Identity[Identity\nWho is the user?]
  ZTA --> Device[Device\nIs it compliant?]
  ZTA --> Network[Network\nFrom where?]
  ZTA --> Workload[Workload\nIs it healthy?]
  ZTA --> Data[Data\nIs it classified?]
  
  Identity --> Policy["Enforce Policy\nAllow / Deny / MFA"]
  Device --> Policy
  Network --> Policy
  Workload --> Policy
  Data --> Policy
  Policy --> Access[Grant Access]
  
  style ZTA fill:#f90,color:#fff
  style Policy fill:#390,color:#fff

Google BeyondCorp

BeyondCorp shifts access from network-based to identity-based. Access is granted based on user identity, device state, and context rather than IP address.

# GCP: Configure access context manager with device policy
gcloud access-context-manager perimeters create \
  --title "internal-apps-perimeter" \
  --resources "projects/my-project" \
  --restricted-services "storage.googleapis.com" \
  --vpc-allowed-services "restricted-services" \
  --access-levels "accessPolicies/123456789/accessLevels/corporate_device"

# Create an access level requiring device encryption
gcloud access-context-manager access-levels create corporate_device \
  --access-policy 123456789 \
  --title "Corporate Device" \
  --basic-level-spec '{
    "conditions": [{
      "devicePolicy": {
        "requireScreenLock": true,
        "requireOsVerification": true,
        "allowedDeviceManagementLevels": ["COMPLETE"]
      }
    }]
  }'

Azure AD Conditional Access

Conditional Access evaluates signals from user identity, device Compliance, location, and risk to enforce access policies.

# Create a Conditional Access policy requiring compliant device
az identity conditional-access policy create \
  --name "Require Compliant Device for Cloud Apps" \
  --conditions '{
    "applications": {"includeApplications": ["All"]},
    "users": {"includeUsers": ["All"]},
    "platforms": {"includePlatforms": ["All"]}
  }' \
  --grant-controls '{
    "builtInControls": ["compliantDevice"],
    "operator": "OR"
  }' \
  --state enabled

# Create a policy that blocks access from non-trusted locations
az identity conditional-access policy create \
  --name "Block non-trusted regions" \
  --conditions '{
    "applications": {"includeApplications": ["All"]},
    "users": {"includeUsers": ["All"]},
    "locations": {"includeLocations": ["All"], "excludeLocations": ["trusted-ip-range"]}
  }' \
  --grant-controls '{"builtInControls": ["block"], "operator": "OR"}' \
  --state enabled

# List Conditional Access policies
az identity conditional-access policy list \
  --query "[].{Name:displayName, State:state}" \
  --output table
# Output:
# Name                           State
# Require Compliant Device       enabled
# Block non-trusted regions      enabled

AWS Verified Access

Verified Access provides zero-trust access to corporate applications without a VPN. It integrates with any OIDC identity provider.

# Create a Verified Access trust provider (OIDC)
aws verifiedaccess create-trust-provider \
  --policy-reference-name AzureAD \
  --trust-provider-type Oidc \
  --oidc-options '{
    "Issuer": "https://login.microsoftonline.com/tenant-id/v2.0",
    "AuthorizationEndpoint": "https://login.microsoftonline.com/tenant-id/oauth2/v2.0/authorize",
    "TokenEndpoint": "https://login.microsoftonline.com/tenant-id/oauth2/v2.0/token",
    "ClientId": "client-id",
    "ClientSecret": "client-secret"
  }'

# Create a Verified Access instance
aws verifiedaccess create-instance \
  --description "DodaTech Internal Apps"

# Configure access policy
aws verifiedaccess create-instance-policy \
  --verified-access-instance-id vai-12345678 \
  --policy-document '{
    "Version": "2021-12-01",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"OIDC": {"sub": ["user"@dodatech".com"]}},
      "Action": ["verifiedaccess:AllowAccess"]
    }]
  }'

Micro-Segmentation with Network Policies

Zero Trust extends to workload communication. Every pod in Kubernetes should have a network policy that explicitly allows only required traffic.

Common Mistakes

1. Assuming VPN is enough: VPNs extend the corporate network perimeter but do not verify device health or user behavior continuously.
2. No device Compliance check: Identity alone is not enough. A compromised identity on an unmanaged device can access everything. Check device Compliance at every request.
3. Overly permissive trust policies: A policy that allows all users from all locations defeats Zero Trust. Start with deny-all and add explicit grants.
4. Ignoring internal traffic: Network policies that only protect the perimeter miss lateral movement. Apply micro-segmentation to internal workloads.
5. Not implementing just-in-time access: Standing access violates Zero Trust. Use policies that require re-authentication and re-authorization for every request.

Practice Questions

1. What are the core principles of Zero Trust architecture?
2. How does Google BeyondCorp differ from a traditional VPN?
3. What signals does Azure AD Conditional Access evaluate?
4. How does AWS Verified Access provide VPN-less access?
5. Why is micro-segmentation important for Zero Trust in the cloud?

Challenge

Implement Zero Trust for a cloud application. The application is deployed on GKE and accessed by employees and contractors. Employees on managed devices should get full access. Contractors on any device should get read-only access with session timeout every 4 hours. All access requires authentication via Azure AD. Use Azure AD Conditional Access policies, GKE network policies, and GCP VPC Service Controls. Write the policies and configurations.

FAQ