Automating User Provisioning and Deprovisioning

Manage and automate access reviews and policy enforcement is the practice of continuously verifying that every identity holds only the access it still needs and automatically removing access that violates policy. In Google Cloud, Identity and Access Management (IAM) (opens in a new tab) defines what is allowed, Cloud Audit Logs records what was actually used, Access Context Manager and Chrome Enterprise Premium enforce conditions on every request, and Google groups combined with service account impersonation create a reviewable path for privilege escalation.

1.1Enforce Least Privilege with Continuous Review

Least-privilege review in IAM means granting only the roles required for a task at the smallest scope and then removing unused or excessive grants. Administrators apply Policy Intelligence role recommendations to find IAM policies with unused and excessive roles and replace broad grants with tighter roles. Organization policy constraints constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload enforce least privilege for long-lived service account keys (opens in a new tab) by blocking their creation and upload and forcing workloads toward short-lived alternatives. Because key material can be copied into gcloud CLI configuration files, local filesystems, or code repositories, disabling keys reduces the standing access that later reviews must clean up.

1.2Automate Justification and Approval for Privilege Escalation

Automated escalation in Google Cloud separates the standing identity from the privileged capability by using a Google group that is granted permission to impersonate a privileged service account. In the documented pattern, an administrator creates a group named elevated-compute-access and a service account named elevated-compute-access that holds the roles/compute.admin role on the project. Group members receive no direct administrative role; they receive roles/serviceusage.serviceUsageConsumer on the project and roles/iam.serviceAccountTokenCreator on the service account, so traffic flows from the user identity to service account impersonation and then to Compute Engine APIs. Membership in the group becomes the approval and justification boundary, and privileged access either expires through time-bound membership or is reviewed periodically for recertification.

The escalation path is built in an explicit order:

1. Create group: Create the elevated-compute-access Google group that will hold approved users.
2. Create service account: Create the elevated-compute-access service account and enable the IAM Service Account Credentials API.
3. Grant resource access: Grant roles/compute.admin to the service account, so the service account depends on the project IAM policy for its power.
4. Grant consumption right: Grant roles/serviceusage.serviceUsageConsumer to the group, which permits members to use the project to impersonate.
5. Grant impersonation right: Grant roles/iam.serviceAccountTokenCreator on the service account to the group, which permits members to mint short-lived tokens as the service account.
6. Validate: Validate against a Compute Engine instance such as example-instance-1 that only current group members can administer the instance.

After the binding exists, additional enforcement requires 2-Step Verification for all privileged users and an Access Context Manager access level such as requiring the corporate network when privileged access is used.

1.3Analyze Activity Logs to Detect Violations and Dormant Access

Activity analysis for access reviews relies on Cloud Audit Logs (opens in a new tab) to compare privileged access requests and access patterns against approved policy. Administrators enable ADMIN_READ, DATA_READ, and DATA_WRITE audit log types for services such as compute.googleapis.com by exporting the project IAM policy, adding an auditConfigs block, and reapplying the policy. Log data flows from Google Cloud APIs to Cloud Audit Logs storage, where administrators review who impersonated privileged service accounts, what resources were touched, and whether patterns indicate anomalies, dormant accounts, or policy violations. Enterprises export these logs to long-term storage to preserve evidence for audit and to support periodic recertification that privileged access either expired or was explicitly reapproved.

1.4Enforce Policy at Request Time with Context-Aware Controls

Request-time enforcement in Google Cloud combines a user-centric control and a resource-centric control that are evaluated when API traffic arrives. Chrome Enterprise Premium configures an access level and binding that evaluates attributes on every API request, including IP-based access or certificate-based access for mutual TLS, and rejects user API traffic that does not meet the conditions even when the credential itself is valid. VPC Service Controls defines perimeters within which resources can communicate and applies to traffic crossing those perimeters. When used together, Chrome Enterprise Premium and VPC Service Controls reduce the effectiveness of compromised credentials used from an attacker-controlled machine outside the environment.

