Resourcemanager.projects.setiampolicy

​

Event Information

• Event meaning & scope
  • resourcemanager.projects.setIamPolicy is triggered when the IAM policy on a GCP project is set or replaced via projects.setIamPolicy.
  • This can add, remove, or modify bindings (roles → members) and organization policies attached at the project level.
• Security / risk implications
  • Potentially high‑impact: can grant or revoke broad access (e.g., roles/owner, roles/editor, custom roles) and can introduce privilege escalation if misused.
  • Monitor for changes that: add powerful roles, add external identities (e.g., *@gmail.com, external domains), or modify conditions that restrict access.
• Practical monitoring & compliance actions
  • Enable Cloud Audit Logs (Admin Activity) and route these events to SCC / SIEM; create alerts for:
    • New owner/editor bindings; changes made by service accounts; changes from unusual IPs/regions.
  • Periodically review setIamPolicy events for least‑privilege and alignment with standards like ISO 27001, SOC 2, and PCI DSS (access control, change management), and enforce approvals for high‑risk policy changes via change‑management workflows.

​

Examples

• Project-wide admin granted to broad principal (e.g., allAuthenticatedUsers / entire domain)
  • resourcemanager.projects.setIamPolicy used to add roles/owner or roles/editor to a public or overly broad principal exposes all project resources (Compute, Storage, BigQuery, etc.) to misuse or data exfiltration, violating least privilege and compliance mandates (e.g., ISO 27001 A.9, SOC 2 CC6, CIS GCP 1.1).
  • Mitigation: Immediately revoke broad bindings via gcloud projects get-iam-policy / set-iam-policy, enforce IAM Conditions, and use Org Policies to block public grants.
• Privileged role escalation via custom or predefined roles
  • An attacker (or misconfigured automation) uses setIamPolicy to assign themselves or a compromised service account powerful roles like roles/iam.admin, roles/owner, or a custom role with resourcemanager.projects.setIamPolicy / iam.serviceAccounts.actAs leading to persistent privilege escalation and control over identities and keys (GDPR Art. 32, HIPAA §164.308(a)(3)).
  • Mitigation: Monitor Cloud Audit Logs for policy changes, enable Cloud SCC/Chronicle rules to alert on risky bindings, and require approvals (change management) for role changes to high-privilege principals.
• Cross-project / cross-tenant data access enabling unauthorized data flows
  • setIamPolicy is used to grant another project’s service account read access (e.g., roles/storage.objectViewer, roles/bigquery.dataViewer) across environments (prod → test, or regulated → non‑regulated), breaking data-segregation controls and compliance boundaries (PCI DSS 3.4/7.1, FedRAMP AC-6).
  • Mitigation: Regular IAM reviews, policy analyzer (gcloud iam policy-intelligence or Policy Analyzer UI), labels/folders to segment regulated workloads, and guardrails via Org Policy plus CI/CD checks before applying IAM changes.

​

Remediation

​

Using Console

• Revoke project‑wide admin from broad principals (e.g., allAuthenticatedUsers, entire domain)
  1. Console: Go to IAM & Admin → IAM, use the Include Google-provided role grants filter, and look for principals like allUsers, allAuthenticatedUsers, or broad groups/domains (e.g., @example.com) with Owner or Editor.
  2. For each risky binding: click Edit principal (pencil icon) → remove Owner / Editor (and any other unnecessary roles) → assign only the minimum required predefined role(s) or a tightly scoped custom role → Save.
  3. Hardening: Under IAM & Admin → Organization policies, enforce controls such as “Domain restricted sharing” and “Restrict public IAM grants” to prevent future public/broad assignments and document this as a least‑privilege / segregation control for ISO 27001, SOC 2, and CIS checks.
• Stop privileged role escalation via custom/predefined roles
  1. Console: IAM & Admin → IAM, sort by Role and specifically review principals with Owner, Editor, IAM Admin, Security Admin, and any Custom roles that contain resourcemanager.projects.setIamPolicy, iam.serviceAccounts.actAs, or iam.roles.update. Remove or downgrade these roles from non‑break-glass users and generic service accounts; keep them only on tightly controlled admin identities.
  2. Console: IAM & Admin → Roles → open each custom role → Permissions tab → search for high‑risk permissions (setIamPolicy, roles.create/update, serviceAccounts.actAs, key management, org policy). Remove them where not strictly needed, or create separate “elevated admin” roles gated by strong approval and MFA.
  3. Monitoring & approvals: In Security → Security Command Center (or Chronicle if available), enable and/or tune findings for risky IAM changes; in Logging → Logs Explorer, build saved queries for SetIamPolicy / IAM role changes and export to SIEM. Require change tickets and at least two‑person approval for assigning any role that can change IAM or act as service accounts (GDPR/HIPAA admin safeguards).
