🔷CIS GCP 1.6Rule: GCP-IAM-006high

Ensure IAM roles do not include cross-project permissions

Description

Service accounts should not have IAM bindings in other projects unless explicitly required.

⚠️ Risk Impact

Cross-project permissions expand the blast radius of a compromise. A breached service account in one project can pivot to other projects.

🔍 How EchelonGraph Detects This

GCP-IAM-006Automated scanner rule

EchelonGraph's Tier 1 Cloud Scanner automatically checks for this condition across all connected Google Cloud accounts. Violations are flagged as high-severity findings with remediation guidance.

🖥️ Manual Verification

terminal
gcloud asset search-all-iam-policies --scope=organizations/ORG_ID --query='policy:serviceAccount' --format=json

🔧 Remediation

Audit cross-project bindings. Use VPC Service Controls to create security perimeters.

💀 Real-World Attack Scenario

An attacker compromised a staging project service account through an exposed debug endpoint. The service account had a binding in the production project for 'historical data migration' that was never revoked. The attacker pivoted from staging to production and accessed 2.1M customer records.

💰 Cost of Non-Compliance

Multi-project breaches cost on average 2.8x more than single-project breaches due to expanded scope of forensic investigation and data exposure. Average cost: $8.2M vs $2.9M.

📋 Audit Questions

  • 1.Map all cross-project IAM bindings for every service account.
  • 2.What is the business justification for each cross-project binding?
  • 3.How often are cross-project permissions reviewed?
  • 4.Do you use VPC Service Controls to enforce project boundaries?

🎯 MITRE ATT&CK Mapping

T1078.004 — Cloud AccountsT1021 — Remote ServicesT1550 — Use Alternate Authentication Material

🏗️ Infrastructure as Code Fix

main.tf
# Use VPC Service Controls to prevent cross-project access:
resource "google_access_context_manager_service_perimeter" "prod" {
  parent = "accessPolicies/${var.access_policy_id}"
  name   = "accessPolicies/${var.access_policy_id}/servicePerimeters/prod_perimeter"
  title  = "Production Perimeter"
  status {
    resources = ["projects/${var.prod_project_number}"]
    restricted_services = ["bigquery.googleapis.com", "storage.googleapis.com"]
  }
}

⚡ Common Pitfalls

  • Legacy data migration bindings that were never cleaned up
  • Using organization-level roles when project-level would suffice
  • Not using VPC Service Controls to enforce boundaries even when IAM is correct

📈 Business Value

Project-level isolation ensures that a breach in one environment cannot cascade to others. This is the cloud equivalent of network segmentation — it limits blast radius and enables confident multi-team cloud usage.

⏱️ Effort Estimate

Manual

4-8 hours to audit cross-project bindings across an organization

With EchelonGraph

EchelonGraph maps all cross-project service account bindings in <2 minutes

🔗 Cross-Framework References

SOC2-CC6.3ISO27001-A.13.1.3

Automate CIS GCP 1.6 compliance

EchelonGraph continuously monitors this control across all your cloud accounts.

Start Free →