Google.iam.admin.v1.updateserviceaccount

​

Event Information

• Event purpose & scope
  • google.iam.admin.v1.UpdateServiceAccount is fired when a service account’s metadata is modified via the IAM Admin API (e.g., display name, description, disabled flag), not when its IAM policy (roles/bindings) is changed.
  • Typical sources: gcloud iam service-accounts update, Console edits, or API clients calling projects.serviceAccounts.patch.
• Security & compliance relevance
  • Changes can affect how a service account is identified, whether it is enabled/disabled, and sometimes can indicate repurposing of an identity—important for SOC 2, ISO 27001, and internal IAM governance.
  • Track for anomalous edits (e.g., unexpected re-enabling of previously disabled accounts) and ensure only authorized roles (e.g., roles/iam.serviceAccountAdmin) are performing these actions.
• Practical monitoring actions
  • In Cloud Logging, filter on protoPayload.@type="type.googleapis.com/google.iam.admin.v1.UpdateServiceAccount" and alert when:
    • authenticationInfo.principalEmail is outside approved admin groups, or
    • requestMetadata.callerSuppliedUserAgent or source IP is unusual, or
    • serviceAccount.disabled flips from true to false.
  • Feed these logs into SIEM / SCC, and use them as part of periodic IAM reviews and change-control evidence.

​

Examples

• Privilege escalation via role change
  • An attacker updates a service account used by an internal app to add high-privilege roles (e.g., roles/owner, roles/iam.serviceAccountTokenCreator) on the project.
  • Impact: Full project takeover (read/write/delete of data, KMS use, billing changes). Violates least-privilege principles in ISO 27001, SOC 2, and CIS GCP.
• Persistence by key/impersonation enablement
  • A malicious admin modifies a low-profile service account to allow key creation or to grant roles/iam.serviceAccountUser to another principal they control.
  • Impact: Long-lived credentials or impersonation path for persistent access, bypassing identity lifecycle controls (NIST 800-53 AC-2, AC-6).
• Lateral movement via resource access expansion
  • The service account for a CI/CD pipeline is updated to include access to additional projects or sensitive APIs (e.g., BigQuery datasets with PII, Cloud Storage backups).
  • Impact: Cross-project lateral movement and data exfiltration, undermining data access controls required by GDPR, HIPAA, and PCI-DSS (principle of data minimization and access segregation).

​

Remediation

​

Using Console

• Immediate containment & investigation (Console + IAM Recommender)
  • In IAM & Admin → IAM, sort by Type = Service account and locate the impacted accounts (by name/email). For each:
    • Click the pencil icon, remove high-privilege roles (roles/owner, roles/iam.admin, roles/iam.serviceAccountTokenCreator, broad *Admin roles) and any roles not required by the app; click Save.
    • In IAM & Admin → Role recommendations, review suggestions and apply least-privilege roles where possible; document all changes for ISO 27001/SOC 2 change records.
  • In IAM & Admin → Audit Logs, filter by Resource type = Service Account and Method name contains setIamPolicy or roles.setIamPolicy to identify who changed what and when; preserve logs for incident response and compliance (NIST 800‑53 AU-6, IR controls).
• Lock down service account capabilities (keys, impersonation, lateral movement)
  • In IAM & Admin → Service Accounts:
    • Click each sensitive/low-profile service account → Keys tab → delete all unnecessary keys; disable “Enable key creation” for admins by removing roles/iam.serviceAccountKeyAdmin or similar from their identities in IAM.
    • On the Permissions tab, remove roles/iam.serviceAccountUser and roles/iam.serviceAccountTokenCreator grants to any untrusted or unnecessary principals to break impersonation paths; keep only specific workloads/principals that must impersonate (aligns with NIST AC‑2/AC‑6).
  • For CI/CD and cross-project access:
    • In each project’s IAM page, restrict the CI/CD service account to tightly scoped roles (e.g., dataset‑specific BigQuery roles, bucket‑level Storage roles) instead of project‑wide or multi-project high-privilege roles.
    • For BigQuery and Cloud Storage, use resource-level permissions: go to BigQuery → Dataset → Share or Cloud Storage → Bucket → Permissions, remove broad grants and add minimal needed roles (satisfies GDPR/HIPAA/PCI-DSS data minimization and segregation).
• Prevent recurrence (guardrails & monitoring)
  • Implement predefined custom roles and groups: in IAM & Admin → Roles, create least-privilege custom roles for admins and CI/CD; then in IAM, assign these instead of primitive roles (Owner, Editor). Restrict who can assign high-privilege roles by limiting roles/iam.admin and roles/resourcemanager.projectIamAdmin to a small, controlled group.
  • In Security → Security Command Center (if enabled) and IAM → Audit Logs, set up alerts (via Cloud Logging → Logs Router → Sinks and Alerting) for:
    • Any assignment of roles/owner, roles/iam.serviceAccountUser, roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountKeyAdmin to service accounts or users.
    • New key creation events for service accounts and IAM policy changes to CI/CD or low-profile accounts.
  • Regularly review IAM → Policy Analyzer and IAM → Service Accounts for over-privileged accounts; formalize quarterly access reviews and approvals to support ISO 27001, SOC 2, CIS GCP, and NIST 800‑53 access review requirements.

