Google.iam.admin.v1.createserviceaccount remediation

​

Event Information

• Event purpose & scope
  • google.iam.admin.v1.CreateServiceAccount indicates that a new IAM service account was created in a GCP project (via Console, gcloud, API, or Terraform) using the IAM Admin API.
  • The payload typically includes the service account name, email, display name, and the actor (user/service) that initiated the creation.
• Security & compliance relevance (e.g., ISO 27001, SOC 2, PCI-DSS)
  • Creation of service accounts introduces new identities that can hold roles and keys; this is a sensitive event for access control and least-privilege enforcement.
  • It should be monitored and logged in Cloud Audit Logs and forwarded to SIEM for anomaly detection, owner validation, and periodic access reviews.
• Practical controls & monitoring
  • Set up log-based alerts (Cloud Logging) on protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount" to notify security/operations when new service accounts are created.
  • Enforce policies via Organization Policy / IAM conditions and deployment pipelines (e.g., Terraform with code review) to restrict who can create service accounts and ensure naming conventions, owner tagging, and rotation/usage of keys align with compliance requirements.

​

Examples

• Over-privileged / Mis-scoped service account for workloads
  • A new service account is created and then granted broad roles like roles/owner, roles/editor, or project-level roles/iam.serviceAccountTokenCreator. This allows lateral movement, privilege escalation, and token abuse if the workload or service account key is compromised.
  • Compliance: Violates least-privilege requirements in ISO 27001, SOC 2, PCI DSS (e.g., PCI DSS 7 – access needs to be restricted to business need-to-know).
• Shadow / Backdoor service accounts created outside standard process
  • An attacker or insider with IAM admin rights creates a hidden service account (e.g., not registered in CMDB/ITSM) and binds it to critical resources, then uses it for persistence or data exfiltration.
  • Compliance: Breaks access governance and account lifecycle controls (e.g., ISO 27001 A.9, SOC 2 CC6, NIST 800-53 AC family).
• Service accounts with user-like capabilities
  • Service account is created with roles that allow impersonating users or other service accounts (roles/iam.serviceAccountUser, roles/iam.serviceAccountTokenCreator across the project), enabling bypass of SSO/MFA, audit trails tied to the wrong principal, and impersonation of privileged identities.
  • Compliance: Undermines identity assurance and non-repudiation (e.g., PCI DSS 10, SOX logging/traceability, NIST 800-53 AU/IA families).

​

Remediation

​

Using Console

• Remove broad / mis-scoped roles and re-scope to least privilege
  • In GCP Console: Go to IAM & Admin → IAM → locate the over-privileged service account → click Edit principal (pencil icon) → remove broad roles (Owner, Editor, project-wide Service Account Token Creator, etc.).
  • Create or use minimal custom roles: IAM & Admin → Roles → Create Role → add only the specific permissions needed for the workload → return to IAM and assign this custom role only at the narrowest scope (folder/project/specific resource) required.
  • For compliance (ISO 27001, SOC 2, PCI DSS 7): document the new role design, keep an approval record (e.g., in your ITSM), and enforce change control for any future privilege increases.
• Detect and remove shadow/backdoor service accounts; enforce lifecycle controls
  • Discover rogue SAs: Go to IAM & Admin → Service Accounts → filter by project and compare against your CMDB/ITSM; look for SAs with no owner record, unusual names, or created by unexpected users (check Service account details → Audit logs).
  • For any unapproved SA: in Service Accounts, click the SA → Delete (or first revoke its bindings via IAM & Admin → IAM by removing all roles that reference that SA). Also remove any keys: Service account → Keys → Delete for each key.
  • Implement governance: restrict who can create SAs and bind roles by going to IAM and removing roles/iam.serviceAccountAdmin, roles/iam.admin, and roles/resourcemanager.projectIamAdmin from general users; keep these only in tightly controlled admin groups, and review SA inventory periodically against compliance requirements (ISO 27001 A.9, SOC 2 CC6, NIST AC).
