Opening Framing
Most organizations don't operate in a single cloud. Whether by strategic choice, acquisition, or organic growth, enterprises find themselves managing workloads across AWS, Azure, GCP, and on-premises data centers. Each environment has its own security model, identity system, networking constructs, and compliance tools. This heterogeneity creates both opportunity and challenge: the opportunity for best-of-breed services and resilience, but the challenge of maintaining consistent security across fundamentally different platforms.
Hybrid and multi-cloud security requires thinking at a higher level of abstraction. Rather than mastering every detail of each platform, security teams must understand common patterns, create unified policies, and implement consistent controls across diverse environments. Identity becomes the control plane that spans all clouds. Centralized monitoring aggregates signals from everywhere. And policy frameworks must translate into platform-specific implementations.
This week covers multi-cloud architecture patterns, identity federation across clouds, network connectivity options, unified security monitoring, and cloud-agnostic security frameworks. You'll learn to design and implement security that works across heterogeneous cloud environments.
Key insight: Multi-cloud security is about finding the common denominator without sacrificing platform-specific strengths.
1) Multi-Cloud Architecture Patterns
Understanding why and how organizations use multiple clouds informs security strategy:
Multi-Cloud Motivations:
WHY MULTI-CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Strategic Reasons: │
│ - Avoid vendor lock-in │
│ - Best-of-breed services (GCP ML, AWS breadth, Azure O365) │
│ - Regulatory requirements (data residency) │
│ - Negotiating leverage with providers │
│ - Disaster recovery across providers │
│ │
│ Organic Reasons: │
│ - Mergers and acquisitions │
│ - Shadow IT adoption │
│ - Developer preferences │
│ - Legacy application requirements │
│ - Customer requirements │
│ │
│ Reality: Most multi-cloud is unplanned │
└─────────────────────────────────────────────────────────────┘
MULTI-CLOUD PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ Pattern 1: Workload Distribution │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │ GCP │ │
│ │ Compute │ │ O365/AD │ │ ML/AI │ │
│ │ Storage │ │ .NET Apps │ │ BigQuery │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Different workloads on different clouds based on strengths │
├─────────────────────────────────────────────────────────────┤
│ Pattern 2: Redundancy/DR │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │◄───────►│ Azure │ │
│ │ Primary │ Sync │ DR Site │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Active-passive or active-active across providers │
├─────────────────────────────────────────────────────────────┤
│ Pattern 3: Cloud-Agnostic Applications │
│ ┌─────────────────────────────┐ │
│ │ Kubernetes (Portable) │ │
│ └─────────────────────────────┘ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ EKS │ │ AKS │ │ GKE │ │
│ └─────┘ └─────┘ └─────┘ │
│ │
│ Containerized apps portable across clouds │
└─────────────────────────────────────────────────────────────┘
HYBRID CLOUD PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ Pattern 1: Cloud Bursting │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ On-Premises │────────►│ Cloud │ │
│ │ Baseline │ Burst │ Overflow │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Base load on-prem, scale to cloud for peaks │
├─────────────────────────────────────────────────────────────┤
│ Pattern 2: Tiered Architecture │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ On-Premises │ │ Cloud │ │
│ │ Sensitive │◄───────►│ Less │ │
│ │ Data/Apps │ │ Sensitive │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Keep sensitive workloads on-prem, others in cloud │
├─────────────────────────────────────────────────────────────┤
│ Pattern 3: Edge + Cloud │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Edge │ │Edge │ │Edge │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ └───────┼───────┘ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Cloud │ │
│ │ Central │ │
│ └─────────────┘ │
│ │
│ Processing at edge, aggregation in cloud │
└─────────────────────────────────────────────────────────────┘Security Challenges:
Multi-Cloud Security Challenges:
COMPLEXITY MULTIPLICATION:
┌─────────────────────────────────────────────────────────────┐
│ Single Cloud: │
│ - Learn one IAM model │
│ - Master one networking model │
│ - Understand one compliance framework │
│ - Use one set of security tools │
│ │
│ Multi-Cloud (n clouds): │
│ - Learn n IAM models + federation │
│ - Master n networking models + interconnection │
│ - Understand n compliance frameworks + mapping │
│ - Use n security tools + aggregation │
│ - Manage n times the attack surface │
│ │
│ Skills required multiply, but teams don't │
└─────────────────────────────────────────────────────────────┘
KEY CHALLENGES:
┌─────────────────────────────────────────────────────────────┐
│ Identity: │
│ - Different IAM models (AWS IAM vs Azure AD vs GCP IAM) │
│ - Users need access to multiple clouds │
│ - Service accounts across clouds │
│ - No native cross-cloud trust │
│ │
│ Network: │
│ - Connecting clouds securely │
│ - Consistent network policies │
│ - DNS across environments │
│ - Traffic inspection and monitoring │
│ │
│ Visibility: │
│ - Different logging formats │
│ - Separate monitoring tools │
│ - No unified view │
│ - Alert correlation │
│ │
│ Compliance: │
│ - Different compliance tools │
│ - Mapping controls across platforms │
│ - Unified audit evidence │
│ - Consistent policy enforcement │
│ │
│ Operations: │
│ - Different APIs and CLIs │
│ - Separate IaC tools or modules │
│ - Incident response across platforms │
│ - Skills shortage │
└─────────────────────────────────────────────────────────────┘Key insight: Multi-cloud security is harder than single cloud. Only adopt multi-cloud if the benefits outweigh the complexity.
2) Identity Federation Across Clouds
Unified identity is the foundation of multi-cloud security. Users and services need consistent access across environments:
Identity Federation Architecture:
CENTRALIZED IDENTITY PATTERN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────┐ │
│ │ Central IdP │ │
│ │ (Azure AD / Okta) │ │
│ └───────────┬─────────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │ GCP │ │
│ │ (SAML/ │ │ (Native) │ │ (SAML/ │ │
│ │ OIDC) │ │ │ │ OIDC) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Users authenticate once, access all clouds │
└─────────────────────────────────────────────────────────────┘
AWS FEDERATION WITH AZURE AD:
┌─────────────────────────────────────────────────────────────┐
│ 1. Configure Azure AD as SAML provider in AWS │
│ │
│ # Create SAML provider │
│ aws iam create-saml-provider \ │
│ --saml-metadata-document file://azure-metadata.xml \ │
│ --name AzureAD │
│ │
│ 2. Create IAM role trusting Azure AD │
│ │
│ Trust Policy: │
│ { │
│ "Version": "2012-10-17", │
│ "Statement": [{ │
│ "Effect": "Allow", │
│ "Principal": { │
│ "Federated": "arn:aws:iam::123:saml-provider/Azure"│
│ }, │
│ "Action": "sts:AssumeRoleWithSAML", │
│ "Condition": { │
│ "StringEquals": { │
│ "SAML:aud": "https://signin.aws.amazon.com/saml" │
│ } │
│ } │
│ }] │
│ } │
│ │
│ 3. Configure Azure AD Enterprise Application │
│ - Add AWS as enterprise app │
│ - Configure SAML claims (RoleArn, etc.) │
│ - Assign users/groups │
│ │
│ 4. User flow: │
│ Azure AD login → SAML assertion → AWS STS → │
│ Temporary credentials → AWS access │
└─────────────────────────────────────────────────────────────┘
GCP FEDERATION WITH AZURE AD:
┌─────────────────────────────────────────────────────────────┐
│ Workload Identity Federation: │
│ │
│ # Create workload identity pool │
│ gcloud iam workload-identity-pools create azure-pool \ │
│ --location="global" │
│ │
│ # Create OIDC provider │
│ gcloud iam workload-identity-pools providers create-oidc \ │
│ azure-provider \ │
│ --workload-identity-pool="azure-pool" \ │
│ --issuer-uri="https://login.microsoftonline.com/{tenant}" │
│ --allowed-audiences="api://gcp-federation" │
│ │
│ # Grant access to service account │
│ gcloud iam service-accounts add-iam-policy-binding \ │
│ SA@project.iam.gserviceaccount.com \ │
│ --role="roles/iam.workloadIdentityUser" \ │
│ --member="principalSet://iam.googleapis.com/projects/.../ │
│ locations/global/workloadIdentityPools/azure-pool/*" │
└─────────────────────────────────────────────────────────────┘Service-to-Service Authentication:
Cross-Cloud Service Authentication:
CHALLENGE: SERVICE IN AWS NEEDS GCP RESOURCE
┌─────────────────────────────────────────────────────────────┐
│ │
│ AWS GCP │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Lambda │─────────────────►│ BigQuery │ │
│ │ │ How to │ │ │
│ │ │ authenticate? │ │ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
SOLUTION: WORKLOAD IDENTITY FEDERATION
┌─────────────────────────────────────────────────────────────┐
│ 1. AWS Lambda assumes IAM role │
│ 2. Lambda exchanges AWS credentials for GCP token │
│ 3. Lambda uses GCP token to access BigQuery │
│ │
│ No long-lived GCP service account keys! │
│ │
│ Configuration: │
│ - GCP Workload Identity Pool trusts AWS account │
│ - GCP Service Account bound to pool │
│ - Lambda has permission to assume GCP identity │
│ │
│ Code (Python): │
│ │
│ from google.auth import aws as google_aws │
│ from google.cloud import bigquery │
│ │
│ # Configure AWS-to-GCP credential exchange │
│ credentials = google_aws.Credentials.from_info({ │
│ "type": "external_account", │
│ "audience": "//iam.googleapis.com/projects/.../pools/", │
│ "subject_token_type": "urn:ietf:params:aws:token-type:\ │
│ aws4_request", │
│ "service_account_impersonation_url": "https://...", │
│ "credential_source": { │
│ "environment_id": "aws1", │
│ "regional_cred_verification_url": "..." │
│ } │
│ }) │
│ │
│ client = bigquery.Client(credentials=credentials) │
└─────────────────────────────────────────────────────────────┘
IDENTITY BEST PRACTICES:
┌─────────────────────────────────────────────────────────────┐
│ ✓ Single source of truth for human identities │
│ ✓ Federation, not credential copying │
│ ✓ No long-lived service account keys │
│ ✓ Workload identity federation for services │
│ ✓ Consistent group/role naming across clouds │
│ ✓ Centralized access reviews │
│ ✓ MFA everywhere │
│ ✓ Privileged access management │
└─────────────────────────────────────────────────────────────┘Key insight: Identity federation eliminates credential sprawl. Never copy credentials between clouds.
3) Network Connectivity
Secure connectivity between clouds and on-premises requires careful architecture:
Connectivity Options:
CLOUD-TO-CLOUD CONNECTIVITY:
┌─────────────────────────────────────────────────────────────┐
│ Option 1: Internet with VPN │
│ ┌─────────────┐ Internet ┌─────────────┐ │
│ │ AWS │◄──────────────►│ Azure │ │
│ │ VPN GW │ IPSec VPN │ VPN GW │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Pros: Simple, cost-effective │
│ Cons: Variable latency, internet dependency │
├─────────────────────────────────────────────────────────────┤
│ Option 2: Private Interconnect │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │
│ │ Direct │ │ Express │ │
│ │ Connect │ │ Route │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ ┌──────────────┐ │ │
│ └───►│ Colo/IX │◄─────────┘ │
│ │ (Equinix) │ │
│ └──────────────┘ │
│ │
│ Pros: Consistent latency, private, high bandwidth │
│ Cons: Expensive, requires physical presence │
├─────────────────────────────────────────────────────────────┤
│ Option 3: Third-Party SD-WAN │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │
│ └──────┬──────┘ └──────┬──────┘ │
│ │ ┌──────────────┐ │ │
│ └───►│ SD-WAN │◄─────────┘ │
│ │ (Aviatrix) │ │
│ └──────────────┘ │
│ │
│ Pros: Unified management, advanced features │
│ Cons: Additional cost and complexity │
└─────────────────────────────────────────────────────────────┘
AWS TO AZURE VPN CONFIGURATION:
┌─────────────────────────────────────────────────────────────┐
│ AWS Side: │
│ 1. Create Virtual Private Gateway │
│ 2. Create Customer Gateway (Azure VPN Gateway IP) │
│ 3. Create Site-to-Site VPN Connection │
│ 4. Download VPN configuration │
│ 5. Update route tables │
│ │
│ Azure Side: │
│ 1. Create Virtual Network Gateway │
│ 2. Create Local Network Gateway (AWS VPN endpoints) │
│ 3. Create Connection with shared key │
│ 4. Configure BGP (optional) or static routes │
│ │
│ Security Considerations: │
│ - Use IKEv2 with strong encryption (AES-256) │
│ - Rotate pre-shared keys regularly │
│ - Enable BGP for dynamic routing │
│ - Monitor VPN tunnel status │
│ - Use redundant tunnels │
└─────────────────────────────────────────────────────────────┘Hybrid Connectivity:
On-Premises to Multi-Cloud:
HUB AND SPOKE ARCHITECTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ │
│ │ On-Premises │ │
│ │ (Hub) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │ GCP │ │
│ │ (Spoke) │ │ (Spoke) │ │ (Spoke) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Traffic flows through on-prem hub │
│ Centralized security inspection │
└─────────────────────────────────────────────────────────────┘
CLOUD-NATIVE HUB:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Transit Network (AWS Transit GW) │ │
│ │ or │ │
│ │ Azure Virtual WAN │ │
│ └───────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │On-Prem │ │ AWS │ │ Azure │ │
│ │ │ │ VPCs │ │ VNets │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ Cloud-native hub with centralized routing and inspection │
└─────────────────────────────────────────────────────────────┘
DNS IN MULTI-CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ Challenge: Consistent name resolution across environments │
│ │
│ Options: │
│ 1. Centralized DNS (on-prem or dedicated service) │
│ - All environments forward to central │
│ - Central manages all zones │
│ │
│ 2. DNS forwarding/delegation │
│ - Each cloud manages its zones │
│ - Forwarding rules for cross-cloud resolution │
│ │
│ 3. DNS peering │
│ - AWS Route 53 Resolver endpoints │
│ - Azure Private DNS zone links │
│ - GCP Cloud DNS forwarding │
│ │
│ Security: │
│ - Use private DNS for internal resources │
│ - Enable DNS logging │
│ - Monitor for DNS tunneling │
│ - DNSSEC for public zones │
└─────────────────────────────────────────────────────────────┘Key insight: Network complexity grows exponentially with clouds. Consider a dedicated network team for multi-cloud.
4) Unified Security Monitoring
Visibility across all environments is essential for detecting threats that span clouds:
Multi-Cloud Monitoring Architecture:
CENTRALIZED SIEM PATTERN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ AWS │ │ Azure │ │ GCP │ │
│ │ CloudTrail │ │ Activity │ │ Audit │ │
│ │ GuardDuty │ │ Logs │ │ Logs │ │
│ │ VPC Flow │ │ Sentinel │ │ Chronicle │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Central SIEM │ │
│ │ (Splunk/Elk/ │ │
│ │ Sentinel) │ │
│ └───────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ SOC Team │ │
│ │ Dashboard │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
LOG COLLECTION FROM EACH CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ AWS: │
│ - CloudTrail → S3 → Lambda → SIEM │
│ - VPC Flow Logs → CloudWatch → Kinesis → SIEM │
│ - GuardDuty → EventBridge → Lambda → SIEM │
│ │
│ Azure: │
│ - Activity Logs → Event Hub → SIEM │
│ - Diagnostic Logs → Event Hub → SIEM │
│ - Sentinel → Direct export or API │
│ │
│ GCP: │
│ - Audit Logs → Pub/Sub → SIEM │
│ - VPC Flow Logs → Pub/Sub → SIEM │
│ - Security Command Center → Pub/Sub → SIEM │
│ │
│ On-Premises: │
│ - Syslog → Forwarder → SIEM │
│ - Windows Event Logs → Agent → SIEM │
└─────────────────────────────────────────────────────────────┘
LOG NORMALIZATION CHALLENGE:
┌─────────────────────────────────────────────────────────────┐
│ Same event, different formats: │
│ │
│ AWS CloudTrail: │
│ { │
│ "userIdentity": {"arn": "arn:aws:iam::123:user/alice"}, │
│ "eventName": "ConsoleLogin", │
│ "sourceIPAddress": "192.0.2.1" │
│ } │
│ │
│ Azure Activity Log: │
│ { │
│ "caller": "alice@company.com", │
│ "operationName": "Microsoft.Portal/SignIn", │
│ "callerIpAddress": "192.0.2.1" │
│ } │
│ │
│ GCP Audit Log: │
│ { │
│ "principalEmail": "alice@company.com", │
│ "methodName": "google.login.LoginService.loginSuccess", │
│ "requestMetadata": {"callerIp": "192.0.2.1"} │
│ } │
│ │
│ Solution: Normalize to common schema (OCSF, ECS, etc.) │
└─────────────────────────────────────────────────────────────┘Cloud Security Posture Management:
Multi-Cloud CSPM:
CSPM TOOLS:
┌─────────────────────────────────────────────────────────────┐
│ Vendor Tools: │
│ - Palo Alto Prisma Cloud │
│ - Wiz │
│ - Orca Security │
│ - Lacework │
│ - Aqua Security │
│ │
│ Cloud-Native Tools: │
│ - AWS Security Hub │
│ - Azure Defender for Cloud │
│ - GCP Security Command Center │
│ │
│ Open Source: │
│ - Prowler (AWS focus, expanding) │
│ - ScoutSuite (multi-cloud) │
│ - CloudSploit │
└─────────────────────────────────────────────────────────────┘
CSPM CAPABILITIES:
┌─────────────────────────────────────────────────────────────┐
│ ✓ Asset inventory across clouds │
│ ✓ Misconfiguration detection │
│ ✓ Compliance mapping (CIS, SOC2, PCI) │
│ ✓ Risk prioritization │
│ ✓ Remediation guidance │
│ ✓ Drift detection │
│ ✓ Attack path analysis │
│ ✓ Identity analysis │
└─────────────────────────────────────────────────────────────┘
UNIFIED DASHBOARD METRICS:
┌─────────────────────────────────────────────────────────────┐
│ Security Posture Score (by cloud and overall) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Overall: 78% AWS: 82% Azure: 75% GCP: 71% │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ Critical Findings: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ AWS: 3 public S3 buckets │ │
│ │ Azure: 5 VMs with public IPs │ │
│ │ GCP: 2 projects with overprivileged service accounts │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Compliance Status: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ CIS AWS: 89% CIS Azure: 84% CIS GCP: 81% │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘Key insight: You need a single pane of glass, but it takes significant effort to achieve meaningful multi-cloud visibility.
5) Cloud-Agnostic Security Frameworks
Frameworks help maintain consistent security across diverse environments:
Security Framework Mapping:
CIS CONTROLS ACROSS CLOUDS:
┌─────────────────────────────────────────────────────────────┐
│ CIS Control │ AWS │ Azure │ GCP │
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Asset Inventory │ Config │ Resource │ Asset │
│ │ │ Graph │ Inventory│
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Vulnerability Mgmt │ Inspector │ Defender │ Security │
│ │ │ │ Scanner │
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Access Control │ IAM │ Azure AD │ Cloud │
│ │ │ /RBAC │ IAM │
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Audit Logging │ CloudTrail │ Activity │ Audit │
│ │ │ Logs │ Logs │
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Network Security │ VPC/SG/NACL │ VNet/NSG │ VPC/ │
│ │ │ │ Firewall │
├──────────────────────┼────────────────┼──────────┼──────────┤
│ Data Protection │ KMS/S3 encrypt │ Key Vault│ Cloud │
│ │ │ /Storage │ KMS │
└──────────────────────┴────────────────┴──────────┴──────────┘
POLICY AS CODE ACROSS CLOUDS:
┌─────────────────────────────────────────────────────────────┐
│ Open Policy Agent (OPA): │
│ │
│ # Universal policy - encryption required │
│ package multicloud.storage │
│ │
│ # AWS S3 │
│ deny[msg] { │
│ input.resource_type == "aws_s3_bucket" │
│ not input.server_side_encryption_configuration │
│ msg := "S3 bucket must have encryption enabled" │
│ } │
│ │
│ # Azure Storage │
│ deny[msg] { │
│ input.resource_type == "azurerm_storage_account" │
│ input.enable_https_traffic_only != true │
│ msg := "Storage account must require HTTPS" │
│ } │
│ │
│ # GCP Cloud Storage │
│ deny[msg] { │
│ input.resource_type == "google_storage_bucket" │
│ not input.encryption │
│ msg := "GCS bucket must have encryption enabled" │
│ } │
│ │
│ Same policy intent, cloud-specific implementation │
└─────────────────────────────────────────────────────────────┘Kubernetes as Abstraction Layer:
Kubernetes Multi-Cloud Security:
KUBERNETES AS COMMON PLATFORM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────┐ │
│ │ Kubernetes Security │ │
│ │ (Pod Security, RBAC, │ │
│ │ Network Policies) │ │
│ └─────────────────────────────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ EKS │ │ AKS │ │ GKE │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Same Kubernetes security controls work everywhere │
└─────────────────────────────────────────────────────────────┘
PORTABLE SECURITY CONTROLS:
┌─────────────────────────────────────────────────────────────┐
│ Network Policies (same YAML across clouds): │
│ │
│ apiVersion: networking.k8s.io/v1 │
│ kind: NetworkPolicy │
│ metadata: │
│ name: default-deny-all │
│ spec: │
│ podSelector: {} │
│ policyTypes: │
│ - Ingress │
│ - Egress │
│ │
│ Pod Security Standards (same across clouds): │
│ │
│ apiVersion: v1 │
│ kind: Namespace │
│ metadata: │
│ name: production │
│ labels: │
│ pod-security.kubernetes.io/enforce: restricted │
│ │
│ RBAC (same across clouds): │
│ Kind: Role, ClusterRole, RoleBinding, ClusterRoleBinding │
│ Works identically on EKS, AKS, GKE │
└─────────────────────────────────────────────────────────────┘
MULTI-CLUSTER SECURITY TOOLS:
┌─────────────────────────────────────────────────────────────┐
│ Falco: Runtime security across clusters │
│ - Same rules on EKS, AKS, GKE │
│ - Centralized alert aggregation │
│ │
│ Kyverno/OPA Gatekeeper: Policy enforcement │
│ - Same policies across clusters │
│ - Admission control │
│ │
│ Trivy: Image scanning │
│ - Scan images regardless of destination cluster │
│ - Integrate in CI/CD before multi-cloud deployment │
└─────────────────────────────────────────────────────────────┘Key insight: Kubernetes provides a common security abstraction, but cloud-specific integrations (IAM, networking) still differ.
Real-World Context
Case Study: Multi-Cloud Credential Sprawl
A financial services company operated in AWS, Azure, and GCP without centralized identity. Each cloud had separate users, service accounts, and credential management. An employee who left the company was deprovisioned from Azure AD (their primary directory) but retained active AWS IAM user and GCP service account credentials. The former employee accessed sensitive data in AWS months later. Post-incident, the company implemented SAML federation from Azure AD to all clouds, eliminated direct cloud credentials, and established automated deprovisioning that revoked access across all environments.
Case Study: Lateral Movement Across Clouds
Attackers compromised a developer's laptop with access to multiple clouds. Using cached credentials and CLI configurations, they moved from AWS to Azure to GCP, exfiltrating data from each. The organization's cloud-specific security tools each detected suspicious activity, but alerts weren't correlated. The full scope wasn't understood until forensic analysis weeks later. Post-incident improvements included centralized SIEM with cross-cloud correlation rules, unified identity with session monitoring, and network segmentation between clouds.
Multi-Cloud Security Checklist:
Multi-Cloud Security Checklist:
IDENTITY:
□ Centralized identity provider
□ SAML/OIDC federation to all clouds
□ No direct cloud credentials for humans
□ Workload identity federation for services
□ Consistent naming conventions
□ Centralized access reviews
□ Automated deprovisioning
NETWORK:
□ Secure inter-cloud connectivity
□ Centralized DNS management
□ Consistent network segmentation
□ Traffic inspection capability
□ Network monitoring across clouds
MONITORING:
□ Centralized log aggregation
□ Log normalization to common schema
□ Cross-cloud correlation rules
□ Unified alerting
□ Multi-cloud CSPM tool
□ Single dashboard for posture
COMPLIANCE:
□ Control mapping across clouds
□ Unified compliance reporting
□ Consistent policy enforcement
□ Automated remediation
□ Regular multi-cloud assessments
GOVERNANCE:
□ Multi-cloud security standards
□ Approved service catalog
□ Architecture review process
□ Cost and security tradeoff guidelines
□ Skills development planMulti-cloud done poorly is worse than single cloud. Invest in consistency or simplify to fewer clouds.
Guided Lab: Multi-Cloud Identity Federation
In this lab, you'll configure identity federation between cloud providers.
Lab Environment:
- AWS account
- Azure account with Azure AD
- GCP project
- Admin access to all platforms
Exercise Steps:
- Configure Azure AD as central IdP
- Create AWS SAML provider for Azure AD
- Configure AWS IAM roles for federated access
- Create GCP Workload Identity Pool
- Configure GCP OIDC provider for Azure AD
- Test user authentication to both clouds via Azure AD
- Configure service-to-service authentication
- Document federation architecture
- Test deprovisioning flow
Reflection Questions:
- What breaks if the central IdP goes down?
- How do you handle cloud-specific permissions?
- What monitoring would you implement?
Week Outcome Check
By the end of this week, you should be able to:
- Explain multi-cloud and hybrid architecture patterns
- Identify security challenges specific to multi-cloud environments
- Configure identity federation between cloud providers
- Implement workload identity federation for services
- Design secure network connectivity between clouds
- Architect centralized security monitoring across clouds
- Map security frameworks to multi-cloud implementations
- Use Kubernetes as a security abstraction layer
🎯 Hands-On Labs (Free & Essential)
Master multi-cloud and hybrid security with cross-platform identity and unified monitoring.
🌐 TryHackMe: Multi-Cloud Security
What you'll do: Configure identity federation across AWS and Azure—implement
SSO, cross-cloud access, and unified governance.
Why it matters: Real enterprises use multiple clouds—learn to secure them
consistently.
Time estimate: 3-4 hours
☁️ Google Cloud Skills Boost: Hybrid Connectivity
What you'll do: Build secure hybrid cloud architectures with VPN, Interconnect,
and identity federation (free labs).
Why it matters: Hybrid architectures are common—on-prem to cloud security
is critical.
Time estimate: 2-3 hours
🔍 Open Policy Agent: Policy as Code Lab
What you'll do: Write cloud-agnostic policies with OPA (Open Policy
Agent)—enforce security across AWS, Azure, and GCP.
Why it matters: Consistent policy across clouds requires abstraction—OPA
provides it.
Time estimate: 2-3 hours
💡 Lab Strategy: Multi-cloud security is about abstraction—master identity federation and you solve 70% of the challenge.
Resources
Lab
Complete the following lab exercises to practice multi-cloud security.