Not all device attributes collected by Endpoint Verification are evaluated during every API request, so reviews cannot assume endpoint posture alone blocked access. For remote server access, OS Login with 2-Step Verification enforces reauthentication with password or security key for SSH to Compute Engine, blocking an attacker who holds compromised OAuth tokens but lacks the second factor. Remote Desktop Protocol (RDP) to Windows instances does not support the OS Login service, so granular 2-Step Verification cannot be enforced for RDP sessions and administrators must use coarse-grained controls such as session length, 2-Step Verification settings, disabling Allow user to trust the device, and Identity-Aware Proxy (IAP) Desktop paths.

1.5Automate Remediation of Compromised or Excess Credentials

Automated remediation revokes active sessions and deletes persistent secrets so a failed review or suspected compromise immediately removes access. A prepared script using the Google Workspace Admin SDK lists users with customer: 'my_customer', lists OAuth tokens, matches the gcloud CLI client ID 32555940559.apps.googleusercontent.com, and calls token removal to invalidate refresh and access tokens and force reauthentication with password or security key. The security operations center (SOC) depends on this revocation script being built and tested in advance (opens in a new tab), because revocation must run quickly across many users during an incident.

Remediation differs by credential type, and each path names its actor and destination state:

• gcloud CLI user tokens: Administrator revocation through the Admin SDK moves the user from authorized to reauthentication required.
• Application Default Credentials: Administrator removal of Google Auth Library from connected apps, or owner execution of gcloud auth application-default revoke, followed by deletion of application_default_credentials.json from $HOME/.config/gcloud/ on Linux and macOS or %APPDATA%\gcloud\ on Windows and recreation with gcloud auth application-default login, moves the workstation from compromised credential present to clean credential issued.
• API keys: Holder of the API Keys Admin role (roles/serviceusage.apiKeysAdmin) with apikeys.keys.create and apikeys.keys.delete regenerates the key, moving the project from exposed key valid to new key valid.

1.6Isolate Emergency Access from Lifecycle Automation

Emergency access in Cloud Identity provides last-resort access that is intentionally exempt from standard Joiner, Mover, and Leaver (JML) lifecycle automation and from single sign-on (SSO). Emergency access users (opens in a new tab) are created directly in Cloud Identity or Google Workspace, hold the super admin privilege sufficient to fix misconfigurations in Cloud Identity, Google Workspace, or Google Cloud, and are not tied to a specific employee. Because exemption from JML means normal provisioning and deprovisioning workflows will never remove them, these accounts require their own recertification boundary in a dedicated organizational unit (OU) where custom configurations apply only to emergency users.

Redundancy and phishing-resistant authentication keep this highly privileged exception reviewable without creating a single point of failure:

• Count: Maintain a minimum of two and a maximum of five emergency access users for each Cloud Identity or Google Workspace account.
• Isolation: Place emergency users in a separate OU and create them for every environment, including testing and staging, so loss of access in any environment remains recoverable.
• Authentication: Enforce 2-Step Verification in the emergency OU to allow only Fast IDentity Online (FIDO) security keys, enable 2-Step Verification for every emergency user, and enroll two or more FIDO security keys per user.

Automated provisioning and deprovisioning workflows synchronize user creation, group membership, and resource access from an authoritative source and remove that access promptly when roles change or people leave. In Google Cloud, the workflow centers on Cloud Identity (opens in a new tab) as the identity as a service (IDaaS) control plane, Identity and Access Management (IAM) as the authorization control plane, and Google Groups as the binding between them. When a join, move, or leave event occurs in the authoritative source, group membership changes flow into IAM allow policies so access is granted, adjusted, or revoked without editing individual user bindings.

2.1Choose an Authoritative Source and Provisioning Model

The provisioning model defines where users are created, how many accounts each person holds, and where the trust boundary sits between Google Cloud and an external identity provider (IdP). Google Workspace and Cloud Identity can act as the authoritative source, or an external IdP such as Microsoft Entra ID (formerly Azure AD) or Okta can remain authoritative and connect to Google Cloud for single sign-on. Choosing the model determines whether lifecycle automation depends on synchronization into Google-managed accounts or on federation trust that evaluates the external identity at sign-in time.

2.2Synchronize Identities From the Authoritative Source

Synchronization keeps Google Cloud group membership aligned with team, role, and employment status in the authoritative source so provisioning and moves happen automatically. With Cloud Identity direct management, administrators create managed user accounts, create a group for each administrative function, and assign users to the groups that match their responsibilities. With an external IdP, the connection is established through Workforce Identity Federation, where Google Cloud trusts the external provider to assert identities and group claims through a configured workforce pool.

