🔷CIS GCP 1.4Rule: GCP-IAM-004critical

Ensure no service accounts have admin privileges

Description

Service accounts should not be granted Owner, Editor, or broad admin roles.

⚠️ Risk Impact

Overprivileged service accounts are the #1 cloud breach vector. If compromised, they grant unrestricted access to all project resources.

🔍 How EchelonGraph Detects This

GCP-IAM-004Automated scanner rule

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

🖥️ Manual Verification

terminal
gcloud projects get-iam-policy PROJECT_ID --format=json | jq '.bindings[] | select(.role=="roles/owner" or .role=="roles/editor") | .members[] | select(startswith("serviceAccount:"))'

🔧 Remediation

Replace roles/owner and roles/editor with granular predefined roles following the principle of least privilege.

💀 Real-World Attack Scenario

A Kubernetes pod running a web application used a service account with roles/editor. The application had an SSRF vulnerability that allowed the attacker to access the metadata server, retrieve the service account token, and use the Editor permissions to create a new service account with Owner role — achieving full project takeover within 4 minutes.

💰 Cost of Non-Compliance

Tesla 2018: Overprivileged cloud credentials led to cryptomining on exposed Kubernetes cluster. Average overprivileged-account breach cost: $4.45M. Privilege escalation attacks increase breach cost by 22% compared to non-escalation breaches.

📋 Audit Questions

  • 1.List all service accounts with Owner or Editor roles.
  • 2.What is your justification for each elevated permission?
  • 3.How often do you review service account permissions?
  • 4.Do you have an automated process to detect privilege escalation?

🎯 MITRE ATT&CK Mapping

T1078.004 — Cloud AccountsT1098 — Account ManipulationT1548 — Abuse Elevation Control Mechanism

🏗️ Infrastructure as Code Fix

main.tf
# WRONG — overprivileged:
# resource "google_project_iam_member" "sa_editor" {
#   role   = "roles/editor"
#   member = "serviceAccount:${google_service_account.app.email}"
# }

# CORRECT — least privilege:
resource "google_project_iam_member" "sa_storage" {
  project = var.project_id
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:${google_service_account.app.email}"
}
resource "google_project_iam_member" "sa_bigquery" {
  project = var.project_id
  role    = "roles/bigquery.dataViewer"
  member  = "serviceAccount:${google_service_account.app.email}"
}

⚡ Common Pitfalls

  • Using roles/editor as a 'quick fix' during development and never removing it
  • Custom roles that aggregate too many permissions, effectively recreating Editor
  • Not auditing permissions inherited through group memberships

📈 Business Value

Least-privilege service accounts reduce blast radius by 95% in breach scenarios. Insurance underwriters increasingly require evidence of privilege minimization. This control directly reduces mean-time-to-contain by preventing lateral movement.

⏱️ Effort Estimate

Manual

8-16 hours to audit all service accounts and map required permissions

With EchelonGraph

EchelonGraph identifies all overprivileged service accounts in <60 seconds and recommends least-privilege replacements

🔗 Cross-Framework References

SOC2-CC6.3ISO27001-A.9.2.3NIST-AC-6

Automate CIS GCP 1.4 compliance

EchelonGraph continuously monitors this control across all your cloud accounts.

Start Free →