• Control cross‑project / cross‑tenant data access (prevent unauthorized data flows)
  1. Discovery: Use IAM & Admin → IAM in each project and look for service accounts from other projects or external tenants (principal type = Service account, with different project ID) that have roles like Storage Object Viewer, BigQuery Data Viewer, or custom read roles over sensitive projects (prod, regulated, PCI, PHI, etc.). Remove any access that is not explicitly approved per data‑segregation policy.
  2. Guardrails: Use IAM & Admin → Policy Analyzer (Policy Intelligence) to simulate and review cross‑project access paths; for highly regulated workloads, group them under dedicated Folders and apply stricter Organization policies (e.g., restrict external service accounts, restrict cross‑project service account usage). Enforce environment‑specific labels (e.g., env=prod, data=regulated) and reference them in your internal standards.
  3. Preventative controls: Integrate IAM changes into CI/CD (Terraform, Deployment Manager) with code review; add checks that block grants from regulated projects to non‑regulated ones or to foreign tenants. Periodically run IAM Recommender / Policy Intelligence to identify excess permissions and remediate to comply with PCI DSS and FedRAMP segregation requirements.

​

Using CLI

• Revoke project‑wide admin from broad principals (e.g., allAuthenticatedUsers, entire domain)
  • List current IAM policy and identify risky bindings:
    • gcloud projects get-iam-policy PROJECT_ID --format=json > iam.json
    • Review for bindings like roles/owner, roles/editor, or other high‑privilege roles with members such as allAuthenticatedUsers, allUsers, or entire domains (domain:example.com).
  • Remove/adjust risky bindings and re‑apply policy:
    • Edit iam.json to delete or narrow these bindings (e.g., per‑group or per‑service‑account, and preferably to least‑privilege roles).
    • gcloud projects set-iam-policy PROJECT_ID iam.json
  • Enforce guardrails and conditions:
    • Block future public grants:
      • gcloud org-policies set-policy org-policy.yaml with constraints like constraints/iam.allowServiceAccountCredentialLifetimeExtension (as needed) and especially constraints/iam.allowedPolicyMemberDomains or constraints/iam.disableServiceAccountKeyCreation as part of hardening, and use constraints/iam.allowedPolicyMemberDomains to restrict members to approved domains.
    • Use conditional bindings to scope access, for example:
      gcloud projects add-iam-policy-binding PROJECT_ID \
        --member="group:devs@example.com" \
        --role="roles/viewer" \
        --condition="expression=request.time < timestamp('2026-01-01T00:00:00Z'),title=TemporaryAccess,description=Time‑bound read‑only"
      
• Contain privileged role escalation via custom/predefined roles
  • Identify and roll back risky high‑privilege grants:
    • gcloud projects get-iam-policy PROJECT_ID --format=json | jq '.bindings[] | select(.role | test("roles/owner|roles/editor|roles/iam.admin"))'
    • For each risky binding, remove it (or replace with least‑privilege roles) in iam.json and re‑apply with:
      • gcloud projects set-iam-policy PROJECT_ID iam.json
  • Monitor and alert on IAM policy changes to privileged roles:
    • Ensure Admin Activity logs for setIamPolicy are enabled (they are by default) and routed:
      • gcloud logging sinks create iam-changes-sink \ storage.googleapis.com/BUCKET_NAME \ --log-filter='protoPayload.methodName=("SetIamPolicy" OR "SetIamPolicy") AND resource.type="project"'
    • Use Security Command Center / Chronicle to alert when roles/owner, roles/iam.admin, custom roles containing resourcemanager.projects.setIamPolicy or iam.serviceAccounts.actAs are assigned.
  • Implement change control and constrained delegation:
    • Restrict who can modify IAM:
      gcloud organizations remove-iam-policy-binding ORG_ID \
        --member="group:too-broad-admins@example.com" \
        --role="roles/resourcemanager.organizationAdmin"
      
    • Require approvals via CI/CD: represent IAM as code (Terraform/YAML), and only allow gcloud projects set-iam-policy via pipelines with reviews, not from individual laptops.
• Prevent unauthorized cross‑project / cross‑tenant data access
  • Discover cross‑project grants:
    • gcloud projects get-iam-policy PROJECT_ID --format=json | jq '.bindings[] | select(.members[]? | contains("serviceAccount:"))' and note members from other projects/tenants.
    • For specific resources, e.g. GCS:
      • gcloud storage buckets get-iam-policy gs://BUCKET_NAME --format=json
    • For BigQuery:
      • gcloud bq show --format=prettyjson PROJECT_ID:DATASET | jq '.access'
  • Revoke or narrow cross‑environment access:
    • Remove or restrict cross‑project roles/storage.objectViewer, roles/bigquery.dataViewer, etc. by editing the respective IAM policies and re‑applying:
      gcloud storage buckets set-iam-policy gs://BUCKET_NAME bucket-iam.json
      gcloud bq update --source=dataset-iam.json PROJECT_ID:DATASET
      
    • Where cross‑project access is required, use dedicated “broker” service accounts and least‑privilege roles limited to specific buckets/datasets, ideally with IAM Conditions (e.g., labels, resource names).
  • Enforce segregation and pre‑deployment checks:
    • Segment regulated workloads with folders/labels and tighter org policies (e.g., separate folders for PCI/HIPAA vs. non‑regulated, and enforce restrictive constraints/iam.allowedPolicyMemberDomains / resource‑location constraints).
    • Use Policy Analyzer / Policy Intelligence to continuously review effective access:
      • gcloud iam policy-intelligence analyze-iam-policy \ --full-resource-name="//cloudresourcemanager.googleapis.com/projects/PROJECT_NUMBER" \ --identity="serviceAccount:SA_NAME@OTHER_PROJECT.iam.gserviceaccount.com"
    • Integrate IAM checks into CI/CD (e.g., policy linting) before running gcloud ... set-iam-policy to prevent non‑compliant cross‑environment bindings.