• Remove user-like capabilities and impersonation; constrain service account usage
  • In IAM & Admin → IAM, search for principals with roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator at project level; click Edit principal and remove project-wide bindings. Reassign these roles only on specific service accounts where absolutely necessary: open the SA under Service Accounts → Show Info Panel → Permissions → Grant Access, and grant Service Account User only to the minimal group/workload.
  • Disable broad impersonation: avoid granting SAs roles that allow impersonating users (e.g., custom roles with impersonate permissions or roles/iam.serviceAccountTokenCreator on many SAs). Where required, scope to a single SA and enforce usage through workload identity (e.g., GCE/GKE default SA) rather than keys.
  • For compliance (PCI DSS 10, SOX, NIST AU/IA): ensure auditability by confirming in IAM & Admin → Audit Logs that actions are performed by distinct, named principals; document which SAs are allowed to impersonate whom, require approvals, and periodically review these bindings.

​

Using CLI

• Constrain over-privileged / mis-scoped service accounts
  • Identify and review risky bindings (e.g., roles/owner, roles/editor, wide serviceAccountTokenCreator) and export for approval:
    gcloud projects get-iam-policy PROJECT_ID --format=json > iam-policy.json
    gcloud iam service-accounts list --project=PROJECT_ID
    gcloud projects get-iam-policy PROJECT_ID \
      --flatten="bindings[].members" \
      --filter="bindings.members:serviceAccount:" \
      --format="table(bindings.role, bindings.members)"
    
  • Remove broad roles and replace with least-privilege, role-scoped bindings (prefer custom roles and per-service-project scope):
    # Remove project-level owner/editor from SA
    gcloud projects remove-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/editor"
    
    # Grant minimal custom role at narrow resource scope
    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
      --role="projects/PROJECT_ID/roles/CUSTOM_MIN_ROLE"
    
  • Enforce prevention controls aligned with ISO 27001 / PCI DSS 7 (policy-as-code, org policy, CI checks):
    # Example org policy to disable basic roles at project level
    gcloud org-policies set-policy policy.yaml --organization=ORG_ID
    # policy.yaml: constraint=iam.disableServiceAccountKeyCreation / iam.allowedPolicyMemberDomains etc.
    
• Detect and remove shadow / backdoor service accounts
  • Discover unregistered / shadow SAs and bindings by comparing GCP to CMDB lists:
    gcloud iam service-accounts list --project=PROJECT_ID \
      --format="table(email,disabled,oauth2ClientId)"
    gcloud projects get-iam-policy PROJECT_ID \
      --flatten="bindings[].members" \
      --filter="bindings.members:serviceAccount:" \
      --format="table(bindings.role, bindings.members)"
    
  • Disable or delete backdoor SAs (after impact review) and strip their bindings to meet ISO 27001 A.9 / NIST AC lifecycle controls:
    # Remove all bindings for backdoor SA
    gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json
    # edit policy.json to remove that SA, then:
    gcloud projects set-iam-policy PROJECT_ID policy.json
    
    # Optionally disable before delete
    gcloud iam service-accounts disable BACKDOOR_SA@PROJECT_ID.iam.gserviceaccount.com
    gcloud iam service-accounts delete BACKDOOR_SA@PROJECT_ID.iam.gserviceaccount.com
    
  • Hardening and governance (prevent future shadow SAs): require Terraform/Deployment Manager + approval for SA creation and monitor with log-based alerts:
    gcloud logging sinks create sa-creation-sink STORAGE_BUCKET \
      --log-filter='protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"'
    
