Description
Granting roles/editor, roles/owner or unnecessary administrative permissions to a service account increases the impact of automation errors or account compromise. Applications, batch jobs and CI/CD should receive only the permissions they need.
Some tasks legitimately require writes or administration. Review the actual permissions and scope rather than treating a role name alone as proof of unnecessary access.
Potential impact
- A compromised service account can modify many resources or access data.
- Automation mistakes can cause greater damage when excessive permissions are available.
Remediation
- Identify required permissions and resources, and replace broad owner or editor grants with suitable predefined or custom roles.
- Regularly review role bindings and who can use the service account. After changes, verify that required actions succeed and unnecessary actions are denied.
Examples
Supply the actual service-account email through var.service_account_email. google_iam_policy generates a policy document; it does not apply permissions until used on a target resource. The after role illustrates a task that only reads objects.
Before
hcl
data "google_iam_policy" "policy" {
binding {
role = "roles/editor"
members = [
"serviceAccount:${var.service_account_email}",
]
}
}
After
hcl
data "google_iam_policy" "policy" {
binding {
role = "roles/storage.objectViewer"
members = [
"serviceAccount:${var.service_account_email}",
]
}
}
Explanation:
- Before: A policy document with the broad Editor role is generated. Review its actual application scope and task requirements.
- After: The role is changed to Storage Object Viewer. Apply it at the required bucket scope and review other grants too.