​

Using CLI

• Immediate containment & rollback (privilege escalation / persistence / lateral movement)
  • Identify the compromised service account and list its current bindings and keys:
    • gcloud iam service-accounts get-iam-policy SA_NAME@PROJECT_ID.iam.gserviceaccount.com --project=PROJECT_ID
    • gcloud iam service-accounts keys list --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com --project=PROJECT_ID
  • Remove high-privilege or persistence-enabling roles from the service account and project-level IAM (ISO 27001 A.9, CIS GCP IAM):
    • From project IAM:
      • gcloud projects get-iam-policy PROJECT_ID > policy.yaml
      • Edit policy.yaml to remove bindings like roles/owner, roles/editor, roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, or cross-project roles for the SA, then:
      • gcloud projects set-iam-policy PROJECT_ID policy.yaml
    • From SA IAM:
      • gcloud iam service-accounts get-iam-policy SA_NAME@PROJECT_ID.iam.gserviceaccount.com --project=PROJECT_ID > sa-policy.yaml
      • Edit to remove roles/iam.serviceAccountUser, roles/iam.serviceAccountKeyAdmin, or any unwanted member bindings:
      • gcloud iam service-accounts set-iam-policy SA_NAME@PROJECT_ID.iam.gserviceaccount.com sa-policy.yaml --project=PROJECT_ID
  • Disable or delete compromised keys and regenerate only if absolutely required (NIST 800-53 AC-2, AC-6; PCI-DSS key management):
    • gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com --project=PROJECT_ID
    • For CI/CD / lateral movement risk, also revoke unnecessary cross-project roles: use gcloud projects get-iam-policy on all linked projects and remove the SA from sensitive roles (e.g., BigQuery, Storage, KMS).