• Restrict service accounts with user-like capabilities (impersonation / token creation)
  • Enumerate who can impersonate or mint tokens (violates non-repudiation in PCI DSS 10 / SOX if overly broad):
    # List Service Account User / TokenCreator bindings
    gcloud projects get-iam-policy PROJECT_ID \
      --flatten="bindings[].members" \
      --filter='bindings.role:roles/iam.serviceAccountUser OR bindings.role:roles/iam.serviceAccountTokenCreator' \
      --format="table(bindings.role, bindings.members)"
    
  • Remove project-wide impersonation and re-scope to specific identities and SAs only where needed:
    gcloud projects remove-iam-policy-binding PROJECT_ID \
      --member="user:USER@EXAMPLE.COM" \
      --role="roles/iam.serviceAccountUser"
    
    # Grant SA User only on specific SA
    gcloud iam service-accounts add-iam-policy-binding SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
      --member="user:USER@EXAMPLE.COM" \
      --role="roles/iam.serviceAccountUser"
    
  • Enforce controls that keep SA usage non-interactive and traceable: disallow SA keys, require Workload Identity Federation, and alert on high-risk methods:
    # Org policy to disable service account key creation
    gcloud org-policies set-policy disable-sa-keys.yaml --organization=ORG_ID
    # disable-sa-keys.yaml uses constraint: iam.disableServiceAccountKeyCreation
    
    # Alert on token creation / signBlob/signJwt
    gcloud logging sinks create sa-token-abuse-sink PUBSUB_TOPIC \
      --log-filter='protoPayload.methodName=("google.iam.credentials.v1.IAMCredentials.GenerateAccessToken" OR "google.iam.credentials.v1.IAMCredentials.SignJwt" OR "google.iam.credentials.v1.IAMCredentials.SignBlob")'
    

​

Using Python

• Detect and right-size over-privileged / mis-scoped service accounts
  • Enumerate service accounts and flag broad roles (roles/owner, roles/editor, project-level roles/iam.serviceAccount*); export for review and replace with least-privilege custom or predefined roles.
    from google.cloud import resourcemanager_v3, iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    broad_roles = {
        "roles/owner",
        "roles/editor",
        "roles/iam.serviceAccountTokenCreator",
        "roles/iam.serviceAccountUser",
    }
    
    def get_project_number(project_id):
        client = resourcemanager_v3.ProjectsClient()
        proj = client.get_project(name=f"projects/{project_id}")
        return proj.name.split("/")[-1]
    
    def list_bindings_with_broad_roles(project_id):
        project_number = get_project_number(project_id)
        resource = f"projects/{project_number}"
        client = iam_v1.IAMPolicyClient()
        policy = client.get_iam_policy(resource=resource)
        for b in policy.bindings:
            if b.role in broad_roles:
                print(f"ROLE: {b.role}")
                for m in b.members:
                    if m.startswith("serviceAccount:"):
                        print(f"  SA: {m}")
    
    if __name__ == "__main__":
        list_bindings_with_broad_roles(project_id)
    
  • To remediate, adjust the binding: remove broad role from SA and add granular roles on specific resources (e.g., specific GCS buckets, Pub/Sub topics).
    from google.cloud import iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    sa_email = "sa-name@YOUR_PROJECT_ID.iam.gserviceaccount.com"
    role_to_remove = "roles/editor"
    roles_to_add = ["roles/storage.objectViewer"]  # example
    
    def update_sa_bindings(project_id, sa_email, role_to_remove, roles_to_add):
        resource = f"projects/{project_id}"
        client = iam_v1.IAMPolicyClient()
        policy = client.get_iam_policy(resource=resource)
    
        member = f"serviceAccount:{sa_email}"
        new_bindings = []
        for b in policy.bindings:
            if b.role == role_to_remove:
                b.members[:] = [m for m in b.members if m != member]
                if not b.members:
                    continue
            new_bindings.append(b)
        policy.bindings[:] = new_bindings
    
        for r in roles_to_add:
            found = False
            for b in policy.bindings:
                if b.role == r:
                    if member not in b.members:
                        b.members.append(member)
                    found = True
                    break
            if not found:
                policy.bindings.append(
                    iam_v1.Binding(role=r, members=[member])
                )
    
        client.set_iam_policy(resource=resource, policy=policy)
    
    if __name__ == "__main__":
        update_sa_bindings(project_id, sa_email, role_to_remove, roles_to_add)
    
  • Governance: enforce least-privilege via CI/CD checks and Org Policies (constraints/iam.allowedPolicyMemberDomains, constraints/iam.disableServiceAccountKeyCreation), and maintain approvals/records for ISO 27001/SOC 2/PCI DSS evidence.

---

