Skip to main content

Event Information

  • What it is: SetIamPolicy is a GCP Admin API call that replaces the IAM policy on a resource (e.g., project, folder, bucket, service account) with a new one. It’s a write operation that can add, remove or change who has which roles on that resource.
  • Why it matters: This event is security‑critical—it can grant or revoke access across users, groups, service accounts, or external identities. Misconfigured SetIamPolicy calls can lead to privilege escalation, data over‑exposure, or loss of least‑privilege posture.
  • How to use it operationally/compliance-wise:
    • Log and monitor SetIamPolicy events in Cloud Audit Logs and route them to SIEM; alert on high‑risk changes (e.g., roles/owner, allUsers, allAuthenticatedUsers).
    • Require change control (e.g., approvals, tickets) for policy changes on sensitive resources to meet ISO 27001, SOC 2, PCI-DSS change‑management and access‑control requirements.
    • Periodically review historical SetIamPolicy events to validate least privilege and detect unauthorized or non-compliant access changes.

Examples

  • Overly permissive role bindings (e.g., roles/owner to broad principal)
    • Example: SetIamPolicy adds user:alice@example.com as roles/owner on a project, giving full control (including billing, IAM, data access) beyond least-privilege.
    • Impact: Violates least-privilege (ISO 27001, SOC 2) and can lead to full environment compromise if that account is compromised.
  • Granting external or anonymous access to sensitive resources
    • Example: SetIamPolicy adds allUsers or allAuthenticatedUsers to roles/storage.objectViewer on a bucket with regulated data.
    • Impact: Public data exposure, potential non-compliance with GDPR/CCPA/HIPAA; requires immediate bucket policy review and access restriction.
  • Privilege escalation via custom role or high-impact permissions
    • Example: SetIamPolicy gives roles/iam.securityAdmin or a custom role with resourcemanager.projects.setIamPolicy to a non-privileged service account.
    • Impact: Allows user/service account to grant themselves or others higher privileges (admin, key management), breaking separation of duties (PCI DSS, SOX); should trigger alerting and policy change review.

Remediation

Using Console

  • Remove overly permissive / risky bindings (e.g., roles/owner, public access)
    • In GCP Console, go to IAM & Admin → IAM → top project selector: choose affected project.
    • Find the member (e.g., user:alice@example.com, allUsers, allAuthenticatedUsers, external domains), click Edit principal (pencil) → in Roles remove:
      • Owner / roles/owner
      • IAM Security Admin / roles/iam.securityAdmin
      • Any other excessive admin role not strictly needed
    • Click Save. Repeat for all projects/folders/org where the principal appears.
  • Restrict bucket access and remove public/over-broad principals
    • In GCP Console, go to Cloud Storage → Buckets → select sensitive bucket.
    • Permissions tab → if Public access shows warnings:
      • Click Manage public accessRemove public access (this removes allUsers / allAuthenticatedUsers at bucket level).
    • Still in Permissions, click Grant access (or Edit access) → review entries:
      • Remove allUsers, allAuthenticatedUsers, and external domains from roles like Storage Object Viewer / roles/storage.objectViewer.
      • Replace with least-privilege roles (e.g., roles/storage.objectViewer only to specific groups/service accounts that require it) and use conditions (e.g., resource, time, IP) where appropriate.
    • If using Uniform bucket-level access, ensure object ACLs are not granting public or external access; enable UBLA if possible for stricter control.
  • Prevent and clean up privilege-escalation paths (custom roles, IAM admin roles)
    • In IAM & Admin → IAM, filter by Role = IAM Security Admin / Organization Admin / Project IAM Admin or similar; remove these from non-privileged users/service accounts; assign lower-scope roles (e.g., specific service roles) that do not include:
      • resourcemanager.projects.setIamPolicy
      • iam.roles.update, iam.roles.create, or broad *setIamPolicy* permissions
    • In IAM & Admin → Roles, locate custom roles:
      • Click a role → Permissions → remove high-impact IAM / project policy permissions (e.g., resourcemanager.projects.setIamPolicy, iam.serviceAccounts.setIamPolicy, iam.roles.*) unless explicitly justified and documented.
    • Implement controls aligned with ISO 27001 / SOC 2 / PCI DSS / SOX:
      • Use groups instead of individuals for admin roles; enable Cloud Audit Logs and Alerting (via Cloud Logging + Cloud Monitoring) for SetIamPolicy on critical resources; require change management / approvals for assignment of IAM admin/custom roles.

Using CLI

  • Remove overly-permissive role bindings (e.g., roles/owner) and replace with least-privilege roles
    • List current IAM policy on the project:
    • Edit policy.json to remove roles/owner for user:alice@example.com and/or replace with specific roles (e.g., roles/viewer, roles/storage.objectAdmin, etc.), then apply:
    • For compliance (ISO 27001, SOC 2), document the change, record the justification for any remaining high-privilege roles, and ensure approvals are logged (e.g., in a ticketing system).
  • Restrict external/anonymous access (allUsers, allAuthenticatedUsers) to sensitive resources
    • Inspect bucket IAM and remove public members from sensitive buckets:
    • Additionally, enforce bucket-level public access prevention for regulated data:
    • For GDPR/CCPA/HIPAA, verify data classification, ensure DPA/records of processing are updated, and maintain an access review log proving removal of public access.
  • Eliminate privilege-escalation paths (custom roles, roles/iam.securityAdmin, setIamPolicy permissions)
    • Identify risky bindings on a project (e.g., security admin, custom roles with resourcemanager.projects.setIamPolicy):
    • Remove or restrict high-impact roles from non-privileged service accounts/users via policy file:
    • For PCI DSS/SOX, ensure separation of duties: maintain a list of allowed IAM/security administrators, enable Cloud Audit Logs for IAM changes, and require change-control approval for any assignment of roles that include setIamPolicy, setIamPolicy-like permissions, or key-management capabilities.

Using Python

  • Detect and remove overly permissive / external bindings (owner, public, escalation)
    • Use Cloud Asset Inventory / Cloud Logging to find risky bindings, then strip them from the policy and re-apply:
    • Run this via CI/CD or as a Cloud Run / Cloud Function triggered by IAM change logs; preserve previous policies in Secure Storage for rollback and audit (ISO 27001 A.8, SOC 2 CC6.x).
  • Specifically remediate public bucket access (allUsers / allAuthenticatedUsers)
    • Enumerate buckets and remove public members while enforcing bucket-level access:
    • Document buckets that truly must be public, segregate from regulated data, and maintain a formal exception register for GDPR/CCPA/HIPAA/SOC 2 evidence.
  • Enforce least-privilege and prevent future escalation (guardrails)
    • Replace direct roles/owner and high-privilege roles with scoped custom roles; restrict assignment of roles/owner, roles/iam.securityAdmin, and any custom roles containing setIamPolicy, roles.setIamPolicy, or serviceAccounts.setIamPolicy via:
      • Org Policy constraints (e.g., constraints/iam.allowedPolicyMemberDomains, constraints/iam.disableServiceAccountKeyCreation).
      • Centralized role catalog and approval workflow for admin roles (PCI DSS 7.x, SOX access control).
    • Add a pre-deployment check to your infra-as-code (Terraform/Deployment Manager) that rejects:
      • Any binding with roles/owner, roles/editor, roles/iam.securityAdmin, or custom roles tagged as “privileged”.
      • Any use of allUsers/allAuthenticatedUsers except for whitelisted resources.