Multi-Cloud Governance -- Security¶

Identity federation, access control, compliance baselines, and threat-modeling patterns for multi-cloud environments spanning AWS, GCP, Alibaba Cloud, and Tencent Cloud.

Identity Federation¶

Problem¶

Each cloud has its own IAM system (AWS IAM, GCP IAM, Alibaba RAM, Tencent CAM). Without federation, operators maintain separate credentials per cloud, violating the principle of centralized identity governance and creating credential-sprawl risk.

Federation Protocols¶

Protocol	Primary Use	Token Format
SAML 2.0	Human user SSO (browser-based)	XML assertion
OIDC (OpenID Connect)	Workload identity, service-to-service	JWT
OAuth 2.0	API authorization, consent flows	Bearer token

Per-Cloud Federation Configuration¶

AWS¶

IAM Identity Center (successor to AWS SSO): Accepts SAML assertions from an external IdP. Maps SAML attributes to AWS permission sets.
IAM OIDC Federation: Accepts OIDC tokens from trusted IdPs (Okta, Entra ID, GitHub Actions). Used for workload identity (CI/CD assuming AWS roles).
Key config: SAML provider in IAM, trust policy with sts:AssumeRoleWithSAML, OIDC provider with sts:AssumeRoleWithWebIdentity.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::ACCOUNT::saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "SAML:aud": "https://signin.aws.amazon.com/saml"
      }
    }
  }]
}

GCP¶

Workforce Identity Federation: SAML/OIDC federation for human users. Maps external IdP groups to GCP IAM roles.
Workload Identity Federation: OIDC federation for service accounts. A GitHub Actions OIDC token, for example, can impersonate a GCP service account without static keys.
Key config: WorkloadIdentityPoolProvider (OIDC or SAML), IAM policy binding the pool identity to a service account.

# GCP Workload Identity Pool Provider for GitHub Actions
resource "google_iam_workload_identity_pool_provider" "github" {
  workload_identity_pool_id = google_iam_workload_identity_pool.github.pool_id
  provider_id               = "github-actions"
  attribute_mapping = {
    "google.subject"            = "assertion.sub"
    "attribute.repository"      = "assertion.repository"
    "attribute.branch"          = "assertion.ref"
  }
  oidc {
    issuer_uri = "https://token.actions.githubusercontent.com"
  }
}

Alibaba Cloud¶

RAM SSO (SAML): Supports SAML-based SSO with external IdPs (Okta, Azure AD, OneLogin). Configured via RAM console: Identity Provider > SAML provider > role mapping.
RAM OIDC Federation: Accepts OIDC tokens for workload identity. RAM roles can be assumed via AssumeRoleWithOIDCToken API.
Key config: SAML provider in RAM, OIDC provider in RAM, RAM role with trust policy referencing the provider.

# Alibaba RAM OIDC role trust policy
{
  "Statement": [{
    "Action": "sts:AssumeRoleWithOIDC",
    "Effect": "Allow",
    "Principal": {
      "OIDC": "acs:ram::ACCOUNT:oidc-provider/okta-provider"
    },
    "Condition": {
      "StringEquals": {
        "oidc:aud": "alibaba-cloud-oidc"
      }
    }
  }],
  "Version": "1"
}

Tencent Cloud¶

CAM SAML Federation: Supports SAML SSO with enterprise IdPs. Configured via CAM console: Identity Provider > SAML > role-for-SAML.
CAM OIDC Federation: OIDC-based role assumption for workloads. CAM roles with OIDC trust policies accept JWTs from trusted issuers.
Key config: SAML provider in CAM, OIDC provider in CAM, role with sts:AssumeRoleWithWebIdentity trust policy.

Recommended Federation Architecture¶

                    [ Central IdP ]
                    (Okta / Entra ID / Keycloak)
                    /      |         |          \
              SAML  /  OIDC|    SAML |    SAML  \
                  /        |         |            \
          [ AWS IAM      [ GCP IAM ] [ Alibaba  [ Tencent
          Identity       Workforce   RAM         CAM
          Center ]       / Workload  SSO+OIDC ] SSO+OIDC ]
                        Identity
                        Federation ]

Best practices:

Use SAML 2.0 for human user SSO across all clouds.
Use OIDC for workload-to-workload and CI/CD identity federation.
Map IdP groups to cloud roles with least-privilege permission sets. Avoid mapping individual users.
Enforce MFA at the IdP level; require MFA in cloud role trust conditions where supported.
Centralize audit logs (CloudTrail, Cloud Audit Log, ActionTrail, CloudAudit) into a SIEM.
Rotate IdP signing certificates on a regular cadence with overlap periods.
Use conditional access policies (device compliance, IP ranges) at the IdP layer.

