Event Information
-
What it is:
SetIamPolicyis 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
SetIamPolicycalls can lead to privilege escalation, data over‑exposure, or loss of least‑privilege posture. -
How to use it operationally/compliance-wise:
- Log and monitor
SetIamPolicyevents 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
SetIamPolicyevents to validate least privilege and detect unauthorized or non-compliant access changes.
- Log and monitor
Examples
-
Overly permissive role bindings (e.g.,
roles/ownerto broad principal)- Example:
SetIamPolicyaddsuser:alice@example.comasroles/owneron 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.
- Example:
-
Granting external or anonymous access to sensitive resources
- Example:
SetIamPolicyaddsallUsersorallAuthenticatedUserstoroles/storage.objectVieweron a bucket with regulated data. - Impact: Public data exposure, potential non-compliance with GDPR/CCPA/HIPAA; requires immediate bucket policy review and access restriction.
- Example:
-
Privilege escalation via custom role or high-impact permissions
- Example:
SetIamPolicygivesroles/iam.securityAdminor a custom role withresourcemanager.projects.setIamPolicyto 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.
- Example:
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/ownerIAM 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 access → Remove public access (this removes
allUsers/allAuthenticatedUsersat bucket level).
- Click Manage public access → Remove public access (this removes
- Still in Permissions, click Grant access (or Edit access) → review entries:
- Remove
allUsers,allAuthenticatedUsers, and external domains from roles likeStorage Object Viewer/roles/storage.objectViewer. - Replace with least-privilege roles (e.g.,
roles/storage.objectVieweronly to specific groups/service accounts that require it) and use conditions (e.g., resource, time, IP) where appropriate.
- Remove
- 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 Adminor similar; remove these from non-privileged users/service accounts; assign lower-scope roles (e.g., specific service roles) that do not include:resourcemanager.projects.setIamPolicyiam.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.
- Click a role → Permissions → remove high-impact IAM / project policy permissions (e.g.,
- 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
SetIamPolicyon critical resources; require change management / approvals for assignment of IAM admin/custom roles.
- Use groups instead of individuals for admin roles; enable Cloud Audit Logs and Alerting (via Cloud Logging + Cloud Monitoring) for
- In IAM & Admin → IAM, filter by Role =
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.jsonto removeroles/ownerforuser:alice@example.comand/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).
- List current IAM policy on the project:
-
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.
- Inspect bucket IAM and remove public members from sensitive buckets:
-
Eliminate privilege-escalation paths (custom roles,
roles/iam.securityAdmin,setIamPolicypermissions)- 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.
- Identify risky bindings on a project (e.g., security admin, custom roles with
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).
- Use Cloud Asset Inventory / Cloud Logging to find risky bindings, then strip them from the policy and re-apply:
-
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.
- Enumerate buckets and remove public members while enforcing bucket-level access:
-
Enforce least-privilege and prevent future escalation (guardrails)
- Replace direct
roles/ownerand high-privilege roles with scoped custom roles; restrict assignment ofroles/owner,roles/iam.securityAdmin, and any custom roles containingsetIamPolicy,roles.setIamPolicy, orserviceAccounts.setIamPolicyvia:- 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).
- Org Policy constraints (e.g.,
- 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/allAuthenticatedUsersexcept for whitelisted resources.
- Any binding with
- Replace direct