​

Using Python

• Revoke broad / public project-wide admin bindings (GCPIAM via Python)
  from google.cloud import resourcemanager_v3
  
  project_id = "my-project-id"
  bad_members = {
      "roles/owner": {
          "allUsers",
          "allAuthenticatedUsers",
          "domain:example.com"   # adjust per your org
      },
      "roles/editor": {
          "allUsers",
          "allAuthenticatedUsers",
          "domain:example.com"
      }
  }
  
  client = resourcemanager_v3.ProjectsClient()
  name = f"projects/{project_id}"
  
  # Get current IAM policy
  get_req = resourcemanager_v3.GetIamPolicyRequest(resource=name)
  policy = client.get_iam_policy(request=get_req)
  
  # Remove bad members from broad roles
  new_bindings = []
  for b in policy.bindings:
      role = b.role
      members = set(b.members)
      if role in bad_members:
          members -= bad_members[role]
      if members:
          b.members[:] = list(members)
          new_bindings.append(b)
  
  policy.bindings[:] = new_bindings
  set_req = resourcemanager_v3.SetIamPolicyRequest(resource=name, policy=policy)
  client.set_iam_policy(request=set_req)
  
  • Follow-up: enforce org policies like constraints/iam.allowedPolicyMemberDomains, forbid allUsers/allAuthenticatedUsers at project level, and use IAM Conditions to scope necessary public access only to specific resources.
• Detect and roll back privileged role escalation (owners / IAM admins / custom roles)
  from google.cloud import resourcemanager_v3
  
  PROJECT_ID = "my-project-id"
  HIGH_RISK_ROLES = {
      "roles/owner",
      "roles/editor",
      "roles/iam.admin",
      "roles/iam.securityAdmin",
  }
  SENSITIVE_MEMBERS = {
      "user:someone@external.com",           # adapt to your context
      "serviceAccount:compromised-sa@....",
  }
  
  client = resourcemanager_v3.ProjectsClient()
  name = f"projects/{PROJECT_ID}"
  
  get_req = resourcemanager_v3.GetIamPolicyRequest(resource=name)
  policy = client.get_iam_policy(request=get_req)
  
  changed = False
  for b in policy.bindings:
      if b.role in HIGH_RISK_ROLES:
          before = set(b.members)
          b.members[:] = [m for m in b.members if m not in SENSITIVE_MEMBERS]
          if set(b.members) != before:
              changed = True
  
  if changed:
      set_req = resourcemanager_v3.SetIamPolicyRequest(resource=name, policy=policy)
      client.set_iam_policy(request=set_req)
  
  • Operationalize: back IaC (Terraform) as the source of truth, require change approvals for any setIamPolicy affecting HIGH_RISK_ROLES, and configure Cloud Logging + SCC / Chronicle rules to alert on these bindings.
• Identify / prevent cross-project or cross-tenant data access violations
  from google.cloud import resourcemanager_v3
  
  PROJECT_ID = "regulated-project-id"
  ILLEGAL_PROJECT_PREFIXES = ("test-", "dev-")  # non-regulated or lower envs
  
  client = resourcemanager_v3.ProjectsClient()
  name = f"projects/{PROJECT_ID}"
  
  get_req = resourcemanager_v3.GetIamPolicyRequest(resource=name)
  policy = client.get_iam_policy(request=get_req)
  
  bad_cross_members = []
  for b in policy.bindings:
      for m in b.members:
          if m.startswith("serviceAccount:"):
              sa = m.split(":", 1)[1]
              # pattern: sa-name@project-id.iam.gserviceaccount.com
              proj = sa.split("@")[-1].split(".iam.gserviceaccount.com")[0]
              if proj.startswith(ILLEGAL_PROJECT_PREFIXES):
                  bad_cross_members.append((b.role, m))
  
  if bad_cross_members:
      # remove them
      for role, member in bad_cross_members:
          for b in policy.bindings:
              if b.role == role and member in b.members:
                  b.members.remove(member)
      set_req = resourcemanager_v3.SetIamPolicyRequest(resource=name, policy=policy)
      client.set_iam_policy(request=set_req)
  
  • Governance: use folders/labels to separate regulated vs non-regulated projects, enforce org policies (constraints/iam.allowedPolicyMemberDomains, constraints/gcp.resourceLocations) and add CI/CD checks that block IAM changes creating cross-environment access to regulated projects.