SPIFFE / SPIRE for Workload Identity¶

SPIFFE (Secure Production Identity Framework for Everyone) provides a cloud-agnostic workload identity layer. SPIRE is its reference implementation.

Each workload gets a SPIFFE ID (e.g., spiffe://example.org/billing-service).
SPIRE agents on each node issue X.509 SVIDs (SPIFFE Verifiable Identity Documents) to workloads via workload API.
mTLS between workloads is bootstrapped by SVIDs, independent of cloud-specific IAM.
In a multi-cloud Kubernetes deployment, SPIRE federates trust domains across clusters, enabling workloads on AWS to authenticate workloads on Alibaba Cloud without cloud-specific trust configuration.

Integration points:

Component	Integration
Istio	SPIRE as the CA backend for Istio mTLS
Envoy	SDS (Secret Discovery Service) with SPIRE
Kubernetes	SPIRE via CSI driver or DaemonSet
Cloud KMS	SPIRE server keys stored in AWS KMS / GCP KMS / Alibaba KMS

Workload Identity Comparison¶

Feature	AWS	GCP	Alibaba	Tencent
Service accounts	IAM Roles for Service Accounts	GCP Service Accounts	RAM Roles for ECS/ACK	CAM Roles for CVM/TKE
OIDC federation	IAM OIDC Provider	Workload Identity Federation	RAM OIDC	CAM OIDC
K8s integration	IRSA (IAM Roles for SA)	Workload Identity	RRSA (RAM Roles for SA)	TKE CAM Pod Identity
CI/CD identity	OIDC from GitHub/GitLab	OIDC pool providers	OIDC provider in RAM	OIDC provider in CAM
Token lifetime	Configurable (900s-12h)	1h default, configurable	900s-3600s	Configurable

Security Baseline and Compliance¶

CIS Benchmarks¶

The Center for Internet Security publishes cloud-specific benchmarks with Level 1 (prescriptive, minimal disruption) and Level 2 (proactive, more restrictive) controls.

Cloud	Benchmark	Key Areas
AWS	CIS AWS Foundations Benchmark v2.0	IAM (root account, MFA, password policy), logging (CloudTrail, Config), networking (VPC flow logs, default SG), encryption (S3, EBS, RDS)
GCP	CIS GCP Foundations Benchmark v2.0	IAM (service account keys, org policies), logging (Audit Logs), networking (VPC flow logs, firewall rules), storage (bucket policy)
Alibaba Cloud	CIS Alibaba Cloud Foundations Benchmark	RAM (root account, MFA, access keys), ActionTrail, Security Center, VPC flow logs, OSS encryption
Tencent Cloud	TBD -- no official CIS benchmark as of 2025; use CSA CCM and Tencent Cloud Security Baseline	CAM, CloudAudit, Security Center, VPC flow logs, COS encryption

Compliance Frameworks¶

Framework	Scope	Multi-Cloud Relevance
ISO 27001/27017/27018	InfoSec management, cloud security, PII in cloud	Audit once, covers all cloud providers
SOC 2 Type II	Trust service criteria (security, availability, confidentiality)	Each cloud provider has SOC 2 reports; inherit controls
NIST CSF 2.0	Cybersecurity functions (Identify, Protect, Detect, Respond, Recover)	Maps to all cloud providers' compliance offerings
PCI DSS 4.0	Payment card data	Network segmentation and encryption enforced per cloud
HIPAA	Healthcare data (US)	BAA required with each cloud provider
GDPR / PIPL	Data privacy (EU / China)	Data residency enforcement per cloud region
CSA CCM v4	Cloud-specific controls matrix	Cross-cloud assessment framework
MITRE ATT&CK Cloud	Adversary tactics and techniques for cloud	Threat model across AWS, GCP, Azure, Alibaba

Automated Compliance Scanning¶

Tool	Clouds Covered	CIS Benchmarks	License
Prowler	AWS, Azure, GCP	Yes	Apache 2.0
ScoutSuite	AWS, Azure, GCP, Alibaba	Partial	GPL 2.0
Checkov	AWS, Azure, GCP, Alibaba (via Terraform)	Partial (IaC scanning)	Apache 2.0
tfsec	AWS, Azure, GCP (Terraform)	Partial	MIT
GCP Security Command Center	GCP	Yes (built-in)	Managed service
AWS Security Hub	AWS	Yes (CIS benchmark standard)	Managed service
Alibaba Cloud Security Center	Alibaba	Partial (baseline checks)	Managed service
Prisma Cloud (Palo Alto)	AWS, Azure, GCP, Alibaba	Yes	Commercial
Wiz	AWS, Azure, GCP, Alibaba, Tencent	Yes	Commercial
Orca Security	AWS, Azure, GCP, Alibaba	Yes	Commercial

Policy-as-Code Enforcement¶

Tool	Scope	Language	Integration
OPA / Gatekeeper	Kubernetes resources	Rego	Admission controller in each cluster
HashiCorp Sentinel	Terraform operations	Sentinel (HCL-like)	Terraform Cloud / Enterprise
AWS Service Control Policies (SCPs)	AWS Organizations	JSON policy	AWS-level
Azure Policy	Azure resources	JSON / aliases	Azure-level
GCP Organization Policy	GCP resources	Constraint templates	GCP-level
Alibaba RAM Control Policies	Alibaba resources	JSON policy	Alibaba-level
Kyverno	Kubernetes resources	YAML-native	K8s admission controller
Cloud Custodian	AWS, Azure, GCP	YAML	Event-driven, serverless

Multi-Cloud Security Baseline Checklist¶

This is a minimal cross-cloud baseline. Adapt per compliance requirements.

Identity and Access:

Root/admin account has MFA enabled and is not used for daily operations.
Federation configured via SAML/OIDC from a single IdP to all clouds.
No long-lived access keys for human users; use temporary credentials via federation.
Service accounts use workload identity (IRSA, Workload Identity, RRSA, TKE Pod Identity) rather than static keys.
Least-privilege role mapping from IdP groups to cloud roles.
Regular access reviews (quarterly) for all cross-cloud roles.

Networking:

No 0.0.0.0/0 ingress rules on security groups / firewall rules.
VPC flow logs enabled in all clouds.
Inter-cloud traffic traverses private interconnect (Direct Connect, Interconnect, Express Connect), not public internet.
Network segmentation between environments (dev/staging/prod) via separate VPCs or projects.

Data Protection:

Encryption at rest enabled for all storage services (S3, GCS, OSS, COS) using cloud KMS or customer-managed keys.
Encryption in transit enforced (TLS 1.2+) for all inter-service and client-to-service communication.
Secrets stored in dedicated secret stores (Vault, AWS Secrets Manager, GCP Secret Manager, Alibaba KMS), not in environment variables or code.

Logging and Monitoring:

Cloud audit logs enabled in all clouds (CloudTrail, Cloud Audit Log, ActionTrail, CloudAudit).
Logs centralized in a SIEM or log aggregation platform.
Alerting on suspicious activity (root account usage, new admin role creation, security group changes).
Container runtime security monitoring (Falco) deployed on all clusters.

Incident Response:

Incident response plan covers multi-cloud scenarios (e.g., compromised credentials in one cloud affecting federated access to others).
Automated playbook for revoking federation trust in the IdP (kill switch).
Regular tabletop exercises covering cross-cloud incident scenarios.

Threat Model¶

Multi-Cloud-Specific Threats¶

Threat	Description	Mitigation
Credential compromise in one cloud leading to lateral movement	Attacker obtains credentials for one cloud and attempts to pivot to others via shared identity	Conditional access policies, IP-based trust conditions, MFA requirement in trust policies, SPIFFE workload identity boundary
Misconfigured federation trust policy	Overly broad SAML/OIDC trust allows any user from the IdP to assume high-privilege roles	Tight attribute conditions in trust policies, group-to-role mapping with least privilege
Inconsistent security baseline across clouds	Different teams manage different clouds with varying security posture	CIS benchmark scanning, Policy-as-Code, cross-cloud security dashboards
Data exfiltration via inter-cloud transfer	Attacker moves data from a secured cloud to a less-secured cloud or external endpoint	DLP policies, egress filtering, data residency constraints, flow-log anomaly detection
Supply chain attack on IaC modules	Compromised Terraform module or Helm chart deploys malicious infrastructure	Pin module versions, scan IaC with Checkov/tfsec, sign commits, require PR approval
DNS hijacking across multi-cloud zones	Attacker compromises DNS credentials and redirects traffic	DNSSEC, multi-factor authentication on DNS registrar, DNS change monitoring
Cloud provider supply chain	Vulnerability in managed service affects workloads	Multi-cloud deployment for critical workloads, regular patch cycle, vulnerability scanning