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
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
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
🏗️ Infrastructure as Code Fix
# 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
8-16 hours to audit all service accounts and map required permissions
EchelonGraph identifies all overprivileged service accounts in <60 seconds and recommends least-privilege replacements
🔗 Cross-Framework References
Automate CIS GCP 1.4 compliance
EchelonGraph continuously monitors this control across all your cloud accounts.
Start Free →