• Detect and remove shadow/backdoor service accounts
  • List all service accounts and compare against an “approved” inventory (from CMDB/ITSM) to detect unregistered SAs; immediately review and, if unauthorized, disable and remove bindings.
    from google.cloud import iam_credentials_v1
    from google.cloud import iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    approved_sas = {
        "approved1@YOUR_PROJECT_ID.iam.gserviceaccount.com",
        "approved2@YOUR_PROJECT_ID.iam.gserviceaccount.com",
    }
    
    def list_service_accounts(project_id):
        client = iam_v1.IAMClient()
        parent = f"projects/{project_id}"
        return list(client.list_service_accounts(name=parent))
    
    if __name__ == "__main__":
        sas = list_service_accounts(project_id)
        for sa in sas:
            if sa.email not in approved_sas:
                print(f"UNAPPROVED SA: {sa.email}")
    
  • For any unapproved SA, revoke IAM bindings and disable/delete account, keeping logs for audit:
    from google.cloud import iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    sa_email = "suspicious@YOUR_PROJECT_ID.iam.gserviceaccount.com"
    
    def remove_sa_from_project_bindings(project_id, sa_email):
        resource = f"projects/{project_id}"
        client = iam_v1.IAMPolicyClient()
        policy = client.get_iam_policy(resource=resource)
        member = f"serviceAccount:{sa_email}"
    
        new_bindings = []
        for b in policy.bindings:
            b.members[:] = [m for m in b.members if m != member]
            if b.members:
                new_bindings.append(b)
        policy.bindings[:] = new_bindings
        client.set_iam_policy(resource=resource, policy=policy)
    
    def disable_and_delete_sa(project_id, sa_email):
        client = iam_v1.IAMClient()
        name = f"projects/{project_id}/serviceAccounts/{sa_email}"
        client.disable_service_account(name=name)
        # wait / validate, then:
        client.delete_service_account(name=name)
    
    if __name__ == "__main__":
        remove_sa_from_project_bindings(project_id, sa_email)
        disable_and_delete_sa(project_id, sa_email)
    
  • Governance: restrict who can create SAs (roles/iam.serviceAccountAdmin) at org/folder level, require change tickets for any SA, and periodically reconcile against CMDB to satisfy ISO 27001 A.9, SOC 2 CC6, NIST AC controls.

---

• Limit service accounts with user-like/impersonation capabilities
  • Enumerate bindings for roles/iam.serviceAccountUser and roles/iam.serviceAccountTokenCreator and verify they are only granted to tightly scoped technical identities on specific SAs, never broad “project-wide” or to generic groups.
    from google.cloud import iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    sensitive_roles = {
        "roles/iam.serviceAccountUser",
        "roles/iam.serviceAccountTokenCreator",
    }
    
    def list_impersonation_bindings(project_id):
        resource = f"projects/{project_id}"
        client = iam_v1.IAMPolicyClient()
        policy = client.get_iam_policy(resource=resource)
        for b in policy.bindings:
            if b.role in sensitive_roles:
                print(f"SENSITIVE ROLE: {b.role}")
                for m in b.members:
                    print(f"  MEMBER: {m}")
    
    if __name__ == "__main__":
        list_impersonation_bindings(project_id)
    
  • Where over-broad, remove project-level impersonation and re-grant at the individual service account resource path (e.g., projects/{p}/serviceAccounts/{sa}) only to approved identities, ensuring user access still flows through SSO/MFA and that logs clearly attribute actions.
    from google.cloud import iam_v1
    
    project_id = "YOUR_PROJECT_ID"
    sa_email = "target-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com"
    member_to_allow = "user:admin@example.com"
    role = "roles/iam.serviceAccountUser"
    
    def set_sa_level_impersonation(project_id, sa_email, member):
        resource = f"projects/{project_id}/serviceAccounts/{sa_email}"
        client = iam_v1.IAMPolicyClient()
        policy = client.get_iam_policy(resource=resource)
    
        for b in policy.bindings:
            if b.role == role and member in b.members:
                return  # already present
    
        policy.bindings.append(
            iam_v1.Binding(role=role, members=[member])
        )
        client.set_iam_policy(resource=resource, policy=policy)
    
    if __name__ == "__main__":
        set_sa_level_impersonation(project_id, sa_email, member_to_allow)
    
  • Governance: enable Cloud Audit Logs for all admin/data access, monitor SA-impersonation events (e.g., GenerateAccessToken, SignJwt), and document mappings of who may impersonate which SA to satisfy PCI DSS 10, SOX, and NIST AU/IA non‑repudiation requirements.