• Hardening IAM to prevent recurrence (least privilege, data minimization)
  • Enforce least privilege per use-case and create dedicated service accounts with scoped roles instead of roles/owner/roles/editor or broad *Admin on the project (SOC 2 CC6, ISO 27001 A.9, GDPR data minimization):
    • Example tightening for CI/CD SA:
      • gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:CI_SA@PROJECT_ID.iam.gserviceaccount.com" --role="roles/storage.objectAdmin"
      • Avoid adding global roles like roles/bigquery.admin, prefer dataset-level ACLs and per-project roles.
  • Restrict who can modify service accounts and grant impersonation/keys:
    • Limit roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser, roles/iam.serviceAccountTokenCreator, and roles/iam.serviceAccountKeyAdmin to a small break-glass admin group.
    • Example: remove broad group access:
      • gcloud projects get-iam-policy PROJECT_ID > policy.yaml
      • Remove group bindings for these roles, then: gcloud projects set-iam-policy PROJECT_ID policy.yaml
  • Use Org Policies and constraints to block risky patterns (supports CIS GCP, HIPAA/PCI segregation):
    • Disable SA key creation where possible:
      • gcloud resource-manager org-policies allow constraints/iam.disableServiceAccountKeyCreation TRUE --project=PROJECT_ID
    • Restrict who can impersonate all service accounts:
      • gcloud resource-manager org-policies allow constraints/iam.allowedPolicyMemberDomains ... (restrict to corporate domains)
      • Prefer using narrower custom roles instead of wide roles/iam.serviceAccountUser on projects/PROJECT_ID/serviceAccounts/*.
• Detection, investigation & compliance alignment
  • Enable and monitor Cloud Audit Logs for IAM changes, SA key operations, and project-level policy changes; create log-based alerts for high-risk roles or impersonation grants (NIST 800-53 AU-2/AU-6, SOC 2 monitoring):
    • Example high-risk filter:
      • resource.type="project" AND protoPayload.methodName=("SetIamPolicy" OR "SetServiceAccountPolicy" OR "CreateServiceAccountKey") AND ("roles/owner" OR "roles/iam.serviceAccountUser" OR "roles/iam.serviceAccountTokenCreator" OR "roles/iam.serviceAccountKeyAdmin")
  • For suspected compromise, revoke active tokens and sessions and rotate upstream app credentials (e.g., CI/CD systems, internal apps) that use the impacted service accounts; re-run access reviews for BigQuery datasets with PII, backup buckets, and KMS keys (GDPR, HIPAA, PCI-DSS segregation).
  • Document the change and remediation steps, link to internal IAM standards (least privilege, no keys unless justified, impersonation controls), and feed lessons learned into access review and change-management processes to satisfy ISO 27001 A.12/A.18 and SOC 2 CC5/CC7.

​

Using Python

• Immediately detect and revoke over-privileged / persistence-enabling role changes
  • Use Cloud Audit Logs + Python to detect suspicious role bindings (e.g., roles/owner, roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, key creation roles) on service accounts, then automatically strip them from project or service account IAM policies.
  • This supports least-privilege and SoD requirements (ISO 27001 A.9, SOC 2 CC6, CIS GCP, NIST 800-53 AC-2/AC-6).
  from google.cloud import resourcemanager_v3
  from google.iam.v1 import policy_pb2
  
  PROJECT_ID = "my-project-id"
  SENSITIVE_ROLES = {
      "roles/owner",
      "roles/iam.serviceAccountTokenCreator",
      "roles/iam.serviceAccountUser",
      "roles/iam.serviceAccountKeyAdmin",
      "roles/iam.serviceAccountAdmin",
  }
  
  def clean_project_policy(project_id: str):
      client = resourcemanager_v3.ProjectsClient()
      project_name = f"projects/{project_id}"
      policy = client.get_iam_policy(request={"resource": project_name})
      new_bindings = []
  
      for b in policy.bindings:
          if b.role in SENSITIVE_ROLES and any("serviceAccount:" in m for m in b.members):
              # Drop binding or surgically remove service accounts
              filtered_members = [m for m in b.members if not m.startswith("serviceAccount:")]
              if filtered_members:
                  b.members[:] = filtered_members
                  new_bindings.append(b)
          else:
              new_bindings.append(b)
  
      policy.bindings[:] = new_bindings
      client.set_iam_policy(request={"resource": project_name, "policy": policy})
  
  if __name__ == "__main__":
      clean_project_policy(PROJECT_ID)
  
• Lock down service account keys and impersonation paths; rotate if compromised
  • Enumerate service accounts, remove roles/iam.serviceAccountUser and key-admin roles from non-admin principals, disable key creation where not required, and rotate keys/credentials if abuse is suspected, aligning with NIST 800-53 AC-2/IA-5 and SOC 2 change management controls.
  • Use Python with the IAM Admin API to (a) remove risky members from service account IAM, (b) disable/delete user-managed keys.
  from google.cloud import iam_admin_v1
  
  PROJECT_ID = "my-project-id"
  SENSITIVE_MEMBER_PREFIXES = {"allUsers", "allAuthenticatedUsers"}
  RISKY_ROLES = {
      "roles/iam.serviceAccountUser",
      "roles/iam.serviceAccountTokenCreator",
      "roles/iam.serviceAccountKeyAdmin",
  }
  
  def harden_service_account(sa_email: str):
      client = iam_admin_v1.IAMClient()
      name = f"projects/{PROJECT_ID}/serviceAccounts/{sa_email}"
  
      # Clean IAM policy on the service account
      policy = client.get_iam_policy(request={"resource": name})
      new_bindings = []
      for b in policy.bindings:
          if b.role in RISKY_ROLES:
              safe_members = [
                  m for m in b.members
                  if not any(m.startswith(p) for p in SENSITIVE_MEMBER_PREFIXES)
              ]
              # Optionally restrict to a central break-glass group only
              # safe_members = [m for m in safe_members if m == "group:breakglass-admins@org.com"]
              if safe_members:
                  b.members[:] = safe_members
                  new_bindings.append(b)
          else:
              new_bindings.append(b)
  
      policy.bindings[:] = new_bindings
      client.set_iam_policy(request={"resource": name, "policy": policy})
  
      # Disable/delete existing user-managed keys for this SA
      key_client = iam_admin_v1.IAMClient()
      for key in key_client.list_service_account_keys(
          request={
              "name": name,
              "key_types": [iam_admin_v1.ListServiceAccountKeysRequest.KeyType.USER_MANAGED],
          }
      ).keys:
          key_client.delete_service_account_key(request={"name": key.name})
  
  if __name__ == "__main__":
      harden_service_account("sa-internal-app@my-project-id.iam.gserviceaccount.com")
  
• Constrain lateral movement by scoping CI/CD and cross-project access; continuously verify
  • Review and constrain CI/CD service account permissions to least privilege (project- or resource-scoped roles instead of roles/editor/owner, no broad BigQuery/Storage access), and ensure separate accounts per environment/project to satisfy GDPR/HIPAA/PCI-DSS segregation and data-minimization.
  • Use Python to scan for CI/CD SAs with cross-project or high-risk roles and remove/replace them with narrower roles.
  from google.cloud import resourcemanager_v3
  
  ORG_PROJECTS = ["prod-project", "stg-project", "dev-project"]
  CICD_SA_SUFFIX = "-cicd@"
  OVERBROAD_ROLES = {
      "roles/owner",
      "roles/editor",
      "roles/bigquery.admin",
      "roles/storage.admin",
  }
  
  def find_and_downgrade_cicd(project_id: str):
      client = resourcemanager_v3.ProjectsClient()
      res = f"projects/{project_id}"
      policy = client.get_iam_policy(request={"resource": res})
  
      for b in list(policy.bindings):
          if b.role in OVERBROAD_ROLES:
              risky_members = [
                  m for m in b.members
                  if m.startswith("serviceAccount:") and CICD_SA_SUFFIX in m
              ]
              if risky_members:
                  # Remove CI/CD SAs from broad roles; keep others
                  b.members[:] = [m for m in b.members if m not in risky_members]
                  if not b.members:
                      policy.bindings.remove(b)
  
      client.set_iam_policy(request={"resource": res, "policy": policy})
  
  if __name__ == "__main__":
      for p in ORG_PROJECTS:
          find_and_downgrade_cicd(p)