Event Information
-
Event meaning & context
google.iam.admin.v1.UndeleteRoleindicates that a previously soft-deleted custom IAM role has been restored (undeleted) in a project, folder, or organization using the IAM Admin API (roles.undelete).- This changes the role’s state back to active, making its permissions assignable to principals again via IAM bindings.
-
Security & compliance implications (e.g., ISO 27001, SOC 2, PCI, HIPAA)
- Undeleting a role can re-enable deprecated or overly permissive permissions, potentially violating least privilege requirements.
- For regulated workloads, this event should be correlated with IAM policy changes and change-management tickets to ensure approval and proper justification are documented.
-
Practical actions in production
- Alert on this event in Cloud Logging / Cloud Monitoring and require review of:
- Who performed the action, when, and from where (principal, IP, method).
- The role definition (permissions list) and all members currently or previously bound to this role.
- If unjustified, remove bindings to the role or re-delete the role, and tighten IAM admin privileges (e.g., restrict
iam.roles.undeletevia custom admin roles).
- Alert on this event in Cloud Logging / Cloud Monitoring and require review of:
Examples
-
Revival of deprecated high-privilege custom role
- A previously deleted custom role with broad permissions (e.g.,
resourcemanager.*,iam.roles.*) is undeleted and then re-bound to service accounts or users. - Impact: Privilege escalation or lateral movement; violates least-privilege principles (relevant to ISO 27001 A.9, CIS GCP, NIST AC-6).
- A previously deleted custom role with broad permissions (e.g.,
-
Bypassing access-review / recertification decisions
- A role removed as part of a quarterly access review (e.g., to meet SOX or PCI-DSS requirement for periodic access recertification) is silently undeleted after the review closes.
- Impact: Non-compliance with access-governance controls; difficult audit trail if
UndeleteRoleis not monitored and alerted on.
-
Reactivation of permissions for compromised identities
- After an incident, a role tied to a compromised service account/user is deleted as a containment step, but an attacker with
roles/iam.roleAdminrunsgoogle.iam.admin.v1.UndeleteRoleto restore it. - Impact: Incident containment is negated, enabling attackers to regain access and persistence; conflicts with incident-response controls (e.g., NIST IR, ISO 27035).
- After an incident, a role tied to a compromised service account/user is deleted as a containment step, but an attacker with
Remediation
Using Console
-
Immediately restrict who can undelete and bind roles (least privilege & controls)
- In GCP Console, go to IAM & Admin → IAM, filter for principals with
roles/iam.roleAdmin,roles/owner, or any custom role includingiam.roles.undelete/iam.roles.update/resourcemanager.projects.setIamPolicy. - Edit each principal’s permissions: click the pencil icon → REMOVE overly broad roles → instead assign narrowly scoped roles (e.g.,
roles/iam.securityReviewer,roles/iam.viewer) that do not allow role admin or policy changes. - Repeat at Organization, Folder, and Project levels to enforce least privilege aligned with ISO 27001 A.9, NIST AC-6, and CIS GCP benchmarks.
- In GCP Console, go to IAM & Admin → IAM, filter for principals with
-
Harden custom role lifecycle and access-review process (prevent revival after recertification or incidents)
- In IAM & Admin → Roles, locate the high-privilege custom role (status “Deleted” or recently changed) → if it must not be used again, ensure it is fully deleted (after 7‑day soft-delete window) and recreate a new, least‑privilege role from scratch with only required permissions; document its intended use and approvers.
- For roles removed during access reviews or incident response, implement a change-control policy: any role creation / update / undelete requires a documented ticket and multi-party approval (e.g., security + system owner) before being applied in the Console.
- In IAM & Admin → Audit Logs, enable Admin Activity logs for
iam.googleapis.comat Org level and send logs to Cloud Logging & SIEM; configure log-based alerts ongoogle.iam.admin.v1.UndeleteRoleandSetIamPolicyso any post-review or post-incident resurrection of roles triggers investigation (supports SOX, PCI-DSS, NIST IR, ISO 27035).
-
Operational containment when a risky role has been revived (practical GCP Console steps)
- Detect and inspect: in IAM & Admin → Roles, filter by Custom and sort by Last modified; click the suspicious role → review Permissions and Bindings (via IAM page) to identify all users/service accounts that currently have it.
- Contain access: in IAM, remove bindings for this role from all principals (edit each member → trash icon for the role) and, if necessary, temporarily disable or rotate keys/credentials for affected service accounts or users while incident response proceeds.
- Post-incident: create a locked-down “break-glass” pattern (custom role with minimal admin perms, stored under Org control, only bindable via a documented emergency process) and add periodic reviews of IAM → Roles and IAM → IAM Recommender to ensure old high‑privilege roles are not silently reintroduced.
Using CLI
-
Immediately quarantine and replace the resurrected role
- List and inspect undeleted custom role (including permissions and bindings):
-
- Block further use: remove bindings and disable the role (do not just delete yet for forensics/compliance):
-
- Recreate least‑privilege replacements and migrate bindings:
-
- List and inspect undeleted custom role (including permissions and bindings):
-
Harden governance and monitoring for
UndeleteRoleto meet ISO 27001 / CIS / NIST / SOX / PCI- Enable Data Access and Admin Activity logs on
iam.googleapis.comand create alerting ongoogle.iam.admin.v1.UndeleteRoleand high‑riskSetIamPolicy/SetRolecalls: -
- Restrict
roles/iam.roleAdminandresourcemanager.*to tightly controlled break‑glass groups; use org‑policies and conditional bindings: -
- Embed undelete checks into access recertification: export role history and compare against review decisions:
-
- Enable Data Access and Admin Activity logs on
-
Integrate with incident response: ensure deleted roles stay dead after compromise
- During IR, explicitly revoke admin capabilities that could resurrect access (e.g. temporarily strip
roles/iam.roleAdminfrom all but IR leads): -
- After deleting or disabling roles tied to compromised identities, validate no resurrection and continuously watch for it:
-
- Replace role-based containment with identity containment: rotate keys, disable accounts, and move workloads to new service accounts/roles while keeping tampered roles permanently disabled, satisfying NIST IR and ISO 27035 expectations.
- During IR, explicitly revoke admin capabilities that could resurrect access (e.g. temporarily strip
Using Python
-
Detect and alert on
UndeleteRole+ risky permissions (guardrail & monitoring)- Enable Cloud Audit Logs for
google.iam.admin.v1.UndeleteRoleand export to BigQuery / SIEM; build detections for custom roles with broad permissions (e.g.,resourcemanager.*,iam.roles.*,*Admin,*Owner). - Example Python detection (BQ query runner) to list high‑risk undeleted roles in the last 24h and send to a webhook/alerting system:
- Enable Cloud Audit Logs for
-
Automated remediation of revived / non‑approved roles (least‑privilege & recertification)
- Maintain an allow‑list of approved custom roles and a configuration source of truth (e.g., YAML in Git). Any undeleted custom role not in the allow‑list, or that conflicts with recertification decisions, should be auto‑disabled or deleted, and any new bindings removed.
- Example Python Cloud Function to auto‑disable / delete non‑approved undeleted roles and strip bindings (triggered by Pub/Sub from Audit Logs):
-
Governance & hardening to prevent bypass and incident‑response regression
- Restrict
roles/iam.roleAdmin,roles/iam.organizationRoleAdmin, andresourcemanager.*to a tightly controlled break‑glass group; require approvals (e.g., Access Context Manager + PAM) and log justification for use. - As part of incident response (NIST IR / ISO 27035), script permanent revocation for compromised identities by removing their IAM bindings and marking tied roles as “blocked” in your config repo so any
UndeleteRoleattempt is automatically reverted. Example helper using Python to strip a custom role from a specific compromised principal across the project:
- Restrict

