# 1.6 Ensure IAM Users Are Not Assigned Service Account User or Service Account Token Creator Roles at the Project Level (Automated) - Source: https://support.icompaas.com/support/solutions/articles/62000232882-16-ensure-iam-users-are-not-assigned-service-account-user-or-service-account-token-creator-roles-at-the-project-level-au - Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178) - Last updated: 2026-06-16 - Publisher: iCompaas, Inc. (https://www.icompaas.com) Profile Applicability:Level 1 Description: The roles Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) should be assigned to IAM users at the service account level, not at the project level, to follow the principle of least privilege. Rationale: Service accounts act as identities for applications or virtual machines (VMs) to interact with Google Cloud services. Granting Service Account User or Service Account Token Creator roles at the project level gives IAM users unrestricted access to all service accounts within the project, including those created in the future. This can lead to privilege escalation, as these roles allow: - Binding service accounts to jobs (via iam.serviceAccountUser). - Impersonating service accounts to perform actions on their behalf (via iam.serviceAccountTokenCreator). To minimize risks and enforce least privilege, these roles should be granted only for specific service accounts. Impact: Revoking these roles at the project level may disrupt workflows or services that rely on broad permissions. Ensure that the roles are reassigned at the appropriate service account level based on business needs. Default Value: By default, IAM users do not have the Service Account User or Service Account Token Creator roles assigned at the project level. Remediation: Test Plan: Using Google Cloud Console: 1. Navigate to IAM & Admin > IAM at [GCP IAM Console](https://console.cloud.google.com/iam-admin/iam). 2. Use the filter bar and search for Role: Service Account User. 3. Verify that no users are listed with this role at the project level. 4. Repeat the process for Role: Service Account Token Creator. Using Google Cloud CLI: Check for users with the Service Account User role at the project level: gcloud projects get-iam-policy --format json | jq '.bindings\[\].role' | grep "roles/iam.serviceAccountUser" Check for users with the Service Account Token Creator role at the project level: gcloud projects get-iam-policy --format json | jq '.bindings\[\].role' | grep "roles/iam.serviceAccountTokenCreator" 1. No output should be returned from these commands. Implementation: Using Google Cloud Console: 1. Navigate to IAM & Admin > IAM at [GCP IAM Console](https://console.cloud.google.com/iam-admin/iam). 2. Filter for Role: Service Account User and remove the role for all users listed. 3. Repeat for Role: Service Account Token Creator. 4. To assign these roles at the service account level: - Navigate to IAM & Admin > Service Accounts: Service Accounts Console. - Select the specific service account. - Click Permissions and add the desired users with the required roles. Using Google Cloud CLI: Retrieve the current IAM policy and save it to a file: gcloud projects get-iam-policy --format json > iam.json Edit the iam.json file to remove roles/iam.serviceAccountUser and roles/iam.serviceAccountTokenCreator bindings at the project level. Example: { "bindings": \[ { "role": "roles/appengine.appViewer", "members": \[ "serviceAccount:example@appspot.gserviceaccount.com" \] } \], "etag": "BwUjMhCsNvY=" } Update the IAM policy with the modified file: gcloud projects set-iam-policy iam.json Backout Plan: 1\. Reassign Roles (If Necessary) If workflows are disrupted, reassign the roles at the service account level: gcloud iam service-accounts add-iam-policy-binding \\ my-service-account@my-project.iam.gserviceaccount.com \\ --member="user:example@yourcompany.com" \\ --role="roles/iam.serviceAccountUser" 2\. Restore IAM Policy from Backup If needed, restore the previous IAM policy: gcloud projects set-iam-policy backup-iam.json References: 1. [Understanding Service Accounts](https://cloud.google.com/iam/docs/service-accounts) 2. [Granting Roles to Service Accounts](https://cloud.google.com/iam/docs/granting-roles-to-service-accounts) 3. [IAM Roles Documentation](https://cloud.google.com/iam/docs/understanding-roles) 4. [Granting, Changing, and Revoking Access](https://cloud.google.com/iam/docs/granting-changing-revoking-access) CIS Controls:

Control

Description

IG 1

IG 2

IG 3






3.3 Configure Data Access Control Lists

Configure access control lists (ACLs) to enforce least privilege and grant access only as needed.

✅

✅

✅

14.6 Protect Information through ACLs

Use ACLs to protect sensitive information and limit access to authorized users based on responsibilities.

✅

✅

✅

## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.