Connecting an external IdP follows an ordered guided setup where each step depends on the previous one:

1. Create a workforce pool: Create a workforce identity pool with a globally unique workforce pool ID used in IAM and a provider ID that users specify when they log in to Google Cloud.
2. Configure Google Cloud in the provider: Complete the provider-specific configuration so the external IdP recognizes Google Cloud as a relying party.
3. Enter provider details in Google Cloud: Add the provider as a trusted authority by retrieving its OpenID Connect or SAML details and storing them on the workforce pool.
4. Configure administrative groups: Map groups from the provider to Google Cloud administrative functions so the same role structure applies on both sides of the trust boundary.
5. Assign users to each group: Assign more than one user to each administrative group so privileged functions do not depend on a single identity.

Data flows from the external IdP to the workforce pool at authentication time, then from group membership to IAM policies at authorization time. Because IAM evaluates the federated identity and its mapped attributes, suspending or deleting the user in the external IdP can cut off Google Cloud access only when suspension and deletion events are propagated through the federation configuration.

2.3Apply Access Through Groups Using Role-Based Access Control

Group-based access is the mechanism that makes join-move-leave automation work without rewriting IAM policies for every personnel change. Role-based access control (RBAC) (opens in a new tab) assigns IAM roles to Google Groups according to job role, and users gain or lose permissions only by entering or leaving groups. This design enforces the principle of least privilege because each group carries the minimum permissions required for its function, and access ends as soon as membership ends.

Recommended administrative groups separate core functions so organization, billing, network, security, and development duties do not overlap in one principal:

• gcp-organization-admins administers all organization resources and is assigned only to the most trusted users.
• gcp-billing-admins sets up billing accounts and monitors usage.
• gcp-network-admins creates Virtual Private Cloud networks, subnets, and firewall rules.
• gcp-hybrid-connectivity-admins creates network devices such as Cloud VPN instances and Cloud Router.
• gcp-logging-monitoring-admins uses all Cloud Logging and Cloud Monitoring features, while gcp-logging-monitoring-viewers has read-only access to a subset of logs and monitoring data.
• gcp-security-admins establishes organization security policies, including access management and organization constraint policies.
• gcp-developers designs, codes, and tests applications, while gcp-devops creates continuous integration and delivery pipelines and system provisioning.

The IAM policy applies to the group object, and the group depends on Cloud Identity for its membership list. Moving a user from one group to another therefore revokes the allow policies of the previous group and grants the allow policies of the new group in one membership operation.

2.4Design Resources for Automatic Deprovisioning

Deprovisioning removes a departing or transferred user's ability to reach projects, virtual machines (VMs), databases, and keys without manual cleanup of every credential. The design must link each secondary credential lifecycle to the primary Google identity lifecycle so suspension or deletion in Cloud Identity, Google Workspace, or the external IdP automatically invalidates derived access. Without that linkage, orphaned keys, database passwords, and VM logins can survive after the user account is gone.

Build revocation-ready projects by connecting resource access to identity state rather than to long-lived secrets. Use OS Login instead of metadata-based SSH keys so authorized keys remain linked to the Google identity and VM access is revoked automatically when the account is removed. Use the Cloud SQL Auth proxy and AlloyDB for PostgreSQL Auth proxy so database access follows suspension or deletion of the Google identity. Restrict external identities with the iam.allowedPolicyMemberDomains organization list constraint, restrict API keys to specific sites, IP addresses, and apps, and design service account keys, OAuth client secrets, and database root passwords so they support non-disruptive rotation after a departure or compromise. Revocation-ready design (opens in a new tab) ensures that disabling the primary identity also disables its derived access paths.

2.5Detect Unused Accounts and Rightsize Permissions

Continuous detection finds accounts and permissions that automation missed, such as users who changed roles or service accounts abandoned after tasks completed. Policy Intelligence provides the IAM recommender, which uses machine learning to recommend removal of unneeded role bindings and to maintain least privilege across the organization. The Recommender service also emits insights, which are findings about notable usage patterns such as unused permissions and unused service accounts.

At enterprise scale, recommendations flow from IAM recommender through the BigQuery Data Transfer Service into a BigQuery dataset for querying and visualization in Looker or Looker Studio. A query that filters on recommender = "google.iam.policy.Recommender" and recommender_subtype = "REMOVE_ROLE" returns candidates for rightsizing IAM role bindings. Administrators review the results and apply removals, so deprovisioning combines event-driven group removal with periodic machine-assisted cleanup.

2.6Certify and Audit the Lifecycle for Compliance

Certification and auditing prove that the right individuals hold the right access for the right reasons and reveal who changed access when incidents occur. Policy Analyzer checks which users have access to which resources and in what capacity, supporting periodic access reviews for compliance and audit. Cloud Audit Logs (opens in a new tab) records the lifecycle events themselves, including IAM policy changes, service account creation, and service account key downloads.

Use Admin Activity audit logs for control-plane changes to projects, service accounts, and IAM policies, and use Policy Denied audit logs when access is refused because of a security policy violation. Because audit logs have a limited retention period, create a log sink that exports them to BigQuery or another destination for long-term forensics, trend analysis, and aggregate access analytics. Querying SetIamPolicy, google.iam.admin.v1.CreateServiceAccount, and google.iam.admin.v1.CreateServiceAccountKey in Logs Explorer shows permission grants and new workload credentials, while group membership change logs show the join-move-leave operations that drove those grants.

Integrating lifecycle management with security and compliance monitoring means connecting user provisioning systems to detective and corrective controls so every join, move, and leave event is visible, evaluated, and remediated. In Google Cloud, Cloud Identity provisions users and groups, Identity and Access Management (IAM) authorizes who can act on resources, Cloud Audit Logs records what happened, and Security Command Center (SCC) analyzes findings for threats and misconfigurations. Log data flows from IAM, Cloud Identity, and Google Workspace into Cloud Logging for central aggregation, then into Security Command Center and Google Security Operations for analysis, and then back to IAM and Organization Policy Service as remediation. This closed loop detects anomalies in the lifecycle process, supports compliance reporting for access governance, and removes orphaned access automatically.

3.1Centralize Lifecycle Telemetry in Audit Logging

Centralized audit logging for lifecycle visibility aggregates administrator activity, data access, and login events so provisioning and deprovisioning can be reconstructed and monitored. Cloud Audit Logs capture IAM policy changes, service account creation and deletion, and token generation, while Google Workspace and Cloud Identity login logs track interactive user authentication when exported to Cloud Logging. Central aggregation enables baselining of normal joiner-mover-leaver behavior, anomaly detection across projects and folders, and retention policies that balance security needs with storage costs. Access to sensitive logs must itself be protected with restricted IAM roles and reviewed under best practices for audit log security.

Configure alerts in Cloud Audit Logs for identity-specific lifecycle signals:

• iamcredentials.googleapis.com methods such as GenerateAccessToken, GenerateIdToken, and SignJwt to audit service account token generation, which requires Data Access logs to be enabled.
• protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail to audit user and service account impersonation and delegation chains.
• sts.googleapis.com exchange requests to detect anomalous identity assertions from Workload Identity Federation and external identity providers.
• Google Workspace and Cloud Identity login events exported to Cloud Logging to detect disabled-account reuse, suspicious logins, and orphaned accounts that still authenticate.
• VPC Service Controls and Chrome Enterprise Premium logs for out-of-perimeter access attempts with stolen tokens.

3.2Detect Lifecycle Anomalies with Security Command Center

Security Command Center is the centralized security and risk management service that ingests asset inventory, audit logs, and threat telemetry to surface lifecycle anomalies as findings. Its Event Threat Detection source correlates IAM activity, login behavior, and service account usage against baselines to flag persistence, privilege escalation, evasion, and initial access techniques that often follow incomplete deprovisioning. Each finding links to recommended investigation steps, and findings can flow from Security Command Center to an existing security information and event management (SIEM) system or into Google Security Operations for further correlation and incident response. Complementary signals come from secret scanning in code repositories, Anomaly Detection, and Cloud Monitoring for service account key usage anomalies.

Monitor these Event Threat Detection findings for lifecycle compromise and orphaned access:

• Persistence: New Geography for logins from an unusual location after role change or termination.
• Persistence: New User Agent for new client software tied to an existing identity.
• Persistence: New API Method for a principal calling APIs it has never used.
• Evasion: Access from Anonymizing Proxy for attempts to hide lifecycle abuse.
• Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity.
• Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity.
• Initial Access: Leaked Service Account Key Used for keys exposed outside Google Cloud.
• Persistence: Service Account Key Created for unexpected long-lived credential creation.
• Initial Access: Suspicious Login Blocked for blocked hijacking attempts.
• Initial Access: Account Disabled Hijacked for activity from an account that should be inactive.

When a finding fires, the security operations center (SOC) must be notified promptly with playbooks, tools, and cross-console access across the Google Cloud console and the Admin console. If separate teams manage those consoles without pre-granted incident-response access, investigation of a compromised or orphaned identity will be delayed.

3.3Sustain Continuous Compliance and Access Governance

Continuous compliance for lifecycle management follows three stages in order: first assessment of regulatory obligations, then gap remediation of excessive or missing controls, and only after remediation, continual monitoring for drift. Assessment uses the Compliance resource center (opens in a new tab) for service support by regulation and for certifications and attestations, plus the Cloud Data Processing Addendum (CDPA) for contractual commitments on data processing and limits on Google support access. Remediation uses Assured Workloads to set baseline personnel controls, data residency through organization policies, key-management options including customer-managed encryption keys (CMEK), and access criteria for support personnel. Third-party verifications, such as ISO/IEC 27017 attestations, provide independent evidence that platform controls meet the claimed regime.

Resource annotation connects inventory to governance reporting so access reviews can group identities and resources consistently:

Policy as code extends the same governance into deployment pipelines, where Policy Controller (opens in a new tab) and Open Policy Agent (OPA) check infrastructure as code before changes deploy. Organization Policy Service provides centralized preventive control over how resources and identities can be configured, and IAM Conditions and tags with IAM provide conditional, attribute-based access control on top of IAM allow policies that bind principals to roles. VPC Service Controls then adds defense in depth by creating service perimeters that restrict data movement even when an IAM binding exists.

3.4Trigger Automated Remediation for Orphaned Accounts and Policy Deviations

Automated remediation for orphaned accounts closes the lifecycle loop by removing or constraining access that monitoring proves is no longer justified. The remediation path flows from a detection in Security Command Center or Cloud Logging to an action on the IAM allow policy, service account, or organization policy that granted the access. Least-privilege enforcement depends on reviewing and applying IAM role recommendations to remove unused and excessive roles, avoiding overprovisioning during moves, and considering just-in-time privileged access through Privileged Access Manager for sensitive operations. Principal access boundary policies (opens in a new tab) further limit what an identity can do even when it holds broad grants elsewhere in the hierarchy.

Enforce preventive constraints so remediation has fewer deviations to correct:

• constraints/iam.disableServiceAccountKeyCreation to block creation of long-lived service account keys.
• constraints/iam.disableServiceAccountKeyUpload to block upload of externally generated keys.
• Domain-restricted sharing constraints to limit resource sharing based on domain.
• Service account usage constraints to limit which service accounts can be used or impersonated.
• Location constraints to restrict the physical location of newly created resources.

This combination ensures that a departed user whose Cloud Identity account remains active, a service account key created outside the approved pipeline (opens in a new tab), or an IAM grant that violates separation of duties triggers both a detective finding and a corrective change. The SOC playbook, SIEM integration, and pre-aligned response-team access determine how fast that finding becomes revocation, key deletion, or policy rollback.

Key Facts

• Group-based RBAC grants IAM roles to Google Groups so users gain permissions by joining a group and lose permissions by leaving it without rewriting IAM policies.
• Privilege escalation uses a Google group granted roles/iam.serviceAccountTokenCreator to impersonate a privileged service account, with membership as the approval boundary and time-bound membership for expiration.
• Cloud Audit Logs must have DATA_READ and DATA_WRITE enabled to record service account token generation, and impersonation is traced through serviceAccountDelegationInfo.firstPartyPrincipal.
• Emergency access users are exempt from JML and SSO, must number two to five per account in a dedicated OU, and must use FIDO security keys with two or more keys per user.
• Security Command Center Event Threat Detection flags lifecycle abuse such as anomalous service account impersonation, leaked service account keys, and activity from